Arc is out
31st of January 2008
Image shamelessly stolen from Paul Grahams Website.
Man mag von Paul Graham halten was man will, aber vorgestern ist etwas passiert, womit ich nicht in den nächsten zehn Jahren gerechnet hätte: PG hat eine erste sehr vorläufige Fassung von Arc veröffentlicht. Vorbei die guten alten Zeiten, in denen man Arc, Hurd und E17 in einem Atemzug nennen konnte. Ich bin erschüttert :)
Paul Graham hat mit On Lisp und seinen Essays (eines der prominentesten dürfte wohl Hackers and Painters sein), schon immer die besseren "Hacker" angesprochen. Etwas später hat er dann mit Arc seinen eigenen LISP-Dialekt erschaffen, von dem über viele Jahre nicht mehr als ein paar Schnippselchen und Ideen bekannt waren. Niemand hat damit gerechnet, dass das irgendwann wirklich kommen wird.
PG sagt selbst, dass es noch zu früh ist und man nicht genau wissen kann, wohin die Reise geht. Arc ist derzeit noch ziemlich unvollständig. So fehlt z.B. eine ordentlich Character-Code-Unterstützung, die mehr als US-ASCII bietet und selbstverständlich hängen sich daran viele auf (da sind ein paar). Wobei es vielleicht schon etwas komisch anmutet, dass die Character-Code-Unterstützung deshalb fehlt, weil PG keine Lust oder Zeit hatte, die MzScheme-Dokumentation zu lesen und die verdammte Unterstützung dafür gleich einzubauen.
Viele von Arcs Funktionen haben sehr kurze Namen (z.B. prn) und einige Konstrukte wie z.B. ein sehr idiomatisches if sind etwas gewöhnungsbedürftig. Es gibt keine Module, usw. usw. Natürlich gibt es Macros (unhygienische, war auch klar):
(mac n-of (n expr)
(w/uniq ga
`(let ,ga nil
(repeat ,n (push ,expr ,ga))
(rev ,ga))))
Etwas grotest ist, dass Arc derzeit auf MzScheme (→ siehe auch PLT) basiert und nicht auf Common LISP. Dadurch fehlt eine direkte CL-Anbindung und auch ein native code Compiler. Spannend fände ich eine eine Arc-Library für CL (vielleicht arc-compat), damit man all die schönen Libraries von CL verwenden kann und natürlich auch einen ordentlichen Compiler bekommt.
Jedenfalls gefällt es mir, bei der Entwicklung, sofern es denn eine geben wird, zuschauen zu können. Und vielleicht wird es den Tag geben, an dem man mit Arc schöne und sinnvolle Dinge erledigen kann. Ob PG bei der weiteren Entwicklung eine Rolle spielen wird?
The Rise Of Functional Programming
15th of January 2008
Und noch ein Rant: "The Rise Of Functional Programming". Natürlich darf ein so wohlklingender Untertitel »der den Tod und/oder das Versagen von Lisp proklamiert« wie "F#/Scala/Haskell and the failing of Lisp" nicht fehlen. Solche Titel sorgen immerhin für den entsprechenden Wirbel :)
Der Text ist interessant und gut lesbar, sollte aber mit der angemessenen Kritik beäugt werden.
Lisp is Not an Acceptable Lisp
15th of January 2008
"Lisp is Not an Acceptable Lisp" von Steve Yegge ist ein lesenwerter »Rant«, vier Monate nach Why Ruby is an acceptable LISP. Werden wieder tausende von Kommentare aus dem Bereich des Hasses, der Verachtung oder Schlimmeren formuliert?
Symbolics Versagen
03rd of January 2008
Dan Weinreb, Symbolics Mitgründer, hat einen sehr interessanten Artikel über das Versagen von Symbolics geschrieben: Why Did Symbolics Fail?.
Symbolics war jene Firma, die die sog. Lisp-Machines entwickelte und auf den Markt brachte.
Bild oben: Screenshot von Symbolics Genera auf einem Macivory (Bild von Rainer Joswig).
Lisp-Machines waren spezielle Rechner zur Ausführung von LISP mithilfe eigens entworfener Hardware (Silikon) und Software. Angeblich waren diese Maschinen das wirklich tollste, was man sich zur Programmierung in Lisp wünschen konnte.
Dan Weinrebs Weblog ist auch ansonsten grossartig und damit sehr zu empfehlen.
Zwiebelstatus
01st of January 2008
Larry Wall's Programming is Hard, Let's Go Scripting... aka State of the Onion ist ganz nett und unterhaltsam, wenn ich auch fürchte, dass Perl6 mir nicht sonderlich gefallen wird. Perl6 könnte auch Stagnant6 oder so ähnlich heißen und reit sich ganz wunderbar in Hurd und Co. ein.
I started out as a BASIC programmer. Some people would say that I'm permanently damaged. Some people are undoubtedly right.
Larry Wall
Schon ganz schön gruselig.
For good or ill, when I went off to grad school, I studied linguistics, so the only computer language I used there was LISP. It was my own personal McCarthy era.
Is LISP a candidate for a scripting language? While you can certainly write things rapidly in it, I cannot in good conscience call LISP a scripting language. By policy, LISP has never really catered to mere mortals.
And, of course, mere mortals have never really forgiven LISP for not catering to them.
Larry Wall
Das ist mein Favorit. Die armen sterblichen Erdenkinder. Klar für die ist das nix. Schön zu wissen, dass es für den Rest von uns LISP gibt. Danke Larry!
Black Hole Theory of Design
30th of December 2007
Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp
Guy Steele
Das ganze stammt aus James Goslings Gedanken über Closures in Java 6: Black Hole Theory of Design (sure, pretty old 2006-09).
Interessant finde ich auch folgende Aussage: "I have somewhat mixed feelings about closures: they are pretty complicated" und weiter unten im Text "When inner classes were designed, we wanted to avoid the complexity of closures.".
Irgendwie schon witzig so etwas zu lesen: Innere Klassen in Java haben eine geringere Komplexität als Closures! Mir scheint da geht so einiges durcheinander. Kein Wunder, dass Java kaum Fortschritte macht.
Gut, closures sind in einer Programmiersprache wie Java vielleicht eher unkonventionell, aber was soll an diesem Konzept bitte schwierig sein? Vielleicht "schwierig" zu implementieren (box it baby), aber spielt das wirklich eine Rolle? Dafür sind Gosling und Co schließlich da (soll sich doch Gosling den SBCL compiler anschauen, da stecken hunderte gute Ideen zur Kompilierung von Closures drin ;p).
Nachtrag: Mir stellt sich allerdings schon die Frage, wie ein Konzept wie Closures in die Sprache Java passen könnte. Alleine, also ohne andere Nettigkeiten wie z.B. higher order functions würde das meiner Meinung wenig Spaß machen. Ausserdem ist Java einfach eine Mainstream-Sprache, die möglichst Vielen gefallen soll. Man stelle sich nur vor, Hugo-Heinz-Meier-von-nebenan verwendet ausgiebig Closures im Rechenkern der x-ten Finanzsoftware. Nein das ginge nicht. Chaos und Unverständnis wären vorprogrammiert. Lieber nicht.
Noch ein Nachtrag: Hier eine Präsentation (ppt) mit dem Titel "The Closure Controversy" von Joshua Bloch, Chief Java Architect bei Google. Eine Google-Suche nach The Closure Controversy zeigt, dass sich damit schon einige 'beschäftigt' haben.
Nachtrag (2008-01-04): Hier noch etwas von Tim Bray (Sun M.) und Bruce Eckel Java: Evolutionary Dead End.
Good answer to Lisp or Scheme
02nd of February 2007
Good answer to Lisp or Scheme. If they ever stop asking?
Chicken/call/cc
20th of July 2006
Wow, die Website von Chicken wurden komplett redesigned und wie es mir scheint, sind nun fertige binaries fuer alle (mir wichtigen) Plattformen ladbar.
Nur mal so: Scheme ist eine Programmiersprache, die ihre Wurzeln in der sog. Lambda Calculus hat, die 1959 von John McCarthy in der Sprache LISP erstmals umgesetzt wurde. Nur Fortran ist aelter.
Scheme ist im Gegensatz zu Common LISP sehr klein und uebersichtlich. Man hat bei dessen Spezifikation auf das Sprachessentielle beschraenkt, was dazu fuehrt, dass die Sprachspezifikation (das sog. R5RS) auf 46 Seiten (PDF) passt (ohne Zitate und Index), was fuer eine Sprache – die natuerlich Turingvollstaendig ist – recht erstaunlich ist.
Game of Go in LISP & Ajax
11th of April 2006
Lars Rune Nøstdal posted on comp.lang.lisp an interresting implementation of the game of Go using common lisp and ajax.