[linux-l] Mächtigkeit von LISP

[Volker Grabsch]

On Sat, Jul 01, 2006 at 03:28:26AM +0200, Oliver Bandel wrote:
> > http://www.paulgraham.com/avg.html
[...]
> > Der Artikel übertreibt IMHO ein wenig, wenn er LISP als "Geheimwaffe"
> > und "entscheidenen Vorteil gegenüber der Konkurrenz" bezeichnet,
> 
> Ich denke das tut er nicht.

Nun, sein entscheidener Vorteil war IMHO, dass er sich von vornherein
neutral Gedanken über das Thema gemacht hat, und *dann* sich seine
Werkzeuge zusammengesucht hat. Und dass sein Team offenbar fähig war,
die Applikation gut zu strukturieren.

Kurz:
1) Sie waren die besseren Programmierer
2) Sie hatten die notwendigen Freiheien um ihre Talente auszuleben

Der Punkt 2) hat sie IMHO von den "großen" Konkurrenz-Unternehmen
abgegrenzt, und Punkt 1) hat sie von der "kleinen" Konkurrenz
(also anderen "startups") abgehoben.

Dass dabei ihre Wahl auf LISP fiel, und dass sie mit LISP ordentlich
umgehen konnten, sind IMHO nur Randerscheinungen. LISP war ein starkes
Werkzeug für sie, für das sie dankbar sind, aber ich finde es
übertrieben, LISP deshalb als "Geheimwaffe" zu bezeichnen. Ihr freier
Geist war die Geheimwaffe.

Das Design ihrer Template-Sprache, also quasi eine "DSL", wenn man so
will, nur ohne neuerfundene Syntax ... die Idee, diese Sprache anders
serialisiert (psychologisch besser geeignet, ohne Klammern, mit Einrücken)
den Kunden vorzusetzen ... oder die geniale Idee, Sessions mithilfe von
Closures zu realisieren ... all das bescherte ihnen guten, sauberen Code.

> > obwohl
> > das damals sicherlich stimmte, weil es sonst "nur" C/C++ und Perl gab,
> > obwohl eine PHP-Konkurrenz wahrscheinlich änhliche Probleme gegen den
> > LISP-Code hätte.
> > 
> > Allerdings könnte man heutzutage statt LISP auch Ruby oder Python als
> > "Geheimwaffe" bezeichnen, vorallem dank einiger DB-Abstraktions- und
> > Web-Applikations-Bibliotheken.
> 
> Du sagst, der Artikel übertreibt, erwähnst zwar daß der Artikel älter ist, 
> und es *damals* wohl eventuell gestimmt haben möge, und sagst, *heutzutage*
> sei das Blödsinn.

Nein, da hast du mich falsch verstanden. Ich meinte, auch *damals* war
die Argumentation Blödsinn, aber den Denkfehler kann man aus der heutigen
Perspektive leichter erklären:

Gäbe es heute eine ähnliche Situation, und jemand hätte - was weiß ich -
mit Ocaml sowas auf die Beine gestellt, würde er Ocaml als "Geheimwaffe"
beschreiben. Obwohl er mit LISP oder Python ähnlich gut arbeiten könnte.

LISP allein, genausowenig wie Python allein, machen noch keinen sauberen
Programmierstil aus. Das sogenannte "RAD" wäre z.B. eine Perversion der
ganzen Geschichte: Mit irgendeinem sog. RAD-Tool und schlecht gehackten
Code kann man ebenfalls von vorne bis hinten eine Konkurrenzfähige
Appliaktion in relativ kurzer Zeit erschaffen. Aber nicht mehr pflegen,
man könnte sie ab irgendeinem Zeitpunkt nur noch in die Tonne hauen.

Ihre Konzepte, ihre Ideen zur Programm-Struktur, waren IMHO das
Entscheidene. "High-Level"-Sprachen unterstützen das natürlich, aber
LISP ist da nur eine von vielen.

Für einen gegebenen Zweck könnte LISP duchaus auch die schlechteste Wahl
sein, und Python oder Ocaml viel besser sein. (z.B. in Kombination mit
einem super Framework)

> Also ist Deine Kritik an dem Artikel Unsinn!

Bitte keine Flames.

Unterstelle mir bitte erstmal ein Minimum an Intelligenz und uns beiden
die menschliche Fähigkeit, uns misszuverstehen.

Ich wollte lediglich klar machen, dass die letztendliche Ursache für
den Erfolg nicht in der Sprache liegt, sondern in den Menschen.
(Wie ich deinen anderen Mail entnehmen kann, vertrittst du eigentlich
auch diese Meinung, oder?)


Nicht nur ihre erste Entscheidung, LISP zu nehmen, sondern auch viele
andere Entscheidungen (z.B. zum Design des Programmes, der
Zwischensprache und des User-Interfaces) haben zum jahrelangen Erfolg
geführt.

Ich würde sogar soweit gehen, zu behaupten, dass sie gar kein Geheimnis
um LISP machen mussten. Hätten sie solch einen Artikel schon früher
geschrieben, und hätte das irgendeinen anderen Startup dazu verführt,
sein Zeug in LISP zu machen, auf Biegen und Brechen, weil's ja "die
Geheimwaffe" ist, wäre er hoffnungslos gescheitert. Er hätte vielleicht
die erste Entscheidung (Wahl der Sprache) gut getroffen, aber die
weiteren nicht mehr.

Außerdem ist es genau diese Denkweise, die letztlich zu solchen in
den Medien hochgepushten unhandlichen Monstern wie J2EE führt.

    "Viele Leute, die X benutzen, haben Erfolg"
Daraus folgt:
    "Wenn ich X benutze, habe ich wahrscheinlich auch Erfolg"


Das setzt zu spät an der Kausalkette an. Sie müsste IMHO eher so lauten:

    "Fähige Leute haben Erfolg"
    "Überwiegend fähige Leute können mit X umgehen"
Daraus folgt:
    "Viele Leute, die X benutzen, haben Erfolg"

Daraus folgt nicht:
    "Wenn ich X benutze, habe ich wahrscheinlich auch Erfolg"


(okay, jetzt könnte man noch flamen, dass fähige Leute leider nicht
immer Erfolg haben, aber das geht zu weit am Thema vorbei :-))


> > an die noch keine (funktionale oder OO- oder gemischte)
> > Sprache herankommt,
> 
> Lisp ist da eben konsequent - aber das macht Lisp-Programmierung auch zur Qual,
> denn die Konsequentheit äussert  sich darin, sich mit Klammer herum zu schlagen! ;-)

Nicht notwendigerweise. Siehe auch das, was ich in der anderen Mail aus
einem "Common Lisp"-Buch zitiert habe.

> > gleich
> > nach Ocaml, in das mich im Moment näher vertiefe (nicht nur ein bisschen
> > Syntax und Beispielcode angucken wie vor ein paar Monaten, als mich
> > Oliver neugierig machte).
> 
> Oh, schön, daß mein Reden nicht vollkommen ungehört verhallte...
> ...schön auch, daß Du Dir OCaml näher anschaust! :)

Das hatte ich dir schon damals gesagt.

> Und...?!  Sind schon erste Resultate Deiner Studien nennbar? :)

Kommt drauf an. Für Lowlevel-Aktionen ist es auf jeden Fall die Sprache
meiner Wahl ... weit vor C/C++/Java. Vorallem für rechenintensive Dinge,
wie zum Beispiel "Game Engines" würde ich es auf jeden Fall empfehlen.

Jedoch schein man an vielen Stellen einfach nicht um einen Code-Generator
herumzukommen. Geht es um persistente Daten und Netzwerk-Dienste, möchte
ich aber gerade davon *loskommen*, um Client und Server stark zu entkoppeln.
Dabei hilft mir im Moment nur Python (Ruby würde es auch tun, wäre aber
Umständlicher).

Andererseits benutze ich die Introspektion in Python nur für
syntaktischen Zucker. Das heißt, auch ohne die dynamischen Features von
Python könnte ich zur Not auskommen.

Mein Ziel war es ja eigentlich, das *Modell* eines Programmes bzw. einer
Datenstruktur (und nicht nur die Struktur selbst) in der Programmiersprache
zu beschreiben, um dann eben *zur Laufzeit* die Kompatibilität zu anderen
Modellen zu überprüfen (z.B. bei einer Client-Server-Verbindung), und
sie ggf. durch Fallbacks in beide Richtungen nur über die Schnittmenge
ihrer APIs kommunizieren zu lassen. Ist - wie immer - blöd zu erklären,
zumal ich von diesem Ziel noch weit entfernt bin.

Allein das Definieren eines Modells in der selben Sprache, sodass ich
auf unterschiedlichste Strukturen (GUI-Libs, SQL-DBs, Datenströme, ...)
mithilfe der selben API zugreifen kann, allein das wäre schon eine
Sensation für mich. Das geht in Python relativ gut, erfordert aber in
anderen Sprachen trotz allem einen Code-Generator.

Ocaml könnte von der Ausdrucksstärke her ebenfalls mächtig genug sein,
das werde ich danach an Angriff nehmen. Wahrscheinlich ist dort die
Implementierung des "Kerns" (also des Meta-Modells) noch einfacher als
in Python, aber um es typsicher zu machen, brauche ich ein paar
Konstruktionen, für die es in Ocaml mangels Introspektion keine
natürliche Formulierung gibt. Vielleicht irre ich mich ja auch, und
mein ganzes Konzept lässt sich auch typsicher gestalten.

Aber wenn ich um Code-Generatoren nicht herum komme, betrifft eine
Modell-Änderung ja wieder Server *und* Client. Für einfache Applikationen
wäre das sicher trotzdem noch sehr interessant, da ich mir schon dort
etliche Vereinfachungen verspreche. Aber Netzwerk-Applikationen waren ja
die *eigentliche* Herausforderung. Wäre das *typsicher* und *dynamisch*
(d.h. insbesondere kein Codegenerator), wäre das der Knüller.

Ich sehe also Ocaml als die nächste Herausforderung an. Das strenge
Typsystem wird mir helfen, mein Konzept (falls es überhaupt in Python
etwas taugt) weiter zu verbessern. Zumindest ist es die einzige
statisch typisierte Sprache, der ich zutraue, mein Konzept ohne
hässliche Hacks direkt zu schlucken.

Entweder ist Ocaml also für meine "Studien" sogar besser geeignet als
Python, oder es steht mir im Weg. Aber das herauszufinden hat noch Zeit.

Ich hoffe, das beantwortet deine Frage etwas.


> Wie findest Du das gemeine auf-die-Finger-Hauen des Compilers
> bzgl. Typen zur Compiletime?! :)

Bisher habe ich den Eindruck, dass es mich die Dinge "natürlicher"
ausdrücken lässt, wenn auch in einer etwas hässlichen Syntax.
Unangenehm aufgefallen ist mit der Compiler noch nicht, im Gegenteil:
etwas Strengeres als C/C++/Java kann ich gut gebrauchen. Gerade in der
Game-Engine für ein kleines Spiel in Python gehen momentan so einige
Zeilen dafür drauf, dass ich kein "Pattern Matching" für Strukturen
habe.

> > Das geht aber mehr in die Richtung
> > 
> >     ausdrucksstarke, schwer zu lernende Sprache mit wenigen
> >     teuren Programmierern
> > 
> > versus
> > 
> >     primitivere / weniger möchtige Sprache mit 100en einfachen
> >     Programmieren
> 
> Tja, der Kerl kommt von der Uni und hat nen hohen Anspruch;
> es geht ihm nicht um Massen-Coding!

Genau. Und diese Einstellung teile ich ebenfalls, und du, und
soweit ich weiß ein Großteil dieser Liste. Sogar die gesamte
OpenSource Community vertritt in vielen Bereichen diese Einstellung.

Große Firmen hingegen nicht, sie verfolgen AFAIK eher den anderen
Ansatz. Aber sie haben ebenfalls imense Gewinne, also großen Erfolg.
Auch das muss man anerkennen. Viele Anfänger, wenn gut koordiniert,
können ebenfalls in der Masse einiges leisten (Stichwort Emergenz).


> > Beide Ansätze sind vielversprechend, insbesondere der zweite Ansatz, bei
> > dem man nur im Kern ein wirklich gutes Team braucht und "weiter außen"
> > auch Unerfahrende oder gar Anfänger mitarbeiten können.
> 
> Ist das nicht immer so?

Naja, die Größenordnungen sind IMHO anders.

> Mythical-Man-Month geht IMHO in die selbe Richtung...?!
> So habe ich das jedenfalls in Erinnerung habe es aber, wie so oft,
> nach dem ersten Drittel abgebrochen... die Leserei).

Das Buch habe ich nicht gelesen. Aber ich habe "Der Temin" gelesen.
Da geht es auch über Projekt-Management, anhand einer einer
unrealistischen, aber sehr witzigen Geschichte. Kann ich nur
empfehlen.

> > Mittlerweile lassen sich ja vorallen in Sprache, die funktionale *und*
> > objektorientierte Programmierung vereinfachen (Python, Ocaml, Ruby, ...)
> 
> Eben, OCaml ist auch dabei, dankeschön für die Erwähnung ;-)

Wie dir aufgefallen sein sollte, war Ocaml bisher bei fast *allen*
Aufzählungen dabei.

> > viele Dinge direkt (oder zumindest trivial) ausdrücken, die vorher nur
> > als "Design Patterns" bekannt waren.
> 
> Aha, klingt ja ganz anders als "damals noch! :)

Du tust so, als hätte ich damals Ocaml schlecht gemacht. Dabei habe
ich lediglich behauptet, es sei nicht *mächtiger* als Python, Ruby, etc.

> Schön, daß Lernen bei manchen Menschen noch wichtiger ist als recht behalten!

Ich weiß leider nicht, was du meinst. Schon damals hielt ich Ocaml für
sehr interessant und lernenswert, und schon damals habe ich mich
gewundert, wieso du mir permanent das Gegenteil unterstellt hattest.
War das wegen der OO <-> FP <-> "Design Patterns" Debatte?

> Bist ja doch ganz aufgeschlosssen..... fein!

War ich schon damals. Vielleicht sind meine vielen Kritisierungen als
Ablehnungen rübergekommen. Falls dem so ist, tut mir das leid. So waren
sie keineswegs gemeint.

Ich fand, du hast die funktionalen Programmiersprachen auf einen zu
hohen Podest gesetzt, aber das heißt nicht, dass ich sie niedertrampeln
möchte.

> > Es würde mich nicht wundern, wenn
> > in LISP noch mehr dieser Patterns "trivial" erscheinen.
> 
> Ja, mit Sicherheit; aber das ist eben auch in vielen funktionlane Sprachen so!

Ja, das hatten wir schon. :-)

Aber Sprachen wie Ocaml und Python, die beide Stile erlauben, sind IMHO
mächtiger als Sprachen wie Java und Haskell, in denen sich jeweils nur
ein Teil natürlich ausdrücken lässt.

Deshalb ist LISP so interessant für mich, weil es *noch mehr* Ausdrucks-
möglichkeiten bietet, als die gängigen FP+OO Sprachen (wie Ruby, Ocaml,
Python, ...).

> Die Design-Patterns sind ja im Zusammenhang der OO-Programmierung entstanden,
> und obwohl das Vorgehen mit Recipes a la Design-Patterns ja universell ist,
> sind viele der Design-Patterns, die als solche bekannt wurden, nur durch
> die OO-Programmierung bekannt und auch notwendig geworden.

Sagen wir lieber, durch beschränkte OO-Sprachen. Python ist für mich
auch zum größten Teil OO-Programmierung, aber es wird im Gegensatz zu
Java nicht zu seiner Qual, sondern ist dank der funktionalen Elemente
sogar sehr angenehm im Mix.

> IMHO kann es keinen Sinn machen, wenn es um reale* ("realexistierende" ;-))
> Programmierung geht, die eine gegenüber der anderen Programmier-Weise ("Paradigma")
> als ausschliesslich glücklichmachende einzusetzen (und alle anderen in die Tonne zu hauen);
> es kann IMHO nur darum gehen, die verschiedenen "Idealtypen"
> ("Idealtypus" aus der Soziologie abgeleitet) zusammen zu nutzen und das, was sich einem an
> Möglichkiten bietet, auch einzusetzen.

Full ACK.

Wenn auch etwas zu kompliziert ausgedrückt. :-)

> Sprachen wie OCaml bieten einem den Vorteil, auf mehr als eines
> der "Programmierparadigmen" zurückgreifen zu können.

Python und Ruby ebenfalls.

Was OCaml als "statsich typisierte Sprache" richtig macht, macht Python
als "dynamisch typisierte Sprache" richtig. IMHO


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR