Diskussion:Literate Programming

AppleScript

Nur eine kleine Frage, gehört AppleScript auch zu den literarischen Sprachen? Von der Beschreibung her irgendwie schon... --Der Messer ^{?! - Bew} 15:36, 26. Feb. 2011 (CET)

Nein, seh ich nicht so. Auch, wenn das grobe Ziel (lesbarer Code) ähnlich ist. Aber der Weg ist anders: Literate Programming zielt darauf ab, Doku *im* Code zu haben (also zusätzlich zum Code im selben File) und AppleScript will *lesbaren Code* haben (unabhängig von der Doku). --Der Hâkawâti ✉ 20:55, 26. Feb. 2011 (CET)

Falscher Freund

Das Wort "literarisch" bedeutet im Deutschen etwas völlig anderes als "literate" im Englischen. Es handelt sich also um einen falschen Freund. Trotzdem ist die Übersetzung "literarisches Programmieren" nicht falsch, allerdings sehr frei.--BerlinSight (Diskussion) 00:07, 20. Jan. 2013 (CET)

knitr

Spricht etwas dagegen Knitr bei der Software mit aufzulisten? (nicht signierter Beitrag von Christian Buhtz (Diskussion | Beiträge) 17:12, 26. Okt. 2014 (CET))

Wo steht das Jupyter Notebook

Als fast schon Standardtool im wissenschaftlichen Betrieb fehlt es hier wohl bisher(?).

Haskell-Programme umordnen

Die (Top-Level-)Deklarationen in einem Haskell-Programm lassen sich frei umordnen. Was ist mit der Bemerkung gemeint, dass man ein Haskell-Programm nicht umordnen könne? DrLemming (Diskussion) 11:00, 13. Okt. 2018 (CEST)

Naja, bei echtem literate programming gibt die Textstruktur der Erzählung, der Beschreibung die Positionen und damit Reihenfolge alle wirksamen Quellcodefragmente vor.

Daraus folgt, dass die Abfolge aller Statements frei angeordnet werden dürfe und sie durch irgendeinen Zaubertrick in die problemangemessene Reihenfolge gebracht werden würden.

Wenn das nur für Deklarationen (die sich vermutlich noch irgendwie herausfiltern und an den Anfang schieben ließen [„hoisting“]) geht, aber nicht für den Rest, dann passt die Methodik halt nicht zu Haskell, wie zu sehr vielen anderen Sprachen ebenfalls nicht.

Für mich als Programmierer ist diese Reihenfolgeänderung ohnehin mehr Hindernis als Hilfe. Ich will an den Beginn der Software-Einheit gucken und dort übersichtlich alle Deklarationen lesen, die sich auf den Bereich auswirken.

LG --PerfektesChaos 12:41, 9. Dez. 2019 (CET)

Essig und Wein

Ich habe ein Dutzend Jahre mit wechselnder Intensität per Javadoc und proprietärer Auswertungstools mit dieser (bzw. verwandter) Technik gearbeitet, wende sie bis heute im Wiki-Bereich an.

Das ist nicht ganz das, was literate programming ursprünglich und eigentlich meint, aber die Grundproblematik ist gleich, genauso mit dem häufigeren Fall Software-Dokumentationswerkzeug.

• Es ist eine super-super-Sache, sofern es um Einzeiler in englischer Sprache für die Methodenfunktionalität, einzelnen Parameter und Paketbeschreibungen geht.
  • Als Programmierer sieht man direkt im Quelltext der Methode die Anforderungen und Bedeutungen der Methode und deren Einzelparameter und kann beide im selben Edit in Einklang bringen.
  • Nach Generierung etwa von HTML erhält man kompakte Übersichten mit Paketbeschreibung, kompakte Funktionsübersicht der Methoden, danach vertiefend Details zu einzelnen Parametern. Als HTML im Browser oder mittels anderem Rendering navigierbar, klickbarer Hypertext, durchsuchbar, generierte Indexlisten.
  • Generische Dokumentation und Programmcode sind untrennbar vereint in derselben Versionierung; beim Exportieren auf andere Dateisysteme ist beides zwangsläufig synchron.
• Es versagt völlig, sofern es darüberhinaus geht:
  1. Mehrsprachige Dokumentation
  2. Komplexeres Markup, Aufzählungen, Grafiken mit Schemata, mathematische Formeln, Anmerkungen und Hintergrundinformationen.
  3. Quellcode unterliegt einem Review-Prozess, mehrerer Reviewer, Sicherheitsanalyse und Tests, Upstream-Update.

Grundsätzlich ist es syntaktisch möglich, in den Quellcode auch HTML für ein kleines <em> in HTML aufzunehmen, etwas farbig zu gestalten und URL anzugeben.

• Praktisch führt das aber für eine über einen knappen Ein- oder Zweizeiler hinausgehende Beschreibung der Hintergründe zu fünf Zeilen wirksamem Programmcode, ersaufend in fünf Bildschirmseiten integrierter Dokumentation.
• Völlig kaputt geht das bei vielsprachigen Dokumentationen, also nicht nur Englisch, sondern ein Dutzend Sprachen und beliebig viele mehr.
• Wobei die Programmierer die Übersetzungen in andere Sprachen ohnehin nicht verstehen und die fachliche Richtigkeit nicht überblicken; sich auch auf ihren Code konzentrieren und nicht auf das HTML-Markup auf den Bildschirmkilometern dazwischen achten; damit aber überhaupt nicht mehr die Synchronisierung von wirksamem Programmcode und textlicher Beschreibung sicherstellen.

Für eine Änderung des Quellcodes ist Entwicklerzugriff erforderlich, alternativ die Möglichkeit zum Einreihen von Patches in eine Review-Queue.

• Heißt für jeden Tippfehler, jede korrigierte URL, jede verbesserte Formulierung und kleine Ergänzung einen Riesen-Aufwand.
• Zwei Gutachter müssen die Unbedenklichkeit überprüfen, außerdem die inhaltliche Richtigkeit.
• Es entsteht eine neue Programmversion, obwohl sich am wirksamem Programmcode nichts geändert hat.
• Die neue Programmversion bedarf eines Neuaufbaus aller abhängigen Systeme, Bibliotheken, Produktiv- und Entwicklervarianten, obwohl sich am wirksamem Programmcode nichts geändert hat.
• Die Einsichtnahme in den wirksamem Programmcode unterliegt ggf. Geheimhaltungsregeln, die für einen größeren Personenkreis von Übersetzern der Texte und Gestaltern nicht gilt; die Dokumentation wird womöglich sogar offen ins Netz gestellt. Damit bekommen aber die technical writer vollen Lesezugriff auf die gesamte vertrauliche Programmierung.

Eine Lösung ist es, eine interne knappe englischsprachige Kurzbeschreibung zu generieren und verfügbar zu machen, die dann sehr synchron mit dem momentanen wirksamen Programmcode sein dürfte.

• Diese kann dann wiederum inhaltlich synchronisiert werden mit den separaten Übersetzungen und den vertiefenden Hintergrundbeschreibungen, ohne die kurzgefasste Methoden-, Feld- und Parameterinfos absolut unbrauchbar bleiben müssen – welche nur für beteiligte Entwickler und Insider verständlich sind.
• Die Pfad- und Verzeichnisstruktur der zusätzlichen Dokumentation muss die der Quellcodes exakt nachbilden. Idealerweise liegen beide im selben Verzeichnis, was jedoch aus Sicherheitsgründen und in verteilten Systemen oft nicht möglich ist; Lesezugriffe auf einen gesicherten Quellcodebereich lassen sich leicht überwachen, während für die abgeleiteten Dokumentationen in einem physisch separierten System großzügigerer Schreibzugriff gegeben sein kann. Quellcodes stammen womöglich gar nicht aus einem klassischen Dateisystem, sondern eher aus einer komplexen Datenbank.

Sodele, das kann in Kurzfassung gern im Artikel erwähnt werden, aber externe Belege habe ich keine, sehe das jedoch als self evident an; vielleicht hatte mal irgendwer was dazu publiziert. Die Problematik ist grundsätzlicher Natur.

• Allgemein taugen derartige Konzepte wie literate programming im Original immer nur für recht triviale, kurze Programme und Quellcodes; bei komplexen Systemen mit vielen beeinflussenden Parametern und komplexer Wirkung geht es irgendwann nicht mehr – wobei die herkömmliche Vorgehensweisen dann auch nicht grad einfach zu verstehen sind.

VG --PerfektesChaos 12:34, 9. Dez. 2019 (CET)

Beschriebenes Programmieren

@Jakob5: Könntest du für deine Eindeutschung bitte Belege bringen, Google lieferte nur unseren WP-Artikel, der englische Fachbegriff allerdings etliche Treffer. Ich habe die Weiterleitung durch meine Verschiebung bestehen lassen. Ich möchte untern in WP einen deutschen Begriff etablieren, den es außerhalb unserer Blase nicht gibt. --Paintdog (Diskussion) 19:03, 12. Dez. 2023 (CET)

Die Rückverschiebung war okay.

Schon der Begriff „Literate Programming“ ist englischsprachig wie deutsch ziemlich randständig, und das Konzept ist nicht die große Offenbarung.

Eine von uns erfundene Eindeutschung eines Nischenthemas wäre glatt TF.

Das Problem mangelhaft dokumentierter Software ist allgemein bekannt und ohne Durchsetzung von Standards mittels des Managements nicht zu lösen.

• Fehlende Doku ist eine Arbeitsplatzgarantie; wenn die mich rausschmeißen, wird niemand mehr durchblicken.
• Das Management ist meist zu faul und schwebt in höheren Sphären, statt Code zu lesen und dann noch qualifiziert zu beanstanden und Arbeitsstunden für nachträgliche Doku zu bezahlen. Soll doch sein Nachfolger sich mit dem Müll rumplagen; die knappe Manpower lieber auf neue Entwicklungen verwenden, für die man gefeiert wird.

Das umseitige Konzept ist nicht das Wundermittel.

• Es setzt stark darauf, viel Lyrik („Literate“) in den Programmcode hineinzuschreiben.
• Das hat sich abgesehen von minimalen Hinweisen und einer englischsprachigen Kurzdoku nicht bewährt.
• Die Idee ist aus den 1980ern und geeignet für kleine mehr private Bastelarbeiten. Auch Knuth habe TeX so geschrieben; wohl als Einzelkämpfer.
• In großem Maßstab bedarf jede Änderung des wirksamen Codes eines Review und einer Erprobung und einer neuen Version, die freigegeben werden muss.
• Deshalb werden mehrsprachige Doku-Versionen, tiefer schürfende Erläuterungen über Hintergründe usw. gerade nicht mehr in den Code geschrieben, weil den kaum noch jemand verändern kann. Jede Tippfehlerkorrektur ein Drama.
• Das Grundkonzept „sowohl die Dokumentation als auch der Quelltext des Programms in einer gemeinsamen Datei vorhanden sind“ ist deshalb ausdrücklich unerwünscht. Mehr als ein Satz pro Parameter und Funktionszweck sind nicht drin. Die sollten dafür auch durchgesetzt werden.

VG --PerfektesChaos 21:25, 12. Dez. 2023 (CET)

Sehr schade. Es klingt immer etwas rückständig wenn Menschen ständig mit Anglizismen hantieren müssen, weil ihnen die deutschen Vokablen fehlen. Besser ist, wenn man diese Dinge eindeutscht. --Jakob5 (Diskussion) 10:14, 15. Dez. 2023 (CET)

Wir können uns aber keine deutschsprachigen Begriffe ausdenken, schon gar nicht als Wikipedia, wenn der deutschsprachige Begriff und Fachausdruck überhaupt nicht existiert.

Wir können uns auch nicht die Millionenstadt Fluss von Januar ausdenken, weil dir Rio de Janeiro nicht gefällt.

VG --PerfektesChaos 12:11, 15. Dez. 2023 (CET)

ich bin Hobby-Germanist, und "Beschriebenes Programmieren" ist die perfekte Übersetzung. Sie erklärt den Begriff ohne ihn definieren zu müssen, noch deutlich klarer als das englische Original. --Jakob5 (Diskussion) 14:11, 18. Dez. 2023 (CET)

Literarisches Programmieren und Lemma

Ist freilich falsch, denn „literarisch“ wäre „literary“. Es geht ums Schreiben von Programmen in Prosa. Und das Lemma wäre richtigerweise großgeschrieben „Literate Programming“. --Viele Grüße, Aschmidt (Diskussion) 00:10, 13. Dez. 2023 (CET)

„Quellcode und Kommentare können miteinander gemischt werden“ – hat sich als Illusion erwiesen

Hatte ich weiter oben schon dargelegt, dass diese Konzeption letztlich nur für eine One-man-show taugt; sich aber für größere Software-Projekte nicht durchgesetzt hat.

• Liegt daran, dass bei einer auf Sicherheit, Qualität und Robustheit ausgelegten Software jeglicher Eingriff in den Quellcode eines Review bedarf.
• Zwar macht man minimale eingebettete auslesbare Dokumentation, etwa für javadoc & Co. die Funktionsbeschreibung in ein oder zwei Sätzen, pro Parameter ein paar Wörter, jedoch möglichst kurz und nur in einer Sprache (englisch) und ohne Zeichnungen und Hintergrund.
  • Die vertiefende, hintergründige, illustrierte oder übersetzte Doku läuft separat.
  • Die integrierte Kurzdoku hilft beim Abgleich und muss konsistent sein. Die ist aber bei der Entwicklung direkt vor Augen und jede Veränderung kann eingepflegt werden; die Konsistenz mit Datentypen und Parameterliste wird über den Vergleich mit dem tatsächlich wirksamen Code zwingend sichergestellt.
• Ein aktuelles Beispiel, welchen Aufwand die Korrektur eines simplen Buchstabendrehers in einem Kommentar nach sich zieht, wie viele Bearbeitungsschritte und Akteure: phab:T356154 und gerrit:994374 bzw. rEUSH80a0680.

VG --PerfektesChaos 01:24, 1. Feb. 2024 (CET)

„Die Quellcode-Abschnitte können in beliebiger Reihenfolge angeordnet werden. Das Literate-Programming-System setzt sie automatisch in der richtigen Reihenfolge zusammen, so dass sie ausgeführt werden können“

Da bedanken sich alle recht freundlich.

• Um noch nachvollziehen zu können, in welcher Reihenfolge Prozeduren ausgeführt werden, soll schon die physische Reihenfolge sichtbar werden; und nicht irgendeine beliebige, und dann würde irgendein oberschlaues Schema ausführbare Anweisungen in einer mir nicht bekannten Reihenfolge anordnen.
• Auch Deklarationen, die keine Ausführungsreihenfolge erfordern, möchte ich in einem von mir vorgegebenen System im Quellcode sehen, damit ich durchschaue ob sie vollständig und konsistent und geeignet zugeordnet sind, und auch alle außer mir nach gleichen Prinzipien das nachvollziehen können, und ich die Deklarationen anderer Leute oder von vor drei Jahren begreife und wiederfinde.
• Auch dieses Konzept hatte sich nicht durchgesetzt. Braucht niemand, wollte niemand, schadet mehr als die geniale Idee versprach.

VG --PerfektesChaos 01:31, 1. Feb. 2024 (CET)

Das alles mag stimmen, trägt aber (wie auch der obere Abschnitt und auch das, was du vor 4 Jahren unter "Essig und Wein" geschrieben hast) nichts zur Verbesserung des Artikels bei. Entweder du hast belegte Kritik an dem Lemma, dann rein damit oder eben nicht, dann sind diese Abschnitte auf der Diskussionsseite unnötig. --Sebastian.Dietrich  ✉  09:10, 1. Feb. 2024 (CET)