Donald Knuth, der Meister der Lyrik
vom 3. August 2009Donald E. Knuth ist die lebende Legende im Softwareumfeld. Er widmet schon über Jahrzehnte hinweg sein Leben der Forschung und der formalen Beschreibung von Algorithmen. Sein "still in progress" Band Art of Computer Programming ist wahrlich ein Meisterwerk. Interessant ist aber, dass sich die wenigsten Informatiker an dieses monströse Werk wagen. Er ist auch der Auffassung, dass Programmcode mit der selben Sorgfalt verfasst werden sollten wie literarische Texte. Dokumentation und Code sollten vereint sein.
"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." - Donald E. Knuth
Da ich auch einen gewissen Standard an Dokumentation und Programmcode habe und meinen Code ästhetisch ansprechend formatiere und schreibe (bzw. den Code so gestalte, dass er mich anspricht :)), bin ich natürlich immer wieder auf der Suche nach Vorbildern.
Deshalb dachte ich mir, wieso nicht mal den Quellcode von TeX (einem Textsatzsystem von Herrn Ph. D. Knuth persönlich) anschauen. Und tatsächlich: Im ersten Moment dachte ich, der Code sei nur die Dokumentation zu TeX. Er liest sich wie eine Definition oder ein Informatikbuch. Hier mal ein kleiner Auszug:
@ Now comes the harder part: At this point in the program, |cur_val| is a
nonnegative integer and $f/2^{16}$ is a nonnegative fraction less than 1;
we want to multiply the sum of these two quantities by the appropriate
factor, based on the specified units, in order to produce a |scaled|
result, and we want to do the calculation with fixed point arithmetic that
does not overflow.
@<Scan units and set |cur_val| to $x\cdot(|cur_val|+f/2^{16})$...@>=
if inf then @<Scan for \(f)\.{fil} units; |goto attach_fraction| if found@>;
@<Scan for \(u)units that are internal dimensions;
|goto attach_sign| with |cur_val| set if found@>;
if mu then @<Scan for \(m)\.{mu} units and |goto attach_fraction|@>;
if scan_keyword("true") then @<Adjust \(f)for the magnification ratio@>;
@.true@>
if scan_keyword("pt") then goto attach_fraction; {the easy case}
@.pt@>
@<Scan for \(a)all other units and adjust |cur_val| and |f| accordingly;
|goto done| in the case of scaled points@>;
attach_fraction: if cur_val>=@'40000 then arith_error:=true
else cur_val:=cur_val*unity+f;
done:
Abgesehen von der gewöhnungsbedürftigen Syntax ist das fast schon lyrik, was er da an den Tag legt. Leider sind nicht alle Programmiersprachen so biegsam, aber Ruby geht hier schon sehr in die richtige Richtung. Also hier ein Aufruf an alle: Doku + Code = Awesome! :)
del.icio.us,
[Donald E. Knuth][1] ist *die* lebende Legende im Softwareumfeld. Er widmet schon über Jahrzehnte hinweg sein Leben der Forschung und der formalen Beschreibung von Algorithmen. Sein \"still in progress\" Band *Art of Computer Programming* ist wahrlich ei
Kommentare
Was meinst du mit ästhetisch Aussehen? Ansprechende Einrückungen und Formatierung oder wirklich wie in TEX eine möglichst realistische Ausdrucksweise? Gerade auf Formatierung lege ich auch recht viel Wert da es ungemein hilft den Überblick zu behalten. Da es ja leider auch im 6. Semester noch Leute gibt die es nicht schaffen einheitlich einzurücken ist dies nicht selbstverständlich.
Wegen der realitätsnahen Ausdrucksweise bin ich mir noch etwas uneinig. Klar ist es sehr schön wenn man seinen Code so schreiben kann aber das Beispiel in TEX treibt es da schon sehr weit. Ich halte es für viel wichtiger mit der Einfachheit einer Sprache mächtige Ausdrücke bilden zu können. Dafür würde ich auch die Klammern in LISP etc. in kauf nehmen. In dem TEX Beispiel lässt sich zwar sehr schön herauslesen WAS es tut, aber die Funktionsweise, WIE es gemacht wird, wird dadurch finde ich sehr verdeckt. Hoffe du weißt was ich mein ;-)
Was ich mal eine nette Idee fände: In die Sprachsyntax integrierte Dokumentationskonstrukte. Also nicht wie üblich in den Kommentaren willkürliche Angaben sondern durch eingebaute Sprachkonstrukte. So könnte man schön auch Contracts oder Asserts abbilden die gleich dokumentiert sind etc. Und beim durchlaufen des ASTs würde neben dem Programmcode auch die Doku mit raus fallen.
Aber im Alltag kann leider nicht jedes Stück Software eine in sich geschlossene, perfekte, Einheit bilden. Da gewinnt bei mir einfach der pragmatismus.
Aber es gibt ja auch im echten Leben Zeitungsredakteure und Lyriker :D
Interessant finde ich auch, was Flo geschrieben hat. Leider kann ich mir da nicht viel drunter vorstellen.. wäre eine Idee für nen eigenen Blogbeitrag von ihm :)
BTW: Aaron wie wärs mal mit Kommentarfeeds? Ich hätte gern so was wie bei KB und Andreas so das ich alle Kommentare in allen Artikeln abonnieren kann. Geht das?
@nougad: CRE127 hab ich gehört, fand ich sehr interessant. Das war auch der ausschlaggebende Grund, den Beitrag zu verfassen :) Mit Ästhetik meine ich beides. Zum einen muss der Code schön fürs Auge sein und nicht wie Kraut und Rüben eingerückt sein und zum anderen die Ausdrucksweise. Kann ich den Code auch schnell verstehen, wenn keine Kommentare vorhanden sind? Ist alles logisch aufgebaut und nicht nur zusammenkopiert, etc. Das Beispiel von Knuth ist ziemlich wirr wenn man die Sprache nicht kennt. Das "WIE" ist auf den ersten Blick noch nicht so wichtig, das spielt erst eine Rolle, wenn man mit dem Codestück arbeiten will. Hier muss man halt die Sprache komplett durchdrungen haben und nachvollziehen können, was der Programmierer sich hier gedacht hat. Hier kann man natürlich mit Kommentaren wieder aushelfen. Die Idee die Kommentare in den Code mit in den AST einzubinden find ich super, ich frag mich warum das noch nicht in irgend einer Sprache drin ist. Wenn du was gefunden hast sag Bescheid :)
@Andreas: Ja, stimmt. Es kommt auch immer auf die Zielgruppe an. Nimmt man zum Beispiel Haskell, hält das ein Mathematiker für selbsterklärend und schick und kann sich gleich "reinlesen", wärend ein PHP-Programmierer damit erst einmal garnichts anfangen kann. Aber sieht man mal davon ab, kann man mit jeder Sprache verständlichen Code schreiben, in dem man sich bei der Namensgebung Gedanken macht, Dinge in Klassen/Module packt die da auch wirklich hingehören usw. Ruby macht es da dem Programmierer schon von Grund auf sehr leicht, verständlichen und lesbaren Code zu schreiben. Ruby wird auch nicht umsonst als "Pseudocode that runs" beschrieben und für DSLs aller Art hergenommen.
@kb: Overhead finde ich das jetzt nicht. Wenn der Code selbst (ohne irgend welche Kommentare) leicht verständlich ist sich "lesen" lässt würde ich das auch für ästhetisch finden. Der Vergleich mit Bildzeitungs-Redakteure und Lyriker find ich sehr gut :)
