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

[Volker Grabsch]

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.

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

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

Und dass diese Reimplementierung wahrscheinlich fehlerhafter *und*
weniger effizient ist, als die fertig, gereiften GCs.

> [...]
> > > 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.
[...]
> Oder hätte ich den Ironie-Detektor anschalten sollen?

Ja, die Aussage war ironisch gemeint. Sie sollte die Denkweise darstellen,
die ich Managern großer Software-Firmen unterstelle. Natürlich kann es
sein, dass ich den Managern damit unrecht tue, also bitte nicht zu ernst
nehmen.

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

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


[Software-Entwicklung als Fließband-Produktion]
> > 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,
[...]

Nette Analogie. :-)


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

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

Ich kann dir also nur beipflichten: Ja, sowas gibt's 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.

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?

    ;-)


Viele Grüße,

    Volker

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