MSDN Magazin > Home > Ausgaben > 2008 > April >  Interview++: Bjarne Stroustrup zur Entwicklung ...
Interview++
Bjarne Stroustrup zur Entwicklung der Sprachen
Howard Dierking

Hin und wieder bringt ein Entwicklungssprung die gesamte Technik sehr schnell vorwärts und gestaltet sie völlig um. Ein solcher Sprung erfolgte in der Softwareentwicklung mit der Einführung der Programmiersprache C++. Dieser Sprung lag nicht in der Sprache selbst begründet: Objektorientierte Sprachen wie z. B. Simula67 und Smalltalk gab es bereits vor C++. Da C++ aber auf der Programmiersprache C aufbaut (und vorhandene C-Programme kompilieren konnte), konnte es die Abstraktionen objektorientierten Denkens einem breiten Publikum zugänglich zu machen.
C++ hat zu vielen Gedanken rund um Softwareentwurf und -entwicklung angeregt, von Entwurfsmustern bis hin zu Metaprogrammierung. Wegen seiner Übertragbarkeit zwischen Hardwareplattformen und seiner Ausdrucksmöglichkeiten auf niedriger Ebene wird C++ in einer Welt schnellerer, kleinerer Hardware ganz sicher entscheidende Rolle spielen.
Ich hatte kürzlich das Vergnügen, mit Bjarne Stroustrup, dem Erfinder von C++, über eine Vielzahl von Themen zu sprechen, angefangen bei seinen Gedanken zu Sprachen über allgemeine Branchentrends bis hin zu seiner persönlichen Leseliste. Viele der an ihn gestellten Fragen waren von Lesern über meinen Blog vorgeschlagen worden. Deshalb ein Dankeschön an alle, die Fragen beigetragen haben. Und selbstverständlich auch Dank an Bjarne Stroustrup.

Gedanken über Sprache
Howard Dierking Warum sind Programmiersprachen mit Menschen so tief verbunden, dass Communitys von Sprachfanatikern entstehen?
Bjarne Stroustrup Danach sollten Sie lieber einen Psychologen, einen Soziologen oder vielleicht sogar einen Wirtschaftswissenschaftler statt eines Computerwissenschaftlers fragen! Ich vermute, dass die Sprachen, die wir verwenden, um unsere Gedanken auszudrücken, ein Teil von uns werden, mit der Folge, dass, wenn Sie nur eine Sprache kennen, Befürworter anderer Sprachen Ihnen möglicherweise wie eine persönliche Bedrohung erscheinen. Im diesem Fall scheint die Lösung darin zu bestehen, dass man mehrere Sprachen gut kennt. Ich glaube nicht, dass Sie Softwareexperte sein können, wenn Sie nur eine Programmiersprache kennen. Es gibt vielleicht auch einen wirtschaftlichen Grund: Auch wenn die Grundkenntnisse über die Grenzen der Programmiersprache hinausreichen, tun die praktischen Fähigkeiten dies oftmals nicht. Wenn ich also nur die Sprache X und ihre Tools kenne und Sie für die Sprache Y und ihre Tools werben, dann bedrohen Sie meine Existenz. Wieder scheint die Lösung in der Kenntnis mehrerer Sprachen und Toolsets zu bestehen (und im sicheren Beherrschen von Grundlagen). Leider berücksichtigen meine vorgeschlagenen Lösungen nicht, dass den meisten Leuten kaum noch Zeit bleibt, nachdem sie all das erledigt haben, was ihnen zum bloßen Bewältigen ihrer Arbeit notwendig erscheint. Dies ist freilich keine Entschuldigung für fanatischen Eifer.
HD Welche Rolle sollte die IDE in der Softwareentwicklung spielen? Wie sollte die IDE eine Sprache unterstützen?
BS Ich benutze IDEs nicht sehr häufig. Ich schätze einen leistungsfähigen IDE-Editor, der meine Sprache versteht, aber ich möchte auch ohne IDE arbeiten können. Ich hätte vielleicht eine andere Meinung, wenn eine gute IDE universell verfügbar wäre – als Teil der Sprache oder auch umgekehrt (siehe Abbildung 1). Dabei spielt mein Wunsch nach Codeübertragbarkeit eine Rolle. Mit C++ möchte ich mein System allein anhand des Quellcodes in den Quelldateien verstehen können. Ich kann IDE-Mechanismen nicht ausstehen, zu denen Transformationen oder Generierung gehören und die nicht als für den menschlichen Gebrauch geeigneter Code dargestellt werden können.
Abbildung 1 Der IDE-Designer als Sprache (Klicken Sie zum Vergrößern auf das Bild)
HD Betrachten Sie überflüssige Informationen oder die Lesbarkeit bei den heutigen Allzwecksprachen als Problem? Wenn ja, was ist die Lösung?
BS Eine einfachere Syntax wäre schön, aber ich vermute, dass das, worüber die meisten Leute klagen, wenn sie von Lesbarkeit sprechen, weniger der eigentliche Text ist als die Komplexität dessen, was ausgedrückt wird. Zu viele Menschen erwarten, irgendein in einer beliebigen Sprache geschriebenes Programm nehmen zu können und dann – mit nur ein wenig Hilfe durch einen Onlinesupport – alle für das Programm verwendeten Konstrukte sowie die gesamte Logik des Programms selbst zu verstehen. Vergleichen Sie dies mit der Art und Weise, wie wir natürliche Sprachen betrachten und verwenden. Würden Sie erwarten, ein Shakespearesches Sonett ohne Hintergrundinformationen zu verstehen? Was ist mit Beowulf oder Altenglisch? Vielleicht erwarten wir zu viel von unseren Programmiersprachen. Jede Sprache, die alles ausdrücken kann, was für eine große Zahl von Anwendungsbereichen notwendig ist, könnte für jede konkrete Anwendung als unnötig komplex erachtet werden, aber sie muss einen im Grunde unbegrenzten Satz von Anwendungen bewältigen können. Domänenspezifische Sprachen können in Sonderfällen helfen, aber jetzt müssen wir uns mit den Komplexitäten vieler Sprachen und ihren Wechselwirkungen befassen.
HD Wie muss eine Allzwecksprache Ideen für Anwendungsentwürfe wie z. B. Komponentenprogrammierung und Dienstprogrammierung unterstützen?
BS Eine Allzwecksprache muss das Schreiben von Bibliotheken unterstützen, die allgemeine und anwendungsspezifische Konzepte ausdrücken. Sie muss Toolerstellung unterstützen und die Verbindung verschiedener Teile einer Anwendung ermöglichen. Dafür benötigt die Sprache Flexibilität, ein ausdrucksfähiges Typsystem, gute Grundleistung und langfristige Stabilität.
HD Ist Multiple Dispatch sinnvoll?
BS Ja. Eine konventionelle objektorientierte Single Dispatch-Programmiersprache (wie z. B. Simula, C++, Smalltalk, Java und C#) kann nicht auf elegante Weise einfache Vorgänge ausdrücken, wie z. B. das Multiplizieren von Zahlen oder das Ermitteln der Schnittmenge zweier Formen, wenn die genauen Typen bis zur Laufzeit nicht bekannt sind. Der sich ergebende Code (beruhend auf Double Dispatch, dem Besuchermuster usw.) ist langsam und nicht so wartungsfreundlich, wie wir ihn gern hätten. Sprachen, die Multiple Dispatch zur Laufzeit unterstützen (wie Dylan und CLOS), funktionieren besser, und Sprachen (wie z. B. C++), die es zur Kompilierzeit unterstützen, können manchmal ein wenig helfen. Letztes Jahr habe ich zusammen mit einigen meiner Studenten ein Forschungspapier zu dem Thema veröffentlicht, wie zu C++ sauber Multiple Dispatch hinzufügen kann. Der sich ergebende Code für Anwendungsfälle von Multiple Dispatch ist kürzer, einfacher, benötigt weniger Speicherplatz und wird schneller ausgeführt als alle Optionen, die wir gesehen haben (siehe Abbildung 2). Diese Arbeit kam allerdings für C++0x zu spät. Einen Artikel dazu finden Sie unter research.att.com/~bs/multimethods.pdf.
Abbildung 2 Multiple Dispatch über Mehrfachvererbung (Klicken Sie zum Vergrößern auf das Bild)
HD Was denken Sie heute über Kovarianz und Kontravarianz in C++? Erwarten Sie, dass sich das derzeitige Verhalten in zukünftigen Sprachversionen ändern wird?
BS Eigentlich nicht. Ich denke, dass C++ in diesem Bereich das tut, was es soll. Denken Sie an Beispiele wie z. B. das Konvertieren eines vector<Apfel> in ein vector<Obst>? Das ist schrecklich unsicher, es sei denn, vector<Obst> wäre unveränderlich (oder Sie könnten ihm eine Birne hinzufügen). Ich denke nicht, dass implizite Laufzeitüberprüfung ein guter Ansatz für solche Probleme ist.
HD Was halten Sie von Nachrichtenübergabe als Schlüsselfeature einer Sprache im Gegensatz zum Methodenaufruf?
BS Mir gefällt explizite Nachrichtenübergabe, aber ich habe sie nur vor langer Zeit und im Kontext verteilter Systeme verwendet. Damit sie realistischerweise in größerem Maßstab funktionieren kann, müssten wir einiges an Arbeit in Sprach- und Toolunterstützung für Nachrichtenübergabe investieren. Ich glaube nicht, dass dies getan wurde, aber ich könnte mich täuschen. Viele mit gemeinsamer Nutzung und Sperrung verbundene Probleme verschwinden, wenn Sie Nachrichten und Nachrichtenwarteschlangen verwenden. Ich würde sehr gern eine C++-Standardbibliothek hierfür sehen, und vielleicht bekomme ich sie (in einigen Jahren).
HD Gibt es bei Allzwecksprachen einen Konflikt zwischen gleichzeitiger Unterstützung einer breiten, heterogenen Zielgruppe und der Förderung von Verbesserungen bei der Ausdruckskraft des Codes und der Entwurfseleganz? Welche Rolle spielt die Sprache bei der Unterstützung der Eleganz?
BS Ich vermute ja, in dem Sinne, dass Spezialisierung zu Eleganz führen kann. Wenn Sie eine kleine Zielgruppe (Benutzercommunity) haben, besteht außerdem die Möglichkeit, (nur) deren Geschmack zu befriedigen, und Sie können von konventionellen Notationen und Konzepten abweichen, wenn Sie Ihre Benutzercommunity irgendwie lenken können (indem Sie ihr in etwa Folgendes sagen: „Wenn Sie das verwenden wollen, müssen Sie sich über Typentheorie informieren“). Eine Allzwecksprache muss nicht nur eine Vielzahl von Anwendungen unterstützen können, sondern auch für eine große Personengruppe mit unterschiedlichsten Voraussetzungen und Bildungshintergründen erlernbar sein (die Grundlagen müssen auch für jene verwendbar sein, die einen schlechten Lehrer haben).
Daher denke ich, dass eine Allzwecksprache Eleganz so lange fördern kann, wie sich eleganter Code in ihr ausdrücken lässt. In C++ lässt sich sehr eleganter Code schreiben. Als Teil einer Allzwecksprache, die allgemein verfügbar ist, können solche Beispiele in die Hände von Millionen und in Artikel und Lehrbücher, die von Millionen gelesen werden können, gelangen. Keine spezialisierte Sprache, wie elegant sie auch sein mag, hat diese Optionen.
HD Haben wir der Architektur einen zu hohen Stellenwert eingeräumt?
BS Nein, jedenfalls nicht in dem Sinne, wie ich Architektur definieren würde. Im Gegenteil, die Architektur hat einen zu geringen Stellenwert, und es gibt zu viel schlechte Programmierung mit zu wenig Kenntnis der strukturellen Prinzipien. Ich vermute, dass ein Hauptproblem bei der Architektur darin besteht, dass viele Programmierer nur eine unklare Vorstellung davon haben, was einen guten Code ausmacht. Es reicht nicht, es zu erkennen, wenn man es sieht. Es reicht nicht, Regeln für das zu haben, was man nicht tun darf. Wir brauchen klare Vorschriften.
HD War die Open-Source-Community für Softwarequalität und -entwurf sowie für die Professionalität hilfreich, schädlich oder ohne Einfluss?
BS Das ist eine wirklich schwierige Frage. Ich habe Fälle gesehen, in denen sie eine Hilfe war (in denen sie Codequalität und die Professionalität der beteiligten Personen erhöhte), Fälle, in denen sie ein schädlich war (in denen sie wirklich schlechte Angewohnheiten und Einstellungen verbreitete), und viele Fälle, in denen ich es nicht beurteilen kann.
Ich kann nicht abschätzen, wie die Auswirkungen auf die Community als Ganzes waren oder was geschehen wäre, wenn es mehr oder weniger Open-Source-Aktivität gegeben hätte. Die Community ist dafür einfach zu groß.

Sprachtrends
HD Sehen Sie in naher Zukunft eine erhebliche Verschiebung hin zu dynamischen Sprachen?
BS Eigentlich nicht. Ich denke, dass die Leute zu oft Äpfel und Birnen vergleichen. Ich glaube nicht, dass wir im Allgemeinen zwischen statischen und dynamischen Sprachen die Wahl haben, und außerdem glaube ich nicht, dass sich Sprachen eindeutig in die zwei Kategorien einordnen lassen: die meisten, wenn nicht alle dynamischen Sprachen haben Aspekte, die statisch festgelegt sind, und alle wichtigen statischen Sprachen bieten die Möglichkeit, etwas zu tun, was eine Festlegung der Bedeutung von Werten zur Laufzeit erfordert. Selbstverständlich gibt es Modeerscheinungen, und über die kann ich nicht spekulieren, aber ich glaube, dass viele Sprachentscheidungen in Praxis getroffen werden, indem ganz rational von den Anforderungen einer Anwendung, eines Anwendungsbereichs und/oder den Fähigkeiten der verfügbaren Entwickler ausgegangen wird. Zum Beispiel würde ich nicht versuchen, eine Java-Laufzeit in etwa in Ruby zu implementieren oder eine stark interaktive Simulationssprache als C++ auszudrücken (im Gegensatz zu ihrer Implementierung).
HD Halten Sie es für sinnvoll, letztendlich auf void*, variant, object usw. ganz zu verzichten? (Abbildung 3 zeigt ein gutes Beispiel.)
BS Ich denke, dass es im Prinzip eine gute Idee wäre, alle Catchall-Optionen loszuwerden, aber in Wirklichkeit könnten wir das nur erreichen, wenn wir eine vollständige Klassifizierung all dessen hätten, was wir ausdrücken möchten, um jederzeit spezifischer sein zu können. Ich habe zum Beispiel nie eine Funktion gesehen, die für jedes Objekt gepasst hätte. Wenn Sie etwas tun, setzen Sie immer etwas voraus über das, was Sie bearbeiten (eine reine Weiterleitungsfunktion könnte ich mir am ehesten als Gegenbeispiel vorstellen). Die derzeitige Arbeit an Konzepten in der C++-Welt (Einschränkungen/Anforderungen bei generischen Algorithmen) wird hier eine Hilfe sein, aber ich denke nicht, dass wir ohne eine wirklich allgemeine Methode dafür auskommen, etwas auszudrücken, von dem wir überhaupt nicht wissen, was es ist, um auf unerwartete Anforderungen reagieren zu können.
HD Sollten wir angesichts des Trends zurück zu schwach typisierten Sprachen wieder die ungarische Notation in Betracht ziehen?
BS Ich bin nicht sicher, ob es einen solchen Trend gibt, obwohl wahrscheinlich der Anteil der Arbeit, der für schwach typisierten Sprachen geeignet ist, zunimmt. Anders gesagt, könnte meiner Meinung nach die Verwendung statisch typisierter Sprachen weiter wachsen, obwohl die Verwendung schwach typisierter Sprachen noch schneller wächst. Aber verwenden Sie kein Ungarisch. Ungarisch ist eine schreckliche Idee. Der Quellcode sollte die Bedeutung eines Programms widerspiegeln und kein Typsystem simulieren. Wenn Sie wirklich glauben, Ungarisch zu benötigen, verwenden Sie wahrscheinlich eine für Ihre Anwendung ungeeignete Sprache.
HD Im Jahr 2000 führten Sie eine Präsentation mit dem Titel „C++: A New Language for a New Millennium“ vor und führten das Konzept eines Wrap<T> ein. Handelt es sich dabei im Grunde um aspektorientierte Programmierung (AOP). Was halten Sie von AOP (grundsätzlich) und seiner Formalisierung des Wrap<T>-Musters (pointcut, advice usw.)?
BS Ich habe mich nicht lange genug mit AOP beschäftigt, um eine verlässliche Antwort geben zu können. Mir gefällt es, wenn eine Komposition (insbesondere eine nicht intrusive), in einer Sprache unterstützt wird (im Gegensatz zu „nicht unterstützt“ und „durch ein Tool unterstützt“). Besorgt bin ich über außersprachliche Tools und über nicht den Standards entsprechende Toolketten. C++-Vorlagen haben sich bei nicht intrusiver Komposition als erstaunlich erfolgreich erwiesen: Schauen Sie sich nur die Standardvorlagenbibliothek (Standard Template Library, STL) und einige der Verwendungen in der Programmierung eingebetteter Systeme an. Es ist eine wirkliche Stärke, wenn man Ideen kombinieren kann, ohne sie in eine starre oder vordefinierte Hierarchie zu zwingen. Auch für einige Entwickler und Verwalter war dies jedoch schwer zu bewerkstelligen. Es ist auch hinsichtlich der Notation schwer. C++0x enthält Versuche, dabei etwas ohne Flexibilitäts- oder Leistungseinbußen zu erreichen.
HD Bestimmte Merkmale der C++-Sprache haben möglicherweise gefährliche unbeabsichtigte Folgen (wie z. B. Makros). Welche weiteren unbeabsichtigten Folgen gibt es, die Sie in C++ oder in modernen Sprachen allgemein geklärt sehen möchten?
BS Ich wusste natürlich, dass Makros gefährlich sind, als ich C zu verwenden begann. Aber wie die meisten Leute unterschätze ich ihre Gefährlichkeit und ihre weitreichenden negativen Auswirkungen. Die verbreitete Verwendung von Makros in C ist wahrscheinlich der Hauptgrund dafür, dass wir vor einem Jahrzehnt keine herausragenden C++-Entwicklungsumgebungen hatten. Es gibt auch zu viele, zu verwirrende Möglichkeiten, Objekte in C++ zu initialisieren. Ich hoffe, dieses Problem in C++0x mit einem einheitlichen Mechanismus zu beheben. In meiner Antwort auf die vorige Frage habe ich Vorlagen erwähnt. Sie sind der Haupterfolg in höheren C++-Versionen (nach 1985), aber ihr Erfolg stellte eine Belastung für die Sprache dar. Auch dieses Problem soll durch Teile von C++0x behoben werden.
Viele kleinere und weniger kleine Probleme, die wir im Laufe der Jahre entdeckten, können aus Kompatibilitätsgründen in C++ nicht behandelt werden. Zum Beispiel ist die Deklaratorsyntax eine unnötige Komplikation – so ziemlich jede lineare Notation wäre besser. Ebenso sind viele Standardeinstellungen falsch: Konstruktoren dürfen nicht standardmäßig Konvertierungen sein, Namen dürfen nicht standardmäßig von anderen Quelldateien aus zugänglich sein, und so weiter. Den Linker nicht steuern zu können, war eine ständige Quelle von Problemen: Insbesondere scheinen Implementierer ihre Freude daran zu haben, ähnliche Features in unvereinbaren Formen bereitzustellen.
Es gab aber auch positive Überraschungen. Die spektakulärste war die umfassende Verwendung von Destruktoren in Verfahren bezüglich der Ressourcenverwaltung und Fehlerbehandlung (mithilfe von Ausnahmen). Ich wusste, dass Destruktoren eine gute Idee sind – schließlich müssen die Wirkung eines Konstruktors umkehrbar sein –, aber mir war nicht ganz bewusst, wie zentral ihre Rolle beim sinnvollen Einsatz von C++ sein würde.
HD Sie schreiben auf Ihrer Website: „Ich denke, dass wir Eleganz eher bei der Erstellung der Anwendungen suchen sollten als in den Sprachen selbst.“ Bedeutet der Trend zu domänenspezifischen Sprachen (domain specific language, DSL) deren Konvergenz?
BS Ja, da bin ich mir fast sicher. Es ist oft ein Versuch in dieser Richtung. Manchmal funktioniert er sogar.
HD Was denken Sie allgemein über DSLs? Wie stellen Sie sich die Beziehung zwischen DSLs und Allzwecksprachen vor?
BS Mich beunruhigt die Anzahl an Sprachen, die entwickelt, implementiert und mit großem Tamtam eingeführt werden, und die dann ohne bedeutende Ergebnisse wieder verschwinden. Während der in der Regel viele Jahre dauernden Entwicklungsphase bindet eine neue Sprache erhebliche Ressourcen fast ohne jeden Nutzeffekt. Ich habe über dieses Phänomen einen Artikel mit der Überschrift „A Rationale for Semantically Enhanced Library Languages“ (research.att.com/~bs/SELLrationale.pdf) geschrieben. Ich plädiere für die Verwendung von Bibliotheken, die eventuell durch Tools unterstützt werden, sowie für eine Allzwecksprache.
Ich denke, dass eine DSL das letzte Mittel sein sollte, nicht das erste. Wenn überhaupt möglich, muss die DSL fest in einer Allzwecksprache und in Standardtoolketten verwurzelt sein. Eine DSL benötigt für ihre Implementierung und die Implementierung ihrer Laufzeitprimitive eine Allzwecksprache (oder zumindest eine Systemprogrammiersprache). Ich denke, dass eine DSL am besten bewusst und fest mit mindestens einer Allzwecksprache gepaart sein sollte, damit sich neue Komponenten leicht mithilfe von Bibliotheken hinzufügen lassen, die in dieser Allzwecksprache geschrieben sind. Natürlich muss ein Experte mehrere Sprachen beherrschen, aber ich frage mich wirklich, ob nicht die Komplexität verschiedener DSLs so sehr anwachsen könnte, dass sie zum Problem wird. Auch scheinen viele (wenn nicht die meisten) DSLs Allzwecksprachen werden zu „wollen“.
HD Sie haben erwähnt, dass viele Konstrukte in C++ wegen unterschiedlicher Definitionen auf verschiedener Hardware absichtlich mehrdeutig gelassen wurden. Sehen Sie Fortschritte bei der Interoperabilität, die einige diese Konstrukte eindeutig machen könnten?
BS „Mehrdeutig“ ist das falsche Wort. Viel zu viele Dinge wurden undefiniert oder implementierungsdefiniert gelassen. Ich vermute, dass, wenn ich C++ von Grund auf neu umdefinieren könnte, es keine undefinierten und weit weniger implementierungsdefinierte Verhaltensweisen aufweisen würde. Aber ich habe keine Zeitmaschine, und wir können nicht einfach mehrere hundert Millionen Codezeilen unbrauchbar machen, indem wir heute ein paar Entscheidungen treffen.

Methodik und bewährte Methoden
HD Welche Prozessmethodik verwenden und lehren Sie bevorzugt?
BS Erkennen wichtiger Anwendungskonzepte, Erkennen nützlicher Bibliotheken, Erstellen neuer Bibliotheken zur Unterstützung des Anwendungskonzepts, frühes Ausprobieren von Ideen, frühes Integrieren, frühes und häufiges Testen, Verwenden von Dokumentation und Lernmaterial als Entwurfstools und Aufbau größerer Programme aus kleineren (einschließlich Iteration). Es sollte klar sein, dass ich mich im Augenblick auf relativ kleine Projekte konzentriere.
HD Sehen Sie eine Schnittmenge oder Verwandtschaft zwischen einer Sprache und einer Entwicklungsmethodik?
BS Ich glaube ja, soweit Bibliotheksentwicklung als ein Entwurfs- und Entwicklungsverfahren betrachtet wird. Die Konzentration auf Mittel auf immer höherer Ebene (näher an der Anwendung) durch Bibliothekserstellung stellt Anforderungen an die Sprache. Ich würde diesen Punkt nicht übertreiben, aber ich glaube nicht, dass Sie eine einzige Entwicklungsmethodik etwa für COBOL, C, Java, C++ und Python verwenden und dabei erwarten können, mehr als nur minimale Unterstützung durch jede einzelne Sprache zu erreichen.
HD Was sind einige Ihrer persönlichen Faustregeln beim Erstellen von Software?
BS Konzentration auf Schlüsselkonzepte, Konzentration auf deren Schnittstellen, Konzentration auf die Verwaltung von Ressourcen (Speicher, Dateien, Sperren usw.), Konzentration auf Fehlerbehandlung. Schlüsseltechniken sind der Entwurf guter Invarianter für Klassen und RAII (Resource Acquisition Is Initialization).
HD Der Begriff „agile“ ist in aller Munde. Was bedeutet „agile“ für Sie? Unterstützt C++ Agile-Entwicklung?
BS Ich verwende dieses Wort nicht, es ist viel zu vage. Selbstverständlich unterstützt C++ Agile-Entwicklung, was auch immer das bedeutet.

Blick in die Zukunft
HD Wie kann sich eine Sprache so entwickeln, dass sie erweiterte Features wie z. B. Vorlagen, dynamische Ereignisse und selbstschreibenden Code unterstützt und gleichzeitig für Anfänger zugänglich bleibt?
BS Ich weiß nicht. Ich glaube nicht, dass es eine allgemeingültige Antwort darauf gibt. Neue Features können wichtig sein, soweit sie effektivere Verfahren im Kontext einer Sprache unterstützen. Aber Stabilität ist unentbehrlich: Einer der Gründe für die bleibende Stärke von C und C++ ist die Sorgfalt, mit der die Normenausschüsse darauf achteten, dass alter (oft Jahrzehnte alter) Code gültig blieb und neue Features sich nahtlos einfügten. Dies ist gelinde gesagt nicht einfach, und die Einführung neuer Features gelingt nicht immer. Zu oft ignorieren die Mitglieder von Normenausschüssen die Probleme von Anfängern. Einige der für C++0x geplanten Hauptfeatures wie z. B. die einheitliche Initialisierung, das automatische Schlüsselwort (um einen Variablentyp von seinem Initialisierer abzuleiten) und Konzepte wie z. B. die Prüfung von Argumentanforderungen für Vorlagen sollten dazu dienen, Nichtexperten die Anwendung der Sprache zu erleichtern.
HD Betrachten Sie Sprachmetadaten als eine Hauptgrundlage für zukünftige Programmiersprachen?
BS Nein. Persönlich fühle ich mich bei nichttrivialer Anwendung von Metadaten äußerst unwohl.
HD Sehen Sie in der Zukunft eine grundlegende Veränderung in Bezug auf Parallelität, wenn CPUs allmählich mehr Kerne bekommen? Wie könnte der Herausforderung der Parallelität in C++0x begegnet werden?
BS C++0x bietet folgende Grundlagen: ein für Multithreading geeignetes Computermodell, einen Satz von Primitiven auf niedriger Ebene für die Bibliothekserstellung und eine API für eine Thread- und Sperrenbliothek. Ich möchte mehr davon sehen (und wahrscheinlich wird es im Laufe der nächsten Jahre auch dazu kommen), insbesondere ein einfacheres Parallelitätsmodell auf höherer Ebene, das auf Threadpools, Futures und Nachrichtenwarteschlangen basiert. Wir müssen automatische oder halbautomatische Möglichkeiten finden, eine Berechnung über viele Prozessoren zu verteilen und Aktivitäten auf diesen Prozessoren zu lokalisieren. Es gibt eine Menge Arbeit in diesem Bereich, viel in C++, aber es gibt noch kein vorherrschendes Modell. Zu den Beispielen gehören STAPL von der Texas A&M University und TBB von Intel.
HD Was halten Sie von GPGPU (General Purpose Computation on Graphics Processing Unit)?
BS Das ist eine Quälerei, aber ich habe keine praktische Erfahrung damit und kann nicht mehr dazu sagen, als dass es umfangreicher Kenntnisse bedarf, um einen für einen bestimmten Zweck vorgesehenen Prozessor zu verwenden.
HD Sehen Sie kommen, dass Hochleistungscomputing letztendlich für Programmierer transparent wird? Wäre dies außerdem ein Ziel für eine Sprache oder für eine Bibliothek oder ein Framework?
BS Nur etwas transparent. Ich glaube nicht, dass Parallelität vollständig transparent sein kann oder sollte. Zunächst einmal kann Fehlerbehandlung sehr unterschiedlich sein, je nach der Verfügbarkeit der Prozessoren, je nachdem, ob Speicher gemeinsam genutzt wird (oder nicht), je nachdem, ob Systeme verteilt sind (oder nicht), und je nach Latenz. Annähernde Transparenz dort, wo diese zweckmäßig ist, ist ein Ziel für neue Sprachen, neue Sprachfeatures und (mein Lieblingsthema) neue Bibliotheken und wird auch ein Ziel bleiben. Letzteres ist nur durchführbar, wenn die zugrunde liegende Sprache die grundlegenden Garantien bietet, die als Computermodell benötigt werden, sowie einen Satz von Primitiven auf sehr niedriger Ebene. C++0x wird das leisten.
HD Wie kommt der Entwurf von C++0x voran?
BS Wir nähern uns dem Ende – endlich! Zumindest hoffe ich das. Nichts ist sicher, bis die Stimmen ausgezählt sind, und kurz vor dem Ende kann es ziemlich spannungsgeladen und emotional zugehen. Der derzeitige Plan sieht vor, dass wir im Juni den vollständigen neuen Standard zur öffentlichen Diskussion vorlegen, was einen neuen formellen Standard 12 bis 18 Monate später bedeutet. Natürlich könnte ich ein Buch über dieses eine Thema schreiben: Wie schaffen man einen Standard, was sollen die Leitlinien sein, und was genau enthält er? Ich habe das beinahe getan – siehe meinen HOPL-Artikel „Evolving a language in and for the real world: C++ 1991-2006“ (verfügbar unter research.att.com/~bs/hopl-almost-final.pdf) sowie alles mit „C++0x“ in der Überschrift auf meiner Homepage. Wenn Sie ein wenig masochistisch veranlagt sind, können Sie im Internet nach „WG21“ suchen und alle Veröffentlichungen des ISO-Normenausschusses zu C++ (einschließlich aller Vorschläge) heraussuchen. Wenn es sonst nichts bringt, wird es Sie davon überzeugen, dass es viel Arbeit ist. Es ist schwer, eine häufig verwendete Programmiersprache zu verbessern, besonders eine, die in der Implementierungsschicht vieler, vieler Tools, Sprachen und Anwendungen angesiedelt ist. Sie können online und auf meiner C++-Seite auch ein paar Videos von mir und anderen finden.

Bücher und Telefone
HD Was lesen Sie derzeit?
BS Auf technischem Gebiet bin ich zu Hennessy und Patterson zurückgekehrt, zur Auffrischung meiner Kenntnisse über Computerarchitektur, und ich versuche, Artikel zu sammeln, die Benutzern helfen, guten Code zu schreiben (für einen Kurs, den ich gerade anbiete). Solche Artikel zu finden, ist viel schwieriger, als ich erwartet hatte: Akademische Papiere sind oft sehr speziell, und nichtakademische Papiere versprechen oft viel mehr, als sie halten. (Vorschläge sind willkommen.) Dann gibt es selbstverständlich einen ständigen Strom von Unterlagen im Zusammenhang mit der C++-Standardisierung. Ich war kurz davor, mir meinen Knuth vorzunehmen, aber jemand hat sich mit meinem Band III davongemacht, sodass ich warten muss. Zum Vergnügen lese ich wieder ein bisschen aus O'Brians Reihe „Aubrey and Maturin“. Ich versuche, meine wissenschaftlichen Kenntnisse aufzufrischen, und komme gerade von einer Richard Dawkins-Orgie. Vor kurzem habe ich auch Rodgers „Command of the Ocean: A Naval History of Britain, 1649-1815“ zu Ende gelesen (deshalb der Besuch bei O'Brian).
HD Sie haben gesagt: „Ich habe mir immer gewünscht, dass mein Computer genauso einfach zu bedienen wäre wie mein Telefon. Mein Wunsch ist in Erfüllung gegangen, denn jetzt kann ich mein Telefon nicht mehr bedienen.“ Haben Sie ein Smartphone, und ist dessen Bedienung etwas einfacher geworden?
BS Ich bin kein großer Fan von Telefonen. Ich bevorzuge das persönliche Gespräch und, wenn dies nicht möglich ist, das geschriebene Wort. Selbst das tollste Telefon kommt nicht ganz an eine gut formulierte E-Mail heran. Ich verwende ein kleines Telefon, das problemlos in meine Tasche passt, und ich nutze nicht annähernd alle seine Funktionen. Ich würde für Tonqualität und Zuverlässigkeit auf so ziemlich jede Funktion verzichten. Um fair zu sein: Benutzeroberflächen sind heute oft viel besser als zu der Zeit, als ich diese Bemerkung gemacht habe.

Howard Dierkingist Chefredakteur des MSDN Magazins.

Page view tracker