[linux-l] Mächtigkeit von LISP (war: Geschwindigkeit von DB)

Volker Grabsch vog at notjusthosting.com
Sa Jul 1 10:17:51 CEST 2006


On Sat, Jul 01, 2006 at 10:24:42AM +1000, Peter Ross wrote:
> On Fri, 30 Jun 2006, Volker Grabsch wrote:
> 
> >   ausdrucksstarke, schwer zu lernende Sprache
> 
> ;-) Ich habe ein paar Wochen im Studium LISP gehoert, und ich muss sagen, 
> dass ist die einzige, gegen die sich mein Kopf irgendwie gewehrt hat. Ich 
> habe keinen Platz gefunden, um in der Klammerwueste sanft zu landen.

Ich muss sagen, mir ging es anfangs mit jeder Sprache so. Ich brauche
immer eine gewisse Zeit, um mich an die neue Syntax zu gewöhnen. Auch
Assembler, C, Python und Ocaml sahen mir anfangs immer äußerst "komisch"
aus, bis ich genug Code gelesen hatte, um es zu verinnerlichen.

Wenn man LISP erst einmal nur als "s-expressions" betrachtet, mag das
zwar ein sehr merkwürdiger Klammerwust zu sein. Und ich persönlich würde
auch stets Python-Syntax, JSON oder YAML vorziehen. Aber Tatsache ist:
Diese 3 Syntax-Vorschriften sind bei großen Konstruktionen
(Datenstrukturen) genauso übersichtlich wie "s-expressions".

Aber wir alle wissen, in welcher Form große Datenmengen gespeichert
werden, die noch menschlenlesbar sein sollen: XML. So groß der Klammer-
Wust von LISP auch sein mag, die Tag-Klammern in XML sind um einiges
nerviger. Ja, manchmal sind Wiederholungen des Tag-Namen sinnvoll, zur
besseren Übersicht, aber meistens schaden sie derselben nur.

Also, was für eine geniale XML-"Erfindung" gibt es da? XML-Editoren.
Dort sieht man die Struktur des Dokumentes und wird vom hässlichen
Quellcode ferngehalten. Ist diese Idee irgendwie neu?

Vor Jahren habe ich mir mal das Buch "Common Lisp" gekauft.
(2. Auflage, Otto Mayer, Spektrum Verlag)
Damals war es nur aus Neugier. Die Qualität des Buches kann ich nicht
einschätzen. Zwar hab ich den Inhalt überwiegend verstanden, aber die
wirklich "coolen" Sachen von Lisp (Makros, ...), und Dinge wie GUI-
Bibliotheken etc. stehen dort nicht drin. Damals hat es mich gelangweilt,
aber die Grundgedanken, die ich dort mitgenommen habe, haben mir später
beim Erlernen von anderen Dingen geholfen.


Wie auch immer, in diesem Buch von 1995 habe ich aus Interesse mal
wieder herumgeblättert. Auf Seite 307 geht es um Programmier-
Entwicklungs-Systeme. Dort werden zwei Arten von Editoren für LISP-
Code erwähnt:
* strukturorientiert (auch: syntaxorientiert)
* bildschirmorientiert (auch: zeichenortientiert)

Ein bildschirmorientierter Editor wird dort im Wesentlichen als das
beschrieben, was wir unter einem Texteditor mit Syntax-Hervorhebung
kennen, mit ein paar netten Features wie "Springe zum nächsten
Ausdruck/Term" bzw. "springe zur zugehörigen anderen Klammer".

Zum strukturorientierten Editor schreibt er:  (Zitat)

    Beim sogenannten strukturorientierten Editor orientiert man sich
    bei der Eingabe des Programms, beim Navigieren im Program und bei
    der Modifikation an der Listenstruktur, also der LISP-Syntax. Das
    vom Editor zu einem bestimmten Zeitpunkt bearbeitete Teilstück des
    Programmes, also der gerade zu editierende Term heißt Edit-Form des
    Programms. Typischerweise verfügt ein "Struktureditor" über Befehle:

        * zum Wechsel des zu bearbeitenden Bereichs, also der Edit-Form

        * zum Suchen in der Edit-Form und zum rekusiven Aufruf des
          Editors für Teile derselben

        * zur Modifikation der Edit-Form

        * zum Rückgängigmachen der Edit-Form

        * zur Ausgabe der Edit-Form in übersichtlicher ggf. verkürzter
          Darstellen (mit beschränkter Schachtelungstiefe)

        * zur Auswertung von Teilformen durch den Interpreter

        * zur Definition neuer Editierkommandos (als Makros für
          bestimmte Kombinationen vorhandener Editierkommandos)

    Bei strukturorientierten Editoren fehlen typischerweise Kommandos,
    um auf einzelne Zeichen, Zeilen oder Bildschirmbereiche zuzugreifen,
    wie dies von Texteditoren her bekannt ist.


Das heißt, der Klammerwust ist eigentlich gar nicht charakteristisch für
LISP, sondern nur eine (gängige) Form der Serialisierung. Genauso wie
XML auch nicht dafür bestimmt ist, komplett über einen Text-Editor
eingegeben zu werden (sondern nur teilweise). Es geht eigentlich nur
über die Struktur des Codes, und darum, dass die Meta-Struktur von
Programm-Code und Daten identisch ist (nämlich verschachtelte Listen).

Daraufhin habe ich etwas herumgesucht, wurde aber leider nicht fündig.
Gibt es einen guten strukturorientierten Editor (im Sinne der obigen
Definition) für LISP? Zuerst dachte ich an Emacs, aber AFAICS ist der
ziemlich genau das, was unter einem bildschirmorientierten Editor
verstanden wird.

Wenn schon vor 10 Jahren solche Editoren "Stand der Technik" waren,
wie weit müssen sich sich bis heute entwickelt haben? Sie müssten doch
schon längst jedem XML-Editor überlegen sein.


> Kann man das in Java tunen? Kaum.. Programmierer muessen sich ja dank 
> Muellabfuhr um Speicher nicht mehr kuemmern

Das finde ich eine Gute Sache[tm], aber man sollte das, was man nicht
mehr braucht, zumindest nicht mehr referenzieren. Ein bisschen Mitdenken
ist immer wichtig.

Sonst könntest du auch Sprachen wie Haskell und LISP vorwerfen, dank
ihnen müsse sich der Programmierer keine Gedanken mehr um Rekursionen
und ähnliches machen, da ihnen der Compiler/Interpreter viele Arten
von Rekursion "glättet".

Das entbindet aber nicht vom Nachdenken, z.B. die Fibonacci-Folge nicht
mit zwei, sondern nur mit einem Rekursionsaufruf zu berechnen.

Von daher würde ich nicht so auf den GC schimpfen. Der ermöglicht in
vielen Fällen wesentlich einfachere Programm-Konstrukte, die fast
genauso effizient wie "hand geschriebener" Code ist. Selbiges mit
Erkennung von "tail recursion" und ähnlichem Zeugs.

Dass man, wenn man diese Konzepte nicht wirklich verstanden hat, auch
Müll produzieren kann, ist gar keine Frage.


Das einzige, was wirklich ansteigen kann, ist der Cache. Aber dafür
gibt es in Python und Ruby, aber AFAIR auch in Java, so etwas wie
"schwache Referenzen", die trotz ihrer Referenzierung vom GC freigegeben
werden dürfen. Alternativ kann ein Programm natürlich seinen Cache
selbst verwalten, aber das wird bei nichttrivialen Anwendungen ein
imenser Aufwand, den man lieber an den GC übertragen sollte.

Zusätzlich gibt es dann noch die sog. "Application Server", sowohl
die vielen berühmten für Java, als auch für andere Sprachen. Diese
Systeme kümmern sich (neben Sicherheit, Daten-Persistenz, ...) auch
um das Caching, das heißt, dass nicht zu vielen Objekt-Instanzen
herumfleuchen, indem die Objekte (genauer: Komponenten) den
Kontrollfluss an den AppServer abgeben.

(Bevor ich mir hier Schläge einhandele: Ich persönlich finde AppServer
totalen Overkill, aber habe andererseits noch nie damit gearbeitet.
Ich finde, all diese Probleme, die ein AppServer angeht, sollten an
anderer Stelle angegangen werden. YMMV. Das sollte also keineswegs
Werbung für J2EE werden.)

> Wahrscheinlich sind die teuren Programmierer wichtiger als die Sprache. 

... oder die Anzahl der Programmierer wichtiger als die Qualität der
Sprache. Lieber das Rad 10 Mal neu erfinden, aber dafür 100 mal so
viele Programmierer einstellen. Steigert die Effektivität auf das
10fache. :-)

Nee, keine Ahnung, wieso in diese Richtung gegangen wird. Vielleicht
sehen viele Firmen die Software-Entwicklung als eine Fließband-
Produktion und nicht als wissenschaftliche/kreative Arbeit. Mir
persönlich ist diese Sichtweise suspekt, aber ich sehe auch die
Erfolge. Außerdem sollte es im Interesse *jedes* Programmierers
liegen, Code zu schreiben, der von anderen, auch Anfängern, verstanden
werden kann. Unnötig komplizierten Code zu schreiben, *das* kriegt
nämlich jeder Anfänger hin. (und entsprechend Buggy ist das Zeugs dann)

> P.S. Soll nicht heissen, dass bei mir auf Arbeit alle Entwickler Stuemper 
> sind. Gott sei Dank nicht. Da gibt's einige, die koennen sogar mit Java 
> gut umgehen;-)

Ich kenne auch Leute, die mit PHP sehr gute und stabile Web-Anwendungen
schreiben können. Meist über ein selbstentwickeltes Framework, das sie
von den schlimmsten Ekelhaftigkeiten etwas befreit. Und zumindest läuft
der Code nahezu "überall".


Viele Grüße,

    Volker

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



Mehr Informationen über die Mailingliste linux-l