Diskussion:Literate Programming

message: 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)
replies: text: 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)
thread_title:  [[AppleScript]] 

message: 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)
thread_title:  Falscher Freund 

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

message: 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:
*# Mehrsprachige Dokumentation
*# Komplexeres Markup, Aufzählungen, Grafiken mit Schemata, mathematische Formeln, Anmerkungen und Hintergrundinformationen.
*# 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  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)
thread_title:  Essig und Wein 

message: 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)
thread_title:  Literarisches Programmieren und Lemma 

message: 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:  und gerrit:994374 bzw. .
VG --PerfektesChaos 01:24, 1. Feb. 2024 (CET)
thread_title:  „Quellcode und Kommentare können miteinander gemischt werden“ – hat sich als Illusion erwiesen 

message: 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)
replies: text: 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)
thread_title:  „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“