Literarisches Programmieren
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Dieser Begriff wurde von Donald E. Knuth in einem Artikel in `The Computer Journal´ 1984 geprägt. Es handelt sich hierbei um eine Programmiermethode, die eine Stufe über der strukturierten Programmierung steht. Eine nähere Einführung dazu gibt u.a. in der c't 10/1990, Seite 340.

ToDo: Eine etwas ausführlichere Beschreibung von LiterarischesProgrammieren an dieser Stelle wäre schön.



Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.

I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.


Interessant ist in diesem Zusammenhang eine Parallele zur Entwicklung von C. DonKnuth ist ja vor allem durch zwei Dinge bekannt, durch sein mehrbändiges Standardwerk TheArtOfComputerProgramming und die SpracheTex. Wenn ich mich richtig erinnere, war er im Laufe seiner Publikationstätigkeit immer wieder mit unzulänglichen Satzsystemen konfrontiert, was ihn dazu bewog sein eigenes Satzsystem zu entwickeln. Die Arbeit war allerdings schwieriger als angenommen, erforderte auch eine komplette Neuentwicklung im Font-Bereich namens MetaFont, um auch alle Kerning-Probleme bis ins Letzte lösen zu können und warf ihn bei seiner Publikationstätigkeit um 10 Jahre zurück. Das LP ist quasi ein "Abfallprodukt" dieser Entwicklung und (die Parallele zu C) für den Eigenbedarf in Verbindung mit einer Herkules-Aufgabe entstanden. -- HelmutLeitner


Frage:
Warum hat sich eigentlich LiterarischesProgrammieren, trotz der Authorität von DonKnuth und der Beliebtheit von TeX nicht etablieren können?

Eine mögliche Antwort:
LiterarischesProgrammieren ist ja eng an Werkzeuge dazu gebunden, die die Generierung von Programm und Dokumentation aus einer Quelle übernehmen. DonaldKnuth hat eine selbstgestrickte, wenig verwendete und schon zur Zeit ihrer Entwicklung recht archaische Sprache verwendet. Später war Objektorientierung angesagt, und die Sprache ging noch mehr an der Realität und den Bedürfnissen vorbei. Heute ist die Softwareentwicklung sehr auf graphische Notationen wie UML fixiert und textuelle Beschreibungen auf dem absteigenden Ast, so daß selbst ein Literate Java nicht viele Chancen hätte. Programme werden auch zunehmend zu groß, um sie als Buch gebunden herausgeben zu können. Aber wer weiß. -- OlafKummer

Die graphische Orientierung ist die eine Entwicklung (von der ich allerdings kein besonders großer Fan bin); die andere Richtung (die ich z.B. in ExtremeProgramming vertreten sehe) anerkennt durchaus, dass textueller Quellcode ein mächtiges (angemessenes) Werkzeug darstellt, wenn man es richtig verwendet. Beiden Bewegungen scheint mir jedoch gemein zu sein, dass die Problematik nicht automatisch validierbarer Dokumentation erkannt und bekämpft wird. So bemühen sich die einen, ihre UmlDiagramme? direkt ausführbar zu machen, während die anderen versuchen, die beim Literarischen Programmieren noch immer vorhandene Trennung zwischen Dokumentation und Quellcode vollkommen zu überwinden und den Quellcode (und dazugehörige Tests) selbstdokumentierend zu gestalten. Letzteres führt, nebenbei bemerkt, fast zwangsläufig zu einem VieleKleineTeile - Design (was mir beim Literarischen Programmieren ebenfalls der Fall zu sein scheint).

Der Punkt mit der Objektorientierung ist meines Erachtens auch nicht unwichtig - ein objektorientiertes Programm lässt sich kaum noch in einer linearen Art und Weise lesen, vielmehr handelt es sich um ein Netzwerk von Klassen/Objekten die miteinander kollaborieren, in dem man also je nach aktuellem Interesse sehr unterschiedlich navigieren kann/muss. Als ein Vorteil der literarischen Programmierung scheint mir häufiger angeführt zu werden, dass die Struktur des Programms im Normalfall gut den historischen Ablauf seiner Entwicklung wiederspiegelt; mir scheint das aber keineswegs eine erstrebenswerte Struktur zu sein (außer vielleicht für akademische Belange) und dem Konzept des konsequenten CodeRefactoring sehr im Wege zu stehen. -- IljaPreuß


Bei der Übersetzung von "literate programming" mit "literarisches Programmieren" sträuben sich mir die Nackenhaare. Nach meinem Wörterbuch heißt "literate" auf deutsch "gebildet", und "literarisch" heißt auf englisch "literary".

Soviel ich verstanden habe, ging es D. Knuth um eine Steigerung des Begriffs "Strukturierte Programmierung". Da mir "Gebildete Programmierung" auch nicht sehr sympathisch ist, würde ich eher für eine freiere, mehr Knuths vermutliche Absicht widerspiegelnde Übersetzung mit "Superstrukturierte Programmierung" oder "Hyperstrukturierte Programmierung" plädieren. Letzteres würde zugleich ganz passend auf die diesbezüglichen Hypermedia-Ansätze anspielen. Am besten sollte man wahrscheinlich in diesem Fall auf eine Übersetzung überhaupt verzichten. -- KlausGünther

Ich glaube schon, dass die Übersetzung den Intentionen von DonKnuth entspricht. Siehe oben eingefügtes Zitat. -- HelmutLeitner

Trotz dem recht blumigen Vergleich des Programmierers mit einem Essyaisten spricht Knuth aber dennoch nicht von "literary programming", sondern von "literate programming". Wie schon oben angedeutet, sehe ich keine wirklich befriedigende und genaue Übersetzung dafür; "literarisch" erscheint mir einfach zu hochgestochen. Aber es ist nicht schlimm, wenn sich mir weiterhin die Nackenhaare sträuben.

Überhaupt halte ich den Vergleich des Programmierers mit einem Essayisten für unglücklich, weil ich mich mit Grausen daran erinnere, was man alles in einen Roman hineininterpretieren kann, wie wir alle aus unserem Deutschunterricht wissen.

Ich denke vielmehr, dass die Qualität eines Programms um so höher ist, je selbst-verständlicher es ist, also je weniger zusätzliche "literarischen" Anstrengungen man unternehmen muss, um es anderen zu erklären. Aus heutiger Sicht, denke ich, sollte das Ziel vielmehr sein, komplexe und erklärungsbedürftige Lösungen nicht in einzelnen Programmen zu verstecken und in deren Dokumentation fallbezogen zu erklären, sondern als wiederverwendbare DesignPatterns zu etablieren und nach den dort inzwischen entwickelten Regeln zu dokumentieren und zu erklären und in umfassendere einschlägige Pattern-Sammlungen oder "Pattern-Languages" einzuordnen. In dem konkreten Anwendungsfall würde man dann nur noch darauf verweisen.

Daran schließt sich für mich dann sofort die Frage an, wie man es vermeiden kann, dass jeder, der ein solches dokumentiertes Pattern wiederverwenden will, es noch einmal von Grund auf neu implementieren muss. Obwohl es ein geheiligtes Prinzip der Pattern-Community ist, dass Patterns unabhängig von konkreten Programmiersprachen in natürlicher Sprache definiert werden, kommt man auf die Dauer aber sicher nicht darum herum, direkt benutzbare, spezialisierbare Basis-Implementationen in konkreten Programmiersprachen bereitzustellen, wofür es in diesen aber besser geeignete Ausdrucksmittel geben sollte, als derzeit der Fall.

In SpracheLava haben wir einiges unternommen, um dies zu erreichen. Zum Beispiel spezialisierbare Packages mit Typparametern ("Virtual Types"), strikte Trennung von Interface und Implementation einer Klasse, beliebige ("semantik-freie") Schachtelung von Deklarationen, Baumdarstellung von Deklarationen mit auf- und zuklappbaren Unterbäumen, etc.. -- KlausGünther

Laut dem LeoWörterbuch bedeutet literate in etwa: belesen, gebildet, literarisch gebildet. Es scheint also doch auch einen literarischen bezug zu haben; "Gebildete Programmierung" wäre (wie schon oben erwähnt) demnach auch nicht zufriedenstellend. -- ThomasHolenstein

Im Englischen stehen sich litera (letter) - literate - literature als Schriftzeichen - Schriftkundig=gebildet - Schrifttum=Literatur einander lautmäßig und bedeutungsmäßig sehr nahe. Eine Nähe, die sich im Deutschen nicht erzeugen lässt. --hl

Von der Übersetzungsproblematik abgesehen scheint das "literate programming" nur ein geringfügiges akademische Leben zu haben, das sich hauptsächlich aus der Authorität von DonKnuth ableitet. Die angestrebte Form der Strukturierung fördert IMO weder selbstdokumentierenden Code (System dient der expliziten Dokumentation), noch der Wiederverwendung von Komponenten (die nur auf der Sourceebene gebildet werden). -- hl

Ich stimme Klaus Günther zu, die Bezeichnung "literarisches Programmieren" kommt mir auch etwas zu hochgegriffen vor. Es gibt zwei Punkte, die mir dabei wichtig erscheinen:
Die Übersetzung des Begriffs müsste in meinen Augen beide Aspekte berücksichtigen. Hier einige Vorschläge:

-- ChristianSmietana


Siehe WardsWiki:LiterateProgramming WardsWiki:BarelyLiterateProgramming


KategorieDokumentation
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 21. Oktober 2004 16:23 (diff))
Suchbegriff: gesucht wird
im Titel
im Text