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.
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.