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)