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

[Oliver Bandel]

On Sat, Jul 01, 2006 at 10:17:51AM +0200, Volker Grabsch wrote:
[...]
> * 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)
[...]
>     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).
[...]

Aha, na, das ist ja interessant.

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

IMHO ist dies noch älter und wurde nur in dem Buch vor zehn Jahren
aufgegriffen. Das ist sicherlich seit den 80ern üblich.

Allerdings gab es Lisp doch früher nur in kommerziellen Umgebungen,
und da bekommen die dann eben auch entsprchend gute Tools geliefert.
*Da* lohnt sich das Geld ausgeben noch ;-)



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

...hmhhh, tja.... was soll man dazu sagen? ;-)


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

Naja, Du siehst, man denkt da in ganz anderer Richtung.
Da geht es dann nicht mehr darum, ob man möglicherweise vergessen hat,
den Pointer auf NULL zu initialisieren usw., sondern man denkt da eher
in algorithmischen Strukturen. Das macht IMHO die Erebnisse wesentlich
besser, als wenn man sich dauernd mit dem Unterholz befassen muß.



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

Besonders bei großer Code-Basis wird das vorteilhaft sein,
weil eine von-Hand-Verwaltung zu vieler Ressourcen nicht mehr
schaffbar ist und selbst geschriebene Libs für sowas,
letztlich auch nichts weiter sind als die Reimplementierung eines GC,
bloß daß man es nicht so nennt. ;-)


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

Wenn man Müll produzieren will, kann man das natürlich auch, wenn man
die Konzepte verstanden hat. Nur weiß man dann darum ;-)



[...]
> > 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. :-)


Sorry, ich verstehe nicht ganz was Du meinst... aber ich halte es nicht immer
für Sinnvoll, Masse statt Klasse einzusetzen.

Das wäre doch genau der Massenproduktions-/Fliessband-Programmierer,
von dem Du meintest, dieses Konzept sei Dir fragwürdig.

Du meinst, wenn man 100 mal so viele Programmierer hat, hat man 10-fache
"Effektivität"?
Was ist denn Effektivität?
Und: meinst Du die steigt mit sqrt(Anzahl)?
Ertrinkt man nicht schon vorher im Chaos?

Oder hätte ich den Ironie-Detektor anschalten sollen?


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

Mir auch.


> aber ich sehe auch die
> Erfolge.

Naja, manches lässt sich eben doch formalisieren;
man denke nur mal an die Kochrezepte a la Design Patterns.

Wenn man ein Ei in die heisse Pfanne haut, weil man der Koch-Anleitung
folgte, dieses zu tun, dann bekommt man schon ein irgendwie gebruzzeltes
Ei - aber je nach Ausführung hat man Entweder ein Spiegelei oder ein
Rührei kreiert. Wenn es darum geht, ein warmes Eigericht zu bauen, dann
hat man das geschafft - schön, 0815-Programmierer-Koch hat es am Fliessband
hergestellt.
Wenn man aber ein nicht (irgend) eine warme Eimahlzeit, sondern definitiv
ein Spiegelei haben wollte und stattdessen ein Rührei bekommt,
dann kann das auch schon mal ärgerlich sein.... ;-)



> 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)
[...]

Ja, schön ausgedrückt :)

Eine Funktion, die in 6-Punkt-Schrift vier DIN-A4-Seiten füllt,
also mindestens zweistellige Anzahl von Bildschirmseiten....
.... und Code, der immer wieder neu geschrieben wird (oder mit
Copy&Paste kopiert und dann in ein paar Zeilen geändert wird...).


Oh jeh... und sowas gibt es wirklich! :(


Aber daß man nur als erfahrener (und mindestens guter) Programmierer auch
in der Lage ist, die Dinge einfach auszudrücken, das finde ich eine treffende
Formulierung der Situation.
Code-Bloat ist Anfängern und Pfuschern vorbehalten.

Gruß,
   Oliver