Kurse sind Zeitverschwendung

Für ihr neues Buch "Visionäre der Programmierung - die Sprachen und ihre Schöpfer", das im O'Reilly-Verlag erschienen ist, interviewten Federico Biancuzzi und Shane Warden die Entwickler der 17 bekanntesten und am weitesten verbreiteten Programmiersprachen - von BASIC, C++ und C# über Forth, APL, Python, Java und SQL bis hin zu UML, Objective-C, Perl und Postscript. In den Gesprächen mit Persönlichkeiten wie James Gosling, Charles Geschke, Thomas Kurtz, Don Chamberlin, Brad Cox und Bjarne Stroustrup kamen allerlei spannende Geschichten ans Tageslicht. Die Programmierprofis verrieten unter anderem auch, woran sie derzeit arbeiten, wie sie Ihre Sprachen weiterentwickeln möchten und wo sie die Zukunft der Entwicklergilde sehen. Lesen Sie im zweiten Teil von "Berühmte Entwickler ganz privat" ausgewählte Interviewpassagen mit dem Forth-Erfinder Charles H. Moore, dem BASIC-Designer Thomas E. Kurtz, den awk-Entwicklern Alfred Aho, Peter Weinberger und Brian Kernighan sowie Java-Vater James Gosling (die deutschen Übersetzungen stammen von Thomas Demming). Die vollständigen, um viele Seiten längeren Interviews lesen Sie nur im O'Reilly-Buch.

Charles H. Moore, Forth: Mehr Kerne kennen

Wie wird Forth zukünftige Computersysteme beeinflussen?

Chuck: Das ist schon geschehen. Ich arbeite seit 25 Jahren an Mikroprozessoren, die für Forth optimiert sind, und derzeit an einem Mehrkernprozessor, dessen Kerne Forth-Computer sind.

Was bietet Forth? Als einfache Sprache ermöglicht es einen einfachen Computer: 256 Wörter im lokalen Speicher, zwei Push-down-Stacks, 32 Anweisungen, asynchrone Operationen, einfache Kommunikation mit den Nachbarn. Klein und mit wenig erforderlicher Leistung.

Forth unterstützt hoch faktorisierte Programme. Die sind gut geeignet für die parallele Verarbeitung, was bei einem Mehrkernprozessor benötigt wird. Viele einfache Programme fördern das sorgfältige Design jedes einzelnen Programms. Und benötigen vielleicht nur ein Prozent des Codes, der sonst geschrieben würde.

Immer, wenn ich höre, wie Leute mit Millionen von Codezeilen prahlen, weiß ich, dass sie ihr Problem gar nicht verstanden haben. Es gibt keine aktuellen Probleme, die Millionen von Codezeilen nötig machen. Vielmehr gibt es sorglose Programmierer, schlechte Manager und unmögliche Kompatibilitätsanforderungen.

Das Programmieren vieler kleiner Computer mit Forth ist eine exzellente Strategie. Andere Sprachen haben gar nicht die Modularität und Flexibilität. Und da die Computer kleiner werden und per Netzwerk miteinander kooperieren (Smart Dust?), wird das die Umgebung der Zukunft sein.

Nicht aufs Warten warten müssen

Was ist der größte Fehler, den Sie in Bezug auf Design oder Programmierung gemacht haben? Was haben Sie daraus gelernt?

Chuck: Vor etwa 20 Jahren wollte ich ein Tool zum Designen von VLSI-Chips entwickeln. Ich hatte auf meinem neuen PC kein Forth, daher gedachte ich, einen anderen Ansatz zu versuchen: Maschinensprache. Nicht Assembler, sondern tatsächlich die Eingabe der Hex-Anweisungen.

Ich baute den Code so auf, wie ich es in Forth getan hätte, mit vielen einfachen Wörtern, die hierarchisch interagieren. Es funktionierte. Ich nutzte das Tool zehn Jahre lang. Aber es war schwierig zu warten und zu dokumentieren. Schließlich baute ich es in Forth nach, und es wurde kleiner und einfacher.

Meine Schlussfolgerung war, dass Forth effizienter als Maschinensprache ist. Teils aufgrund seiner Interaktivität und teils aufgrund seiner Syntax. Ein netter Aspekt von Forth-Code ist, dass Zahlen durch die Ausdrücke dokumentiert werden können, aus denen sie berechnet wurden.

Welchen Ratschlag würden Sie einem Anfänger geben, damit das Programmieren angenehmer und effektiver wird?

Chuck: Nun, sicherlich nicht überraschenderweise würde ich sagen, dass Sie lernen sollten, Forth-Code zu schreiben. Selbst wenn Sie das nicht beruflich tun werden, werden Sie einige dieser Lektionen lernen und eine bessere Sichtweise auf jegliche andere Sprache erhalten. Wenn ich ein C-Programm schrieb - ich habe kaum welche geschrieben - tat ich das im Forth-Stil mit vielen einfachen Unterroutinen. Selbst wenn das teurer war, lohnte es sich meiner Meinung nach, weil die Wartbarkeit deutlich stieg.

Die andere Sache ist, das Ganze einfach zu halten. Der unvermeidliche Trend beim Entwerfen eines Flugzeugs oder beim Schreiben einer Anwendung, selbst einer Textverarbeitung, ist, Features über Features hinzuzufügen, bis das Ganze nicht mehr wartbar ist. Es wäre besser, ein halbes Dutzend Textverarbeitungen zu haben, die sich auf unterschiedliche Märkte konzentrieren. Das Schreiben einer E-Mail mit Word ist verrückt, 99 Prozent der verfügbaren Features sind unnötig. Sie sollten einen E-Mail-Editor haben. Es gab solche Editoren, aber der Trend scheint davon wegzuweisen. Mir ist nicht klar, warum das so ist.

Halten Sie es einfach. Wenn Sie mit einer Anwendung zu tun haben, wenn Sie ein Teil des Designteams sind, versuchen Sie, die anderen Leute auch davon zu überzeugen, es einfach zu halten. Greifen Sie nicht zu weit vor. Lösen Sie keine Probleme, von denen Sie glauben, dass sie in Zukunft auftreten könnten. Lösen Sie die Probleme, die Sie jetzt haben. Vorausschauen ist sehr ineffizient. Sie können sich zehn Sachen vorstellen, die passieren könnten, von denen nur eine eintreten wird. Also haben Sie viel Aufwand umsonst getrieben.

Wie erkennen Sie einen guten Programmierer?

Chuck: Ein guter Programmierer schreibt schnell guten Code. Guter Code ist korrekt, kompakt und lesbar. "Schnell" bedeutet Stunden oder Tage.

Ein schlechter Programmierer wird über das Problem sprechen wollen, Zeit mit Planung statt mit Schreiben verschwenden und auf dem Schreiben und Debuggen von Code seine Karriere aufbauen.

Thomas E. Kurtz, BASIC: OOP ist ein großer Betrug

Welches ist der beste Weg, eine neue Programmiersprache zu erlernen?

Tom: Wenn Sie einmal wissen, wie man programmiert, und die Konzepte kennen (zum Beispiel wie Speicher alloziert wird), ist das Erlernen einer neuen Sprache einfach, wenn man Zugriff auf eine Referenzanleitung und eine ordentliche Implementierung (zum Beispiel einen Compiler) hat. Ich habe das häufig getan.

An einem Kurs teilzunehmen, ist eigentlich ziemliche Zeitverschwendung.

Jeder Programmierer, der sein Geld wert ist, wird während seiner Arbeitsjahre viele Sprachen erlernen. (Ich habe vermutlich mehr als 20 verwendet.) Neue Sprachen lernt man, indem man die Anleitung liest. Mit ein paar Ausnahmen haben die meisten Programmiersprachen eine ähnliche Struktur und ein ähnliches Verhalten, daher lassen sich neue Sprachen ziemlich einfach erlernen, wenn es eine ständige Beschreibung für sie gibt.

Nachdem Sie sich einmal mit den spracheigenen Begriffen vertraut gemacht haben (Was bedeutet Polymorphismus?), geht der Rest quasi von allein.

Ein Problem beim heutigen Programmierstil ist, dass es keine Anleitungen gibt - nur Tools zum Bauen von Schnittstellen. Sie sind so entworfen, dass Programmierer viele der Anweisungen nicht mehr Buchstabe für Buchstabe tippen müssen, sondern eher wie bei den CAD- und CAM-Tools der Ingenieure vorgehen können. Für Programmierer der alten Schule ist das ein Gräuel - ich möchte den ganzen Code tippen, Zeichen für Zeichen.

Es gab in der Vergangenheit Versuche, das Tippen zu vereinfachen (für schlechte Schreiber oder Studenten), indem Makros bereitgestellt wurden (wie zum Beispiel ein einzelner Tastendruck für das Schlüsselwort LET), aber so richtig durchgesetzt haben sie sich nie.

Ich versuche momentan, eine Sprache zu erlernen, die wohl "objektorientiert" ist. Es gibt keine Referenz, zumindest habe ich keine gefunden. Die verfügbaren Anleitungen zeigen nur ziemlich triviale Beispiele und nutzen 90 Prozent des Platzes dafür, zu zeigen, warum OOP (objektorientierte Programmierung, Anm. d. Red.) eine so überragende "Religion" ist. Ich habe Freunde, die an einem C++-Kurs teilgenommen haben, aber es war aus pädagogischer Sicht ein Desaster. Meiner Meinung nach ist OOP ein großer Betrug, der an der Community begangen wird. Alle Sprachen wurden ursprünglich für eine bestimmte Klasse von Anwendern entworfen - FORTRAN für umfangreiche numerische Berechnungen und so weiter. OOP war dafür gedacht, dass seine Anwender sich überlegen fühlen können, weil sie "dazugehören". In Wahrheit ist der einzige wichtige Aspekt des OOP ein Ansatz, der schon vor Jahrzehnten entwickelt wurde: das Kapseln von Unterroutinen und Daten. Alles andere ist nur Dekoration.

Man schütze sich vor Hardware und Reglementierung!

Hat die Entwicklung der Hardware auch die Entwicklung der Sprache beeinflusst?

Tom: Nein, weil wir dachten, die Sprache sei ein Schutz, um nichts über die Hardware wissen zu müssen. Als wir BASIC entwarfen, machten wir es unabhängig von der Hardware, es gibt nichts in der Sprache oder in den Features, die später dazukamen, was die Hardware widerspiegelt.

Das gilt nicht für einige der frühen PC-Versionen von BASIC, die mit dem, was wir in Dartmouth gemacht haben, nur wenig zu tun haben. So gibt es zum Beispiel in einer PC-Version von BASIC eine Möglichkeit, den Inhalt eines Speicherplatzes zu setzen oder auszulesen. Bei unserem eigenen BASIC gab es das nie. Daher waren diese PC-BASICs natürlich außerordentlich abhängig von den Hardwaremöglichkeiten, und das Design dieser PC-Sprachen spiegelte die Hardware wider, die verfügbar war.

Wenn Sie mit Leuten sprechen, die Microsoft BASIC entwickelt haben, würden die sagen, dass die Features der Sprache durchaus durch die Hardware beeinflusst waren, aber das war bei Dartmouth mit dem ursprünglichen BASIC nicht der Fall.

Wenn Sie heute eine komplett neue Programmiersprache für die Lehre entwerfen müssten - wie stark würde sie BASIC ähneln?

Tom: Sie wäre sehr ähnlich, da die Prinzipien, denen wir folgten, immer noch gültig sind. So haben wir zum Beispiel versucht, eine Sprache zu bauen, die man sich leicht merken kann, sodass eine Person, die sie längere Zeit nicht verwendet hat, trotzdem schnell wieder damit arbeiten kann.

Wir haben versucht, eine Sprache zu bauen, die ein Minimum an esoterischen Anforderungen hat. Wenn Sie zum Beispiel in FORTRAN eine Zahl ausgeben wollten, mussten Sie eine Format-Anweisung verwenden und genau angeben, wie sie ausgegeben werden soll. Das ist sehr esoterisch, insbesondere für Leute, die die Sprache nicht so häufig verwenden, daher haben wir in BASIC dafür gesorgt, dass die Zahl einfach von vornherein so ausgegeben wird, wie es unserer Meinung nach sinnvoll ist. Wenn es eine Integer-Zahl war, gaben wir sie als Integer-Zahl ohne Dezimalpunkt aus, obwohl wir intern mit Gleitkommazahlen arbeiteten. Wenn Sie eine Zahl eingeben wollten, mussten Sie sich um das Format auch keine Gedanken machen. Sie hätten einfach die gewünschte Formel hingeschrieben, und die Zahl wäre genutzt worden - ohne Einschränkung auf ein bestimmtes Format beim Eingeben von Daten.

Das orientiert sich meistens an Tabellenkalkulationen - die sind darin richtig gut. Sie könnten festlegen, dass Sie für Zahlen in einer bestimmten Spalte eine Ausgabe mit einer festen Anzahl von Nachkommastellen haben wollen. Wenn Sie sich nicht darum scheren, erhalten Sie die allgemeine Form. Ich denke, so ungefähr gingen wir auch in BASIC vor. Wir haben die Eingabe von Zeichen zugelassen und machten es dabei sehr einfach: ohne Regeln.

Während der 70er und 80er Jahre haben wir in Dartmouth strukturierte Programmierversionen von BASIC entwickelt und die Elemente hinzugefügt, die für eine objektorientierte Programmierung notwendig sind. Wir würden heute nichts anders machen.

Alfred Aho, awk: Die Dokumentation ist unbezahlbar

Wie setzen Sie eine Programmiersitzung nach ein paar Tagen fort? Oder nach ein paar Monaten?

Al: Wenn jemand ein Programmiersystem (oder auch ein Buch) schreibt, muss er das gesamte System irgendwie in seinem Kopf unterbringen. Durch Unterbrechungen werden die Gedankenketten aufgebrochen, aber wenn es nur ein kurzer Zeitraum ist, kann man normalerweise schnell wieder einsteigen, wenn man sich den Code erneut anschaut. Nach einer Unterbrechung, die Monate oder Jahre dauert, bin ich schnell dabei, Artikel, Bücher oder Notizen zu studieren, in denen ich meine Algorithmen dokumentiert habe, um mein Wissen über das, was ich vorher programmiert habe, wieder aufzufrischen.

Ich denke also, dass gute Kommentare und eine gute Dokumentation sowohl für die ursprünglichen Systemdesigner als auch für andere, die den Code über lange Zeit warten müssen, sehr hilfreich sein können. Brian (Kernighan, Anm. d. Red.) hat ein Protokoll der wichtigsten Entscheidungen geführt, die wir beim Entwerfen der Sprache getroffen haben. Ich fand dieses Protokoll unbezahlbar.

Brian Kernighan, awk: Über die Lehre zur Perfektion

Was hat Sie an der Programmierung gefesselt?

Brian: Ich kann mich gar nicht an ein besonderes Ereignis erinnern. Ich hatte sogar erst einen eigenen Computer, als ich im College anfing, und bis ich wirklich gelernt hatte, zu programmieren (in FORTRAN), dauerte es noch mal ein Jahr oder so. Ich denke, am meisten Spaß beim Programmieren hatte ich bei einem Ferienjob beim Projekt MAC am MIT im Sommer 1966, bei dem ich an einem Programm arbeitete, das ein Aufgabenband für den brandneuen GE 645 in den ganz frühen Tagen von Multics erstellte. Ich schrieb in MAD, das viel einfacher und eleganter als das vorher von mir genutzte FORTRAN oder COBOL war. Und ich nutzte CTSS, das erste Timesharing-System, das unendlich einfacher und angenehmer als Lochkarten war. Das war der Punkt, an dem der Aspekt des Rätsellösens bei der Programmierung wirklich Spaß machte, da die mechanischen Details nur noch sehr selten im Weg standen.

Wie können Programmierer ihr Programmieren verbessern?

Brian: Schreiben Sie mehr Code! Und dann machen Sie sich Gedanken über den Code, den Sie geschrieben haben, und versuchen, ihn zu überarbeiten, um ihn besser zu machen. Lassen Sie andere Leute den Code lesen, wenn das möglich ist, egal ob als Teil Ihres Jobs oder als Teil eines Open Source-Projekts. Es ist auch hilfreich, verschiedene Arten von Code zu schreiben, eventuell sogar in unterschiedlichen Sprachen, da Sie damit Ihr Repertoire an Techniken erweitern und mehr Wege haben, Programmierprobleme anzugehen. Lesen Sie zum Beispiel den Code von anderen Leuten und versuchen Sie, Features hinzuzufügen oder Fehler zu beheben - das wird Ihnen zeigen, wie andere Leute Probleme angehen. Schließlich geht nichts über das Unterrichten des Programmierens, um den eigenen Code zu verbessern.

Peter Weinberger, awk: WYSIWYG pur

In welchem Umfeld sehen Sie AWK als bessere Wahl als zum Beispiel SQL an?

Peter: Nun, die beiden lassen sich nicht einfach vergleichen. awk hat keine expliziten Typen, SQL ist damit völlig überladen. awk liest und schreibt also Strings, aber es ist darauf ausgelegt, manche Strings als Zahlen zu betrachten, wenn man es darum bittet. SQL nutzt Joins, aber um das Gleiche in awk zu machen, muss man ein Programm vorweg laufen lassen, vermutlich join. SQL führt Sortier- und Aggregationsaufgaben aus, aber im Unix-Umfeld wird das durch sort und dann ein erneutes Pipen in awk oder ein anderes Unix-Programm umgesetzt. Kurz gesagt war awk dafür gedacht, Teil einer Sequenz von nacheinander ausgeführten Befehlen zu sein. SQL war dafür gedacht, mit Daten verwendet zu werden, die in einer eigenen Struktur versteckt sind, wobei der Anwender das Schema kennt. Schließlich sind in SQL Jahre der Abfrageoptimierung eingeflossen, während Sie in awk das bekommen, was Sie sehen.

James Gosling, Java: Spezifikationen lösen keine Probleme

Wie ändert das allgegenwärtige Internet das Konzept einer Programmiersprache?

James: Die Anwesenheit eines Netzwerks beeinflusst das Design einer Programmiersprache in sehr großem Maße. Sobald Sie ein Netzwerk haben, müssen Sie sich mit Diversität und Kommunikation beschäftigen. Sie müssen darüber nachdenken, was für Auswirkungen Fehler haben können. Sie müssen sich um die Zuverlässigkeit sorgen.

Insbesondere müssen Sie sich darüber Gedanken machen, wie Sie stabile Systeme aufbauen können, die auch bei Teilausfällen noch funktionieren, da die meisten Systeme, die gebaut werden und tatsächlich für etwas nützlich sind, genau die sind, bei denen immer irgendetwas kaputt ist.

Die klassische Sichtweise der Software war immer "ganz oder gar nicht": Es funktioniert, oder es funktioniert nicht. Viele der Überlegungen dazu fließen in Dinge wie den Java-Exception-Mechanismus, das starke Typensystem, den Garbage Collector (erklärendes PDF, Anm. d. Red.), die virtuelle Maschine und so weiter ein. Ich glaube, das Netzwerk hat wirklich grundlegende Auswirkungen auf das Design von Java - die Sprache und die virtuelle Maschine.

Glauben Sie eher an eine formale oder eine vollständige Spezifikation eines Projekts, bevor Sie es bauen?

James: Ich habe gegenüber formalen Spezifikationen gemischte Gefühle. In der Theorie sind sie wohl toll, aber in der Praxis scheinen sie nicht ganz so gut zu funktionieren. Für ziemlich kleine Sachen mag es noch in Ordnung sein, aber je größer es wird, desto weniger formal werden die Spezifikationen, da sie nicht sehr gut skalieren.

Wichtiger ist noch, dass formale Spezifikationen ein Problem häufig gar nicht lösen. Sie verschieben das Problem vom Finden von Fehlern in Ihrer Software hin zum Finden von Fehlern in Ihrer Spezifikation. Und es kann wirklich schwer sein, Fehler in der Spezifikation zu finden.

Selbst wenn Sie keine formalen Spezifikationen schreiben, führen Sie eine Art Anforderungs-Analyse durch - viele Organisation gehen da nach dem Wasserfallmodell vor, bei dem eine Gruppe eine Anforderungsdokument schreibt, das sie an die Leute übergibt, die dann tatsächlich das Ding bauen müssen.

Das Anforderungsdokument ist häufig mit Problemen angefüllt, und solange es keine wirklich kurze Feedbackmöglichkeit gibt, finden Sie keine Fehler in den Spezifikationen. Währen ich also im Allgemeinen ein großer Fan von Spezifikationen und Anforderungen und solchen Sachen bin, tendiere ich dazu, sie nicht furchtbar ernst zu nehmen, und ich erwarte auf keinen Fall, dass sie große Probleme lösen.

Hat Java die Meinung der Öffentlichkeit über Plattformunabhängigkeit beeinflusst?

Die Öffentlichkeit denkt nicht nach

James: Ich glaube nicht, dass die Öffentlichkeit über Plattformunabhängigkeit nachdenkt. Aus meiner Sicht als Entwickler, der diese großen Systeme aufbaut, sollte die Öffentlichkeit aber eigentlich auch nichts davon mitbekommen müssen.

Wenn Sie Ihre EC-Karte in einem Geldautomaten nutzen, bemerken Sie vermutlich gar nicht, dass da mit großer Sicherheit schon Java-Code genutzt wird, der auf Sun-Rechnern und IBM-Rechnern und Dell-Rechnern und HP-Rechnern und anderen Kisten mit x86-Architektur und PowerPC-Architektur und sonst was läuft.

Viele dieser Prozesse laufen hinter den Kulissen ab. Sie fahren mit der U-Bahn: Wenn Sie eine dieser Transponderkarten nutzen, wie der Oyster-Card bei der Londoner U-Bahn, nutzen Sie ein auf Java basierendes System.

Sie nutzen tatsächlich alle die Plattformunabhängigkeit, und wenn die Konsumenten genötigt würden, sich der Programmiersprache bewusst zu sein, mit der das System aufgebaut wurde, wäre das ein echter Fehler des Systems. Eines unserer Ziele ist, vollständig transparent zu sein und von den Leuten gar nicht bemerkt zu werden. Natürlich bringt das die Marketingleute zur Verzweiflung. Sie würden gerne immer dann ein Java-Log anzeigen, wenn Sie die Zugangssperren bei der U-Bahn passieren, aber das wäre verrückt.

Den ersten Teil von "Berühmte Entwickler ganz privat" mit Gesprächen über C++, Python und APL lesen Sie hier.