Foto: O'Reilly
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 ersten Teil unserer neuen montäglichen Serie "Berühmte Entwickler ganz privat" ausgewählte Interviewpassagen mit dem C++-Erfinder Bjarne Stroustrup, dem Python-Vater Guido von Rossum und dem APL-Entwickler Adin D. Falkoff (die deutschen Übersetzungen stammen von Thomas Demming).
Der zweite Teil mit Interviews mit Entwicklern der Sprachen Forth, Basic und AWK folgt am kommenden Montag.
Bjarne Stroustrup, C++: Stochern und herumpicken
Wie debuggen Sie? Haben Sie Ratschläge für C++-Entwickler?
Bjarne: Durch Beobachten. Ich untersuche das Programm so lange und stochere darin mehr oder weniger systematisch herum, bis ich es soweit verstanden habe, dass ich eine sinnvolle Abschätzung darüber abgeben kann, wo der Fehler sitzt.
Testen und ein gutes Design sind eine weitere Komponente, um Fehler zu minimieren. Ich mag das Debuggen so wenig, dass ich es so weit wie möglich vermeide. Wenn ich der Designer einer Software bin, baue ich es so um Interfaces und Konstanten herum auf, dass es ziemlich schwer ist, ernsthaft schlechten Code zu erhalten, der sich kompilieren lässt und dann falsch abläuft. Dann gebe ich mein Bestes, um es testbar zu machen. Testen ist die systematische Suche nach Fehlern. Es ist schwer, schlecht strukturierte Systeme systematisch zu testen, daher empfehle ich auch hier eine klare Codestruktur. Das Testen kann automatisiert werden und lässt sich damit so reproduzierbar machen, wie es beim Debuggen gar nicht möglich ist. Eine Schar Tauben auf dem Bildschirm herumpicken zu lassen, um herauszufinden, ob sie eine GUI-basierte Anwendung knacken können, ist nicht der richtige Weg, um eine hohe Qualität sicherzustellen.
Ratschläge? Es ist schwierig, allgemeine Ratschläge zu geben, da die besten Techniken häufig davon abhängen, was bei gegebenem System und Entwicklungsumgebung möglich ist. Auf jeden Fall gilt aber: Finden Sie die wichtigen Schnittstellen, die systematisch getestet werden können, und schreiben Sie Testskripte, die das tun. Automatisieren Sie so viel wie möglich und lassen Sie diese automatisierten Tests häufig laufen. Und führen Sie auch Regressionstests regelmäßig durch. Stellen Sie sicher, dass jeder Einstiegspunkt in das System und jede Ausgabe systematisch getestet werden können. Bauen Sie Ihr System aus qualitativ hochwertigen Komponenten zusammen - monolithische Programme sind unnötig schwer zu verstehen und zu testen.
C++ 2.0
Werden wir je ein C++ 2.0 sehen?
Bjarne: Das hängt davon ab, was Sie mit "C++ 2.0." meinen. Wenn Sie auf eine neue Sprache anspielen, die mehr oder weniger von Grund auf neu entwickelt wurde und das Beste von C++ enthält, aber alles Schlechte weglässt (für bestimmte Definitionen von "Bestes" und "Schlechtes"), ist die Antwort: "Ich weiß es nicht." Ich würde mich über eine richtige neue Sprache in der Tradition von C++ freuen, aber ich sehe keine am Horizont, daher möchte ich mich auf den nächsten ISO-C++-Standard konzentrieren, der den Arbeitstitel C++0x trägt.
Für viele wird das ein "C++ 2.0" sein, da es neue Sprachfeatures und neue Standardbibliotheken enthalten wird, aber es wird auch zu 100 Prozent kompatibel zu C++98 sein. Wir nennen es C++0x, in der Hoffnung, dass es ein C++09 wird. Wenn wir langsam sind - sodass x hexadezimal werden muss - werde ich (und andere auch) ziemlich enttäuscht und verärgert sein.
C++0x wird nahezu 100 Prozent kompatibel zu C++98 sein. Wir haben kein besonderes Interesse daran, Ihren Code ungültig werden zu lassen. Die größten Inkompatibilitäten entstehen durch die Verwendung ein paar neuer Schlüsselwörter wie static_assert, constexpr und concept. Wir haben versucht, die Auswirkungen minimal zu halten, indem wir neue Schlüsselwörter wählten, die nicht so viel genutzt werden. Die wichtigsten Verbesserungen sind:
-
Unterstützung von modernen Maschinenarchitekturen und Nebenläufigkeit: ein Maschinenmodell, eine Thread-Bibliothek, Thread-lokaler Speicher und atomare Operationen, sowie ein Mechanismus zur asynchronen Werterückgabe ("Futures").
-
Eine bessere Unterstützung der gegnerischen Programmierung: Konzepte (ein Typensystem für Typen, Kombinationen aus Typen und Kombinationen aus Typen und Integern), um Template-Definitionen und -Anwendungen besser prüfen und sie besser überladen zu können. Typdeduktion basierend auf Initialisierern (auto), verallgemeinerte Initialisiererlisten, verallgemeinerte konstante Ausdrücke (constexpr), Lambda-Ausdrücke und mehr.
-
Viele "kleine" Spracherweiterungen, zum Beispiel statische Assertions, Verschiebesemantiken, verbesserte Enumerations, ein Name für den Nullzeiger (nullptr) und so weiter.
-
Neue Standardbibliotheken für reguläre Ausdrücke, Hash-Tabellen (zum Beispiel unordered_map), "smarte" Zeige und so weiter.
Alle Details finden Sie auf der Website des "C++ Standards Committee". Einen Überblick finden Sie auch in meinen Online-FAQ zu C++0x.
Beachten Sie bitte, dass ich mich bei "den Code nicht ungültig werden lassen" auf die Kernsprache und die Standardbibliothek beziehe. Alter Code wird eventuell tatsächlich nicht mehr funktionieren, wenn er Erweiterungen eines Compileranbieters außerhalb des Standards oder altertümlicher Bibliotheken nutzt. Meiner Erfahrung nach beziehen sich die Leute vor allem auf proprietäre Features und Bibliotheken, wenn sie sich über "kaputten Code" oder "Instabilitäten" beschweren. Wenn Sie zum Beispiel das Betriebssystem wechseln und nicht eine der portablen GUI-Bibliotheken verwenden, werden Sie sicherlich einiges am Code für die Benutzerschnittstelle zu korrigieren haben.
Von Forschung und wirklichem Leben
Sie haben die Industrie verlassen, um eine akademische Laufbahn einzuschlagen. Warum?
Bjarne: Tatsächlich habe ich die Industrie nie komplett verlassen, da ich als AT&T-Fellow weiterhin eine Verbindung zu AT&T habe, zudem verbringe ich jedes Jahr viel Zeit mit Leuten aus der Industrie. Ich sehe meine Verbindung zur Industrie als sehr wichtig an, denn damit bleibt meine Arbeit mit der Realität verbunden.
Ich bin vor fünf Jahren als Professor an die Texas A&M University gegangen (nach fast 25 Jahren in "The Labs"), weil ich das Gefühl hatte, eine Änderung nötig zu haben, und weil ich dachte, ich müsse auch im Bereich der Ausbildung etwas beitragen. Zudem hatte ich ein paar sehr idealistische Vorstellungen von Grundlagenforschung nach all meinen Jahren der angewandten Forschung und Entwicklung.
Viel Forschung ist im Informatikbereich entweder zu weit von den tagtäglichen Problemen entfernt (selbst von mutmaßlichen zukünftigen tagtäglichen Ideen) oder so sehr mit den wirklichen Problemen verschlungen, dass sie eigentlich nicht viel mehr als ein Technologietransfer ist. Ich habe natürlich nichts gegen Technologietransfer (wir brauchen ihn unbedingt), aber es sollte gute Feedbackwege von der Praxis in der Industrie zurück zur fortgeschritteneren Forschung geben. Der kurze Planungshorizont in vielen Firmen und die Anforderungen der akademischen Veröffentlichungs- und Anstellungswege scheinen Aufmerksamkeit und Einsatz von einigen der kritischsten Probleme abzuziehen.
Guido von Rossum, Python: Sinnieren und skizzieren
Wie debuggen Sie eine Sprache?
Guido: Gar nicht. Sprachdesign ist ein Bereich, in dem agile Entwicklungsmethoden einfach keinen Sinn haben - bis die Sprache stabil ist, wollen sie nur wenige Leute nutzen, aber Sie finden die Fehler in der Sprachdefinition erst, wenn Sie so viele Anwender haben, dass es zu spät ist, um etwas zu ändern.
Natürlich lässt sich in der Implementierung Vieles wie jedes normale Programm debuggen, aber das Sprachdesign selbst muss von vornherein sorgfältig entworfen sein, da seine Fehlerkosten so exorbitant hoch sind.
Gibt es ein Tool oder Features, das Sie vermissen, wenn Sie Software schreiben?
Guido: Wenn ich auf einem Computer genauso einfach Skizzen machen könnte wie mit Stift und Papier, würde ich vielleicht mehr Skizzen machen, während ich mich mit dem schwierigen Nachdenken über ein Design beschäftige. Ich fürchte, dass ich warten muss, bis die Maus allgemein durch einen Stift (oder einen Finger) ersetzt wird, mit dem auf dem Bildschirm gezeichnet werden kann. Persönlich fühle ich mich furchtbar eingeschränkt, wenn ich irgendein Zeichenprogramm auf dem Computer nutzen muss, obwohl ich eigentlich mit Stift und Papier ganz gut bin - vielleicht habe ich das von meinem Vater geerbt, der Architekt war und andauernd Skizzen machte, daher habe ich als Teenager auch immer gezeichnet.
Am anderen Ende der Skala vermute ich, dass ich nicht einmal weiß, was ich vermisse, um einer großen Codebasis zu stöbern. Java-Programmierer haben heutzutage IDEs, die schnelle Antworten auf Fragen wie "Wer ruft diese Methode auf?" oder "Wo ist diese Variable zugewiesen?" geben können. Bei großen Python-Programmen wäre das auch hilfreich, aber die notwendigen statischen Analysen sind aufgrund der dynamischen Natur von Python viel schwieriger durchzuführen.
Sie haben gesagt, dass eine Zeile Python, eine Zeile Ruby , eine Zeile Perl, eine Zeile PHP zehn Zeilen Java-Code entsprechen.
Guido: Häufig ist das der Fall. Ich denke, dass der Level in Firmenumgebungen nur der Angst sehr konservativer Manager entspricht, auch wenn es bestimmte Funktionalitätspakete gibt, die hilfreich sind. Stellen Sie sich die für IT-Ressourcen verantwortlichen Personen in einer Firma mit 100.000 Mitarbeitern vor, bei denen die IT gar nicht das Hauptprodukt ist - vielleicht bauen sie Autos, verkaufen Versicherungen oder etwas anderes, aber alles, was sie tun, betrifft irgendwie etwas am Computer. Die für die Infrastruktur verantwortlichen Personen müssen notwendigerweise sehr konservativ sein. Sie greifen lieber auf Dinge zurück, an denen große Namen stehen, wie zum Beispiel Sun oder Microsoft, weil sie wissen, dass Sun und Microsoft zwar auch andauernd etwas vermasseln, diese Firmen aber gezwungen sind, es wieder geradezurücken, auch wenn es fünf Jahre dauert.
Open Source-Projekte haben solche Beruhigungspillen für den normalen CIO bisher traditionell nicht angeboten. Ich weiß nicht genau, ob, wie und wann sich das ändern wird. Falls Microsoft oder Sun plötzlich Python für ihre jeweiligen VMs unterstützen würden, könnte es passieren, dass die Programmierer in den Firmen tatsächlich bemerken würden, dass sie durch die Verwendung fortgeschrittenerer Sprachen eine höhere Produktivität ohne irgendwelche Nachteile erreichen würden.
Adin D. Falkoff, APL: Dyadisch und monadisch einfach
Hat die komplexe Syntax die Verbreitung von APL behindert?
Adin: Die Syntax von APL und ihre Auswirkungen auf die Akzeptanz der Sprache sind eine Diskussion wert, auch wenn ich nicht der Meinung bin, dass sie "komplex" ist. APL basierte auf der mathematischen Notation und auf algebraischen Ausdrücken und wurde durch das Entfernen ungewöhnlicher Formen und das Verallgemeinern der akzeptierten Notation vereinheitlicht. So wurde zum Beispiel entschieden, dass die dyadischen Funktionen, wie die Addition oder Multiplikation, zwischen ihren beiden Argumenten stehen sollen, und monadische Funktionen konsistent ihre Funktionssymbole vor das Argument schreiben sollen, ohne Ausnahmen, die es in der klassischen mathematischen Notation gibt. So ist der Absolutwert in APL durch einen vertikalen Blaken vor dem Argument dargestellt und nicht durch Balken auf beiden Seiten, und das Symbol für die Fakultät steht in APL ebenfalls vor dem Argument und nicht dahinter. Diesbezüglich war die Syntax von APL einfacher als die seiner historischen Quelle.
Die Syntax von APL war auf eine andere, wichtige Art und Weise einfacher als die von algebraischer Notation und anderen Programmiersprachen: Die Prioritätsregeln für die Auswertung von Ausdrücken in APL besagen schlicht, dass alle Funktionen die gleiche Priorität besitzen und sich die Anwender nicht merken müssen, ob die Potenzierung vor der Multiplikation durchgeführt wird oder wo definierte Funktionen in der Hierarchie wiederzufinden sind. Die Regel ist einfach, dass der am weitesten rechts stehende Unterausdruck zuerst ausgewertet wird.
Daher glaube ich nicht, dass die Syntax von APL die Verbreitung der Sprache beeinträchtigt hat, während der Zeichensatz mit seinen vielen Sonderzeichen, die auf einer normalen Tastatur nicht vorhanden sind, vermutlich diesen Effekt hatte.
Wenn ich eine neue Programmiersprache entwerfen wollte, welchen Ratschlag können Sie mir da geben?
Adin: Ich denke, das Beste, was ich sagen kann, ist, dass Sie etwas tun sollten, was Ihnen Spaß macht, etwas, mit dem Sie gerne arbeiten, etwas, das Ihnen dabei hilft, etwas anderes zu erreichen, was Sie auch gerne tun würden.
Wir waren bei unserem Vorgehen immer sehr auf uns bezogen, und ich denke, das sie die meisten Designer, wenn ich mir so durchlese, was die Leute schreiben. Sie begannen damit, etwas zu tun, was sie tun wollten. Das stellte sich dann als allgemein nützlich heraus.
Von IBM aus in die ganze Welt
Wie definieren Sie bei Ihrer Arbeit Erfolg?
Adin: APL hat gezeigt, dass es bei der Entwicklung vieler Aspekte von IBMs Geschäften ein sehr nützliches Tool war. Es stellte bei der Verwendung von Computern einen vereinfachten Ansatz bereit, der es Forschern und Produktentwicklern ermöglichte, den eigentlichen Problemen deutlich mehr Zeit zu widmen - von der theoretischen Physik bis zur Entwicklung von Flachbildschirmen. APL wurde auch genutzt, um Prototypen großer Systeme zu erstellen - wie für Montagestraßen und Lagerhäuser - und damit schnell zu beginnen und zu testen, bevor sie durch die Implementierung mit anderen Programmiersystemen festgezurrt wurden.
Wir waren darin erfolgreich, APL zu einer ganzen Reihe von IBM-Produkten auszubauen und durch unsere Vorreiterrolle anderen Computerfirmen dabei zu helfen, ihre eigenen APL-Systeme anhand eines internationalen Standards bereitzustellen.
APL fand auch immer wieder Anwendung in akademischen Institutionen als Tool und als Disziplin, womit der eigentliche Zweck seiner Entwicklung erfüllt wurde - seine Verwendung in der Lehre.
APL war natürlich der Vorläufer für Programmiersprachen und -systeme, die Arrays als primitive Datenobjekte behandeln und gemeinsam genutzte Variablen verwenden, um simultan arbeiten zu können. Damit haben wir ohne Zweifel einen starken Einfluss auf weitere Entwicklungen im Bereich der parallelen Programmierung. Es ist sehr befriedigend, zu sehen, dass in den letzten paar Monaten drei verschiedene Computerindustrie-Konsortien begonnen haben, in diesem Bereich voranzugehen.
Unsere Reihe "Berühmte Entwickler ganz privat" wird fortgesetzt!