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

[Oliver Bandel]

Hi,


On Sun, Jul 02, 2006 at 12:38:13AM +0200, Volker Grabsch wrote:
> On Sat, Jul 01, 2006 at 01:23:03PM +0200, Oliver Bandel wrote:
> > > 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 ;-)
> 
> Ja, mag sein. Aber Gutes Zeug[tm] wird von der OpenSource-Community doch
> immer gern übernommen. Auch gute freie XML-Editoren gibt es.

Naja, vielleicht klappt das ja nicht immer.
Dafür ist Lisp eben in der OpenSource-Community zu sehr Aussenseiter...
...die paar, die sich mit Lisp intensiv beschäftigen optimieren vielleicht
lieber die Compiler und Bibliotheken?!


> 
> > > 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? ;-)
> 
> Naja, du könntest zum Beispiel sagen: "Hey, klar, kenn ich, schau dir
> mal das Projekt X an, die machen genau das, was du suchst!"
> 
> Auf solch eine Antwort habe ich zumindest gehofft. :-)

...tja, Pech gehabt, ich wusste ja keine solche Antwort.

Sonst hätte ich sie mit hoher Wahrscheinlichekti auch gegeben.


[...]
> Ich erkläre den Gedanken nochmal:
> 
> Du hast ein Projekt mit etlichen Programmierern. Jetzt nimmst du 100 mal
> so viele, aber dafür schlechtere Programmierer und/oder schlechtere
> Sprachen und Werkzeuge. Dies führt dazu, dass die Programmierer viele
> redundante Arbeit leisten müssten, weil sie sie nicht wegabstrahieren
> können (weil es unfähig sind, weil die Sprachen/Tools es nicht ermöglichen,
> oder weil die Chef-Programmierer es nicht gestatten). Deshalb müssen sie
> jedes Rad 10 mal neu erfinden, sind also 10 mal langsamer. Statt 100 mal so
> viel zu leisten, leisten die Programmierer also nur noch 10 mal so viel.
> 
> Aber immerhin: 100 mal so viele Programmierer, aber noch 10 mal so viel
> Effektivität.
> 
> Die Effektivität verzehnfacht sich also, die Effizienz hingegen wurde
> gezehntelt. Aber egal, 10 mal so viel Leistung, und man hat ja die
> Massen an Programmierern zur Verfügung. Und sie waren vielleicht sogar
> billiger, als würde man 10mal so viele, aber dafür gute, Programmierer
> nehmen.
> 
> So war obige Aussage gemeint. Aber natürlich nicht im Ernst. :-)


Naja, wie war das mit Swarum-Intelligence und GA...
... vielleicht sind viele der Implementierungen Schrott, aber wenn
ein paar davon gut sind, reicht das vielleicht schon? ;-)

(Nicht ganz unernst gemeint, aber auch nicht wirklich als sinnvolle
 Strategie - jedenfalls nicht, ohne daß man das mal untersucht, ob
 das funktionieren würde.)



> 
> (... weil ich glaube, dass der "Reibungsverlust" durch redundante
> Arbeit in der Masse nicht linear, sondern exponentiell ansteigt.
> Und weil auch bei den besten Programmierern noch Reibungsverluste und
> Einarbeitungszeiten hinzukommen. Das ist natürlich nur geraten, wenn
> da jemand mehr Ahnung hat, würden mich Ausführungen zu dem Thema sehr
> interessieren.)

Mythical Man Month: da geht es ja genau darum!

Man denkt sich: verdreifachen der Programmiererzahl bringt dreifache Leistung.

Stimmt aber eben nicht, wegen Kommunikations-Overhead und anderem,
was Du wohl als "Reibungsverluste" benennst.

Es gibt Untersuchungen über die "Produktivität" von Programmierern.
Am Anfang ist sie recht hoch und mit steigender Zahl bereits vorhandener
Zeilen Quellcodes (purer Programmcode, also nicht die Kommentarzeilen)
flacht die Kurve ab.

Das ist IMHO DER HAUPTGRUND, wieso man in der Software-Entwicklung nicht
an Sprachen wie OCaml und ähnlichen vorbei kommt: Wenn man weniger
Zeilen braucht, um ein Programm zu schreiben, ist auch die Sättigung
der Zeilen Quellcode/Programmierer erst bei wesentlich komplexerer
Software erreicht!
Anderer Grund: compiletime-Prüfungen der Typen.
Wenn man nicht unbedingt dynamische Eigenschaften einer Spraqche braucht,
oder diese nicht *hauptsächlich* für ein Projekt braucht, sondern nur
für ein paar Teilbereiche, dann bringt strikte Typprüfung zur Compilezeit
den Vorteil extrem verringerter Debugging-Zeiten.

Man kann dann also komplexere Dinge in kürzerer Zeit schaffen,
und durch Multiparadigmen-Sprachen wird man dabei ja auch noch
unterstützt, weil man einfach mehr Möglichkeiten hat, etwas
auszudrücken in der Weise, wie es am sinnvollsten Möglich ist,
anstatt drum herum zu sprechen (mit weniger aussagekräftigen
Sprachen).


 
[...]
> > 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! :(
> 
> Da kann ich einen drauf setzen: Mir wurde - vor Jahren - mal Code
> gezeigt, an dem unter Zeitdruck gearbeitet wurde. Als Abschreckung.
> Nicht nur alles Copy & Paste & kleine Änderungen. Nein, mir wurde
> auch gezeigt, auf welche Weise dort Bugfixing vor sich ging:
> 
> Man nehme eine (sehr komplexe) Routine, in der ein Fehler gefunden ist.
> Der Fehler tritt bei bestimmten Parametern XYZ auf. Die Routine wird
> dann wie folgt abgeändert:
> 
>     def Routine (Paramamter)
> 
>         Wenn Paramter = XYZ
>         Dann:
>             <neuer Code, sodass bei XYZ das richtige Ergebnis kommt>
>         Sonst:
>             <alter Code>
> 
> 
> Das heißt, die Routine wird einfach immer komplexer gemacht, statt nach
> der tieferen Ursache zu suchen und ggf. verwandte Bugs gleich mit auszu-
> märzen. Denn man hat ja keine Zeit, und durch den alten Code kann sowieso
> keiner mehr durchsehen.

Oh jeh; naja, das ist immerhin der pragmatische Weg, das irgendwie noch zu handhaben. ;-)

Immerhin würde eine Änderung dees alten Codes ja auch die Möglichkeit
weiterer Probleme heraufbeschwören können!

Besser wäre halt neu schreiben - aber was, wenn da so viele Fallstricke
sind, daß man statt einigen zehn oder einigen Hundert Zeilen dann
bei der Änderung feststellt, daß die gesamte Codebasis - die ja wesentlich
umfangreicher sein kann - marode ist?
Und daß man dann wirklich mehr kaputt macht als man gerade biegen kann?
Dann müsste *alles* bearbeitet werden.... => rewrite from scratch!

So gesehen ist dieses Vorgehen verständlich, in gewisser Weise auch
sinnvoll, auch wenn es eigentlich vollkommener Unsinn ist, dies so zu machen.


Aber angenommen, die SW strotzt nur so vor globalen Variablen, oder
hat auch ohne selbige vielleicht zu viele Nebeneffekte?! => nicht handhabbar!

DAS spricht IMHO für funktionale Sprachen: Nebeneffekte ade.
Und für statische Typisierung: das Interface steht, und wenn die
Implementierung geändert wird, würden bei versehentlicher
Typ-Änderung die Sourcen gleich nicht akzeptiert werden!

Ich denke sogar, daß in dem Projekt, das Du da oben nanntest,
die meisten Probleme dadurch entstanden sind, daß es eben keine
so rigide Typprüfung wie z.B. i OCaml gibt!

Meiner Erfahrung nach ist das absolut hilfreich, wenn der Compiler
streng ist, bei der Typprüfung. Vieles, was in C kaum aufgefallen
wäre (oder allenfalls eine Warning wäre, wenn man alle anschaltet),
wird von OCaml's Compiler gleich abgeschmettert!
Und wieder ein Bug vom Compiler abgefangen! :)

Das Pfuschen fällt da schwerer, deswegen werden solche Sprachen sicherlich
von dem AverageProgrammer eher mit Abneigung betrachtet; und Schusselfehler
des guten Programmierers werden leich erkannt, und deswegen finden Leute,
die da guten Code schreiben wollen (und dies auch wirklich wollen und
es nicht nur behaupten), sowas dann gut.

> 
> Um was für Software es sich handelte, und wo diese eingesetzt wurde,
> behalte ich lieber für mich ...

Na, sicherheitsrelevante SW?
KKW, Flugzeug, Bahn?!

Auch in dem Umfeld habe ich schon schlimmes gesehen - nicht was den Code
angeht, aber die Testtools!

[...]
> > 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.
> 
> Ja, eben. Sehr gut passt in diesem Zusammenhang auch der Spruch:
> 
>     Man sagt, nur 10 Menschen hätten Einstein wirklich verstanden.
>     Niemand versteht mich.
>     Bin ich ein Genie?
> 
>     ;-)
> 

heheh, der ist aber gut! :)


Gruß,
   Oliver