Alles, was Sie tun können, kann ich tun Meta

Am 9. April wird auf einer abgelegenen Startrampe in den Ebenen Kasachstans ein Bodenlotse seinen Countdown beenden; eine Sojus-Rakete wird abgefeuert; und Charles Simonyi – der ehemalige Chefarchitekt von Microsoft, das Genie hinter seinen berühmtesten Anwendungen, der Erfinder der Methode zum Schreiben von Code, die die Programmierer des Unternehmens seit 25 Jahren verwenden, und jetzt der Befürworter eines ehrgeizigen Projekts zur Neuprogrammierung von Software – werden beginnen seinen Aufstieg ins All.

Charles Simonyi Präsident und CEO von Intentional Software.

Eingekuschelt in einen russischen Raumanzug, fühlt sich der 58-jährige Milliardär als fünfter Weltraumtourist auf der ISS. Die Reise, die Simonyi rund 20 Millionen Dollar kosten wird, wird seinen Traum erfüllen, ein Nerd im Weltraum zu werden (um einen Namen zu leihen, den er für die Website gewählt hat, die sein außerirdisches Abenteuer dokumentiert: www.nerdinspace.com ). Es wird ihm auch die Möglichkeit geben, unseren Planeten von oben und außen zu betrachten.



Dies war schon immer Simonyis bevorzugter Blickwinkel. In seiner Karriere, die sich über vier Jahrzehnte erstreckt, hat er jedes Mal, wenn er mit einem hartnäckigen Problem in der Software oder im Leben konfrontiert wurde, versucht, es zu lösen, indem er außerhalb oder darüber hinaustrat. Er hat sogar einen Namen für sein Lieblingsgambit: Er nennt es Going Meta. In seiner Jugend im Ungarn der 1960er Jahre lernte er die Grundlagen der Computertechnik auf einem antiquierten sowjetischen Großrechner, der von Vakuumröhren angetrieben wurde, und entwarf dann seine eigene Flucht in den Westen. In den 1970er Jahren schrieb Simonyi im legendären Palo Alto Research Center (PARC) von Xerox als Teil des Teams, das das Personal Computing erfand, die erste moderne Anwendung: eine Textverarbeitung, die die komplexen Codes verbannte, die dann zum Markieren von Text verwendet wurden, und ein Dokument als es würde auf dem Papier aussehen. Ob in seiner Doktorarbeit an der Stanford University über einen Metaprogrammierungsansatz zur Steigerung der Programmierproduktivität, seiner Karriere bei Microsoft, die Legionen von Softwareentwicklern organisiert und ihnen beibringt, wie sie ihren Code strukturieren, oder seine geplante Reise in die Erdumlaufbahn in diesem Frühjahr, die über etablierte Wege hinausgeht Dinge zu tun war schon immer Simonyis Methode. Jetzt plant er, was er hofft, dass es sein sprunghaftster Meta-Move von allen sein wird. Simonyi glaubt, dass er eine Vielzahl hartnäckiger Probleme lösen kann, die Computer schon immer geplagt haben, indem er jedem, der sie verwendet, und den Programmierern, die sie programmieren, eine höhere Sicht auf die Software bietet.

Bill Gates bezeichnet Simonyi als einen der größten Programmierer aller Zeiten. In der Tat ist Simonyi wohl der die meisten erfolgreicher Programmierer der Welt, gemessen an der finanziellen Belohnung und der Anzahl der Menschen, die seine Kreationen verwenden. (Andere gefeierte Programmier-Milliardäre, wie Larry Ellison und Bill Gates selbst, verdienten ihr Geld und nannten die Gründung und Leitung von Technologieunternehmen.) Simonyi konnte leicht entscheiden, den Rest seines Lebens damit zu verbringen, philanthropische Unternehmungen zu stiften, Flugzeuge zu fliegen oder in seinem . zu kreuzen Yacht. Stattdessen, sagt er, programmiert er wahrscheinlich härter als je zuvor. Er ist besessen von einem Projekt, das er seit anderthalb Jahrzehnten verfolgt und das ihn vor vier Jahren direkt aus den Türen von Microsoft getragen hat. Er ist stolz auf seinen Beruf. Aber er wird auch von dem Gedanken verfolgt, womit sich Programmierer jedes Mal auseinandersetzen müssen, wenn sie sich an den Code setzen. Er fragt: Warum ist es so schwer, gute Software zu entwickeln?

Multimedia

  • Weitere Fotos von Simonyi

Napoleonischer Code

Unsere Zivilisation läuft auf Software, sagt Bjarne Stroustrup, der Erfinder der Programmiersprache C++ (siehe Das Problem mit der Programmierung ) . Aber die Software selbst läuft nicht sehr gut. Wohin Sie auch schauen, Software überschreitet das Budget, ist im Zeitplan, unsicher, unzuverlässig und schwer zu bedienen. Jedes Mal, wenn eine Organisation versucht, ein neues System einzuführen oder ein altes zu aktualisieren, geht dies ein enormes Risiko ein. große informationstechnologische Projekte sind heute technologische Teergruben, die Institutionen immobilisieren. Studien berichten regelmäßig, dass bei zwei Dritteln dieser Projekte erhebliche Verzögerungen, erhebliche Kostenüberschreitungen oder beides auftreten. Die US-Regierung fand es fast unmöglich, groß angelegte Softwaresysteme einzuführen oder zu aktualisieren: Jahrzehntelange Bemühungen bei der Federal Aviation Administration und dem FBI sind im Chaos zusammengebrochen. Den Unternehmen erging es nicht besser. Um ein einziges Beispiel zu nennen: Die Führungskräfte von McDonald's träumten von einem webbasierten Managementsystem namens Innovate, das den Echtzeitfluss von Burgern, Pommes und Chicken Nuggets in jedem ihrer Restaurants auf der ganzen Welt verfolgen würde. Als sie das Projekt aufgaben und abbrachen, mussten sie 170 Millionen US-Dollar der geschätzten Gesamtkosten von 1 Milliarde US-Dollar abschreiben.

Solche Fehler summieren sich. Laut einer Studie des National Institute of Standards and Technology aus dem Jahr 2002 kosten Softwarefehler jedes Jahr 59,5 Milliarden US-Dollar. Aber der Preis für schlechte Software lässt sich auch an menschlichem Elend messen – und sogar an verlorenen Menschenleben. Während des Golfkriegs 1991 feuerte eine Patriot-Raketenbatterie wegen fehlerhafter Software nicht auf einen ankommenden Scud; Der direkte Treffer auf eine Kaserne tötete 28 US-Soldaten.

Im letzten halben Jahrhundert der Computertechnik wurden wunderbare Fortschritte erzielt. Programmierer haben Lochkarten und Fernschreiber aufgegeben. Sie haben uns einen Computer auf jedem Desktop, Werkzeuge für die Arbeit, Spielzeug zum Spielen und ein Netzwerk zur Verfügung gestellt, das Haushalte und Unternehmen zu einem riesigen globalen Pool an Informationen und Unterhaltung verbindet. Dieser Fortschritt wurde durch die exponentielle Kurve des Mooreschen Gesetzes angetrieben, der Vorhersage des Intel-Gründers Gordon Moore, dass sich die Leistung von Mikrochips alle ein bis zwei Jahre verdoppeln (oder ihre Kosten halbieren würden). Aber obwohl das Mooresche Gesetz jedes Jahr neue Computer schneller und billiger gemacht hat, wurden die Flexibilität und der Nutzen unserer Computersysteme durch die langsamere, ungleichmäßige Entwicklung der Software eingeschränkt. Eine Formulierung dieses Problems ist als Wirth’s Law bekannt, nach dem Programmierexperten Niklaus Wirth: Software wird schneller langsamer als Hardware schneller.

Simonyi teilt einen Großteil der allgemeinen Unzufriedenheit mit Software. Software, wie wir sie kennen, sei der Flaschenhals am digitalen Füllhorn, sagt er. Es erfordert enorme Ressourcen an Talent und Zeit. Es ist enttäuschend und schwer zu ändern. Es blockiert Innovationen in vielen Organisationen.

Simonyis Ehrgeiz ist es, diesen Software-Engpass zu beseitigen – charakteristischerweise, indem er Meta geht. Er hat einen Ansatz entwickelt, den er absichtliche Programmierung (oder neuerdings absichtliche Software) nennt, von dem er hofft, dass er die Programmierung umkrempeln wird. Wenn es nach Simonyi geht, werden Programmierer aufhören, die Bedürfnisse ihrer Kunden zu erfüllen. Stattdessen erstellen sie für jedes Problem, das sie lösen müssen – sei es die Bestandsverfolgung oder die Lenkung von Raketen – generische Tools, die die Computerbenutzer selbst modifizieren können, um die zukünftige Entwicklung der Software zu steuern.

An einem grauen Nachmittag im letzten Oktober saß ich mit Simonyi in Bellevue, WA, vor zwei nebeneinander liegenden Bildschirmen in seinem Büro bei Intentional Software, der Firma, die er gründete, nachdem er Microsoft 2002 verlassen hatte, um seine große Idee zu entwickeln und zu kommerzialisieren. Simonyi raste mit mir durch eine Präsentation, die er für eine bevorstehende Konferenz vorbereitete; er verwendete Microsoft Office PowerPoint-Folien, um seine Vision für den vorgeschlagenen großen Sprung nach vorne in der Programmierung zu skizzieren. Er war gerade dabei, eine Folie zu verschieben, als die Anwendung einfach nicht mehr reagierte.

In der Ecke des linken Bildschirms tauchte eine Büroklammer mit gläsernen Augen auf: der weithin geschmähte Office Assistant, den Microsoft 1997 eingeführt hatte. Simonyi versuchte, das antike Zappeln des Cartoon-Assistenten zu ignorieren, aber er wurde behindert. Nichts funktioniert, seufzte er. Das liegt daran, dass Clippy mir etwas hilft.

Ich war verwirrt. Du meinst, du hast Clippy nicht ausgeschaltet? Vor langer Zeit hatte ich die Menüs von Office durchsucht und das Kästchen angekreuzt, das erforderlich war, um den lästigen Anthropomorph ein für alle Mal zu drosseln.

Ich weiß nicht wie, gab Simonyi mit einem kleinen Lachen zu, das zu sagen schien: Ja, ich weiß, ist das nicht ironisch?

Es war. Simonyi leitete jahrelang die Anwendungsteams bei Microsoft, den Entwicklern von Word und Excel, deren Produkte täglich von zig Millionen Menschen genutzt werden. Er gilt weithin als der Vater von Microsoft Word. (Ich verwende natürlich Word, um diese Sätze zu schreiben.) Könnte Charles Simonyi sein Gegenstück in Clippy gefunden haben?

Simonyi starrte seinen Widersacher an, als wäre er in einen telepathischen Kampf verwickelt. Dann drehte er sich mit leuchtenden blauen Augen zu mir um. Ich brauche einen Helfer: einen Super-Clippy, der mir zeigt, wo ich ihn ausschalten kann! Simonyi sehnte sich nach einem Meta-Clippy.

Im Jahr 2004 schlug Simonyi sein eigenes Gesetz vor: Alles, was getan werden kann, könnte „meta“ gemacht werden tun, ich kann Meta machen! Aber wie viele Wunderkinder, die es gut gemacht und gut gealtert haben, hat Simonyi gelernt, seine Überheblichkeit mit einem Hauch von Demut und Anmut zu unterdrücken. Vor zehn Jahren beschrieb er sich selbst als zottelig aussehenden Kerl mit ausländischem Akzent. Er bevorzugt schwarze Rollkragenpullover und zweireihige Blazer. Mit seiner aufrechten Haltung und seinem kantigen Gesicht, einem nach vorne über die Stirn gekämmten dunklen Haarschopf, wird ihm oft nachgesagt, dass er einem Napoleon mit größeren Knochen ähnelt.

Intentional Software ist ein großes Schema in einem Bereich, in dem große Schemata selten funktioniert haben. Jede frühere Innovation, die als Komplettlösung für die Probleme der Software eingeführt wurde, hat am Ende nur bescheidene, inkrementelle Verbesserungen gebracht. Aber Simonyi strotzt nur so vor dem Selbstbewusstsein eines Selfmade-Immigranten, der seine eigenen Stiefel immer fest im Griff hatte. Auf einem Foto, das über seinem Schreibtisch hängt, steht er im Weißen Haus unter einem Porträt von Ronald Reagan. Sein breites Grinsen spiegelt das des Präsidenten wider. Die Bildunterschrift lautet Die zwei Optimisten.

Die Büros von Simonyis neuem Unternehmen befinden sich in einer Suite in einem eleganten gläsernen Wolkenkratzer, und wenn Sie sich durch das Fenster lehnen und nach unten schauen, können Sie das Dach des gedrungenen, unscheinbaren weißen Gebäudes sehen, das 1981 sein erstes Büro bei Microsoft beherbergte. ( Es ist jetzt eine Bank.) Seitdem ist Microsoft bis zur Unkenntlichkeit gewachsen. Die Softwareindustrie hat die Welt verändert. Warum sollte Simonyi sich also daran machen, alle seine Regeln neu zu schreiben? Das Problem ist so groß, dass es scheinbar zur festen Ordnung der Dinge gehört. Simonyis Lösungsvorschlag könnte Jahrzehnte dauern, und seine Kritiker sind äußerst skeptisch. Niemand verlangt von ihm, die bekannten Routinen des Programmierens hinter sich zu lassen und in eine neue Welt aufzubrechen. Aber solche Migrationen haben sich für ihn in der Vergangenheit gelohnt.

Die Sprache der Maschine

Simonyi wurde 1948 in Budapest geboren. Als Sohn eines Physikprofessors verliebte er sich mit 15 Jahren in seinen ersten Computer – einen russischen Mammut-Ural II im ungarischen Statistischen Zentralamt. In den 1960er Jahren war der Ural, der seine Anweisungen über kassenähnliche Schlüssel erhielt und über einen Raum voller Vakuumröhren für Berechnungen verfügte, weltweit bereits ein Relikt. Aber Ungarns kommunistische Führer versuchten, den sowjetischen Abfall zu nutzen, um die Bahn- und LKW-Fahrpläne zu optimieren. Der Ural war dieser Aufgabe nicht gewachsen: Es gab keine Möglichkeit, Echtzeitdaten zu Sendungen einzugeben. Es war völlig aussichtslos, erinnert sich Simonyi. Es hätte sehr einfach durch Angebot und Nachfrage erfolgen können. Das war leider politisch inkorrekt.

Aber Simonyi war das egal. Ich habe diesen Computer geliebt, sagt er, obwohl er nutzlos war. Als Kind hatte er ein Bausatz-Auto mit Viergang-Getriebe gebaut – nicht so sehr, weil er damit spielen wollte, sondern einfach nur verstehen wollte, wie es funktioniert. Ein ehemaliger Schüler seines Vaters verschaffte Simonyi eine Stelle als Nachtschwester im Ural. Da die Maschine jedes Mal, wenn sie aus- und wieder eingeschaltet wurde, eine Röhre ausstieß, zog es das Statistikamt vor, sie die ganze Nacht laufen zu lassen. Von der Abenddämmerung bis zum Morgengrauen gehörte der Mainframe also ausschließlich Simonyi; er hatte einen PC, bevor es solche Dinge gab. Er lernte, es zu programmieren, indem er clevere, aber nutzlose Routinen schrieb, um magische Quadrate zu erzeugen – numerische Arrays, in denen die Summen der Zeilen, Spalten und Diagonalen alle übereinstimmen.

Programmierer anderswo auf der Welt hatten bereits ein Babel an Programmiersprachen erfunden – Fortran, Cobol, Lisp (eine sagenumwobene Sprache: siehe Ancient Text, S. 20) – und so weiter – um ihre Arbeit zu erleichtern, die damals wie heute aus mühsamem Schreiben bestand Ausführliche Anweisungen für Computer zur Ausführung. In diesen Sprachen waren die Anweisungen Textzeilen, die über Tastaturen eingegeben und häufig auf Lochkarten gespeichert wurden. Dieser Quellcode wurde dann kompiliert oder in Maschinencode übersetzt – der eins s und 0 s, die ein digitaler Computer verstehen könnte. Die Methode ist heute weitgehend unverändert geblieben, auch wenn die meisten Programmierer inzwischen Programmiertools verwenden, die auf gewöhnlichen PCs laufen. Aber im Ural lernte Simonyi, auf einer primitiveren Ebene zu programmieren, indem er mühsam die Opcodes der Maschinensprache eintippte, Anweisung für Anweisung die Sequenzen von Speicherabrufen, Hinzufügungen, Speicherablagen und Sprüngen spezifizierte, denen der Prozessor des Computers folgen musste um selbst die trivialste Operation auszuführen. Es war (wie Simonyi dem Autor Steve Lohr im Buch von 2001 sagte Gehe zu ) Steinzeitprogrammierung. Simonyi erinnert sich noch an die Codes. Zweiundzwanzig ist JUMP, sagt er heute. Es ist in mein ROM gebrannt.

Ungarn in den 1960er Jahren, das immer noch vor der sowjetischen Niederschlagung des Aufstands von 1956 zurückschreckte, war kein Ort für einen ehrgeizigen jungen Mann mit einer Vorliebe für Problemlösungen. Mit 17 bekam Simonyi ein Praktikum bei einer dänischen Computerfirma, indem er einigen Programmierern Beispiele seiner handcodierten Ural-Programme zeigte. Die ungarischen Behörden erwarteten eine Rückkehr von Simonyi; einen begehrten Studienplatz hatte er bereits gewonnen. Stattdessen floh er mit der Ermutigung seines Vaters in die Vereinigten Staaten.

Ein Empfehlungsschreiben des dänischen Programmierexperten Peter Naur verhalf ihm zu einer Aufnahme an der University of California in Berkeley. Er bezahlte die Rechnungen mit einem Job im Rechenzentrum von Berkeley, wo er die Aufmerksamkeit eines Fakultätsmitglieds namens Butler Lampson auf sich zog. Lampson war einer der Leiter des Project Genie der U.S. Defense Advanced Research Projects Agency – ein Experiment in Time-Sharing-Computersystemen, bei dem mehrere Benutzer, die an Terminals sitzen, die Gehirnzeit eines einzelnen Computers teilen können. Als die Macher von Project Genie eine Firma namens Berkeley Computer Corporation (BCC) gründeten, deren Ziel es war, eine Maschine zu bauen, die ihre Arbeit kommerzialisieren würde, rekrutierte Lampson Simonyi.

Bei BCC debuggte Simonyi in Zusammenarbeit mit dem Systemdesigner Chuck Thacker die ganze Nacht hindurch den störrischen Prototyp des Unternehmens. Eines Nachts tauchte Simonyi in einem durchsichtigen schwarzen Outfit auf – eine Art Hippie-Ding aus einem der Geschäfte in der Telegraph Avenue, sagt er. Heute kann er sich nicht mehr genau erinnern, warum – vielleicht von einer Party? Das Debugging verlief an diesem Abend besonders gut und das Outfit wurde zu einem Glücksbringer – Simonyis Debugging-Anzug.

BCC ging nach nur wenigen Jahren kaputt, aber Lampson, Thacker und ein Großteil des BCC-Teams wechselten zu Xerox PARC. Simonyi – damals nur ein zufälliger ungarischer Student ohne Green Card, wie er heute sagt – kam 1972 zu ihnen und arbeitete bei Xerox, während er gleichzeitig in Stanford promovierte. Bob Taylor, der während eines Teils dieser legendären Ära das Computer Science Lab von PARC leitete, sagt, Simonyis Kreativität stach selbst in der berühmten Menge des Labors hervor: Er konnte sich einfach vorstellen, Code und Ideen auszudrücken, die ihn von den Charts abhielten.

Es war eine berauschende Zeit. Das Team visionärer Ingenieure schuf eine Reihe von Innovationen, die das nächste Vierteljahrhundert der PC-Ära prägen sollten: die grafische Benutzeroberfläche, die Vernetzung (Ethernet), den Laserdrucker, die objektorientierte Programmierung (Smalltalk), das tragbare Computing (das Dynabook) und mehr. Diese Durchbrüche mündeten alle in einem prototypischen Personal Computer namens Alto.

Der Alto war eine erstaunliche Erfindung, aber es war nicht klar, was man damit machen konnte, bis Simonyi und seine Kollegen seine bekannteste Anwendung entwickelten: ein Textverarbeitungsprogramm namens Bravo, dessen Schrift auf dem Bildschirm der Ausgabe des Systems entsprach zum neuen Laserdrucker. Bestehende Textverarbeitungsprogramme verfügten über ausgeklügelte Codesysteme zum Formatieren von Text auf dem Bildschirm (jeder, der WordPerfect in den 1980er Jahren auf einem PC verwendet hat, wird sich an die eingebetteten Codes erinnern); Mit Bravo können Sie die Codes vergessen, das Design eines Dokuments direkt manipulieren und die Änderungen sofort miterleben. Ein leitender Angestellter der Citibank schaute sich eine Demo an und zitierte eine charakteristische Zeile der frechen Figur Geraldine des Komikers Flip Wilson: What you see is what you get! Der Name (auf das Akronym Wysiwyg reduziert und ausgesprochen Wizzywig ) stecken. Plötzlich hatte Bravo Benutzer: Verwandte und Freunde von PARC-Forschern baten darum, es zum Drucken von Schulnewslettern und zum Formatieren wissenschaftlicher Arbeiten zu verwenden. Lampsons Frau druckte ihre Abschlussarbeit mit dem System, und als es für Simonyi an der Zeit war, seine zu drucken, tat er dasselbe.

Abstraktionsebenen

Wysiwyg ist ein Beispiel für eine Abstraktionsschicht – ein Werkzeug auf höherer Ebene, das es Computerbenutzern ermöglicht, eine gewisse Komplexität auf niedrigerer Ebene zu ignorieren. Programmierer verwenden ständig Abstraktionen. Der in einer Programmiersprache geschriebene Textcode ist eine Abstraktion des Maschinencodes, den ein Computer tatsächlich versteht. Ein Web-Domain-Name ist eine Abstraktion der numerischen Internet Protocol-Adresse eines Servers.

ein Affe mit gutem Farbsehen

Aber die meisten Abstraktionsschichten in Computersystemen sind weniger sichtbar und geheimnisvoller als Wysiwyg. Seitdem Programmierer aufgehört haben, sich die Opcodes zu merken, die Simonyi in seiner Jugend verwendet hat, schichten sie neue Abstraktionen auf ältere Abstraktionen. Jede Generation von Programmierern verwendet die Programmiersprachen und Werkzeuge ihrer Ära, um die Programme der nächsten Generation zu erstellen. Abstraktionsschichten haben sich wie geologische Schichten angesammelt. Nachrichten rasen ständig vom binären Grundgestein Ihres Computers nach oben und wieder zurück, sodass ein Mausklick seine Funktion ausführen kann. Ihr Mausklick löst einen Code im Betriebssystem aus, der eine Nachricht an das Textverarbeitungsprogramm sendet, das das Betriebssystem anweist, Ihre Datei auf einer Festplatte zu speichern. Aber dieser scheinbar einfache Prozess ist nur aufgrund vieler, vieler Abstraktionsschichten möglich.

Die Geschichte der Software ist die Geschichte dieser Schichten, von denen jede Programmierer weiter von der Binärdatei entfernt, wodurch sie besser in der Lage sind, Computer dazu zu bringen, nützliche Aufgaben auszuführen. Ständig gewannen Programmierer mehr Macht. Aber sie gingen auch immer ehrgeizigere Probleme an. Programme wurden immer größer, und Programmierer verloren sich im Gewirr von sogenanntem Spaghetti-Code, der sich als unmöglich herausstellte und reparierte. So wurden große Softwareprojekte zu Epen der Frustration und Verzögerung. Programmmanager standen vor geschäftlichen Problemen wie: Wie planen Sie ein Projekt realistisch? Wie verbessern Sie die individuelle Produktivität? Wie koordinieren Sie komplexe Aufgaben in einem großen Team? Jede dieser Fragen erwies sich als überraschend schwer zu beantworten.

Die Schwierigkeit, die Arbeit eines Teams zu koordinieren, inspirierte das berühmteste Diktum der Softwareentwicklung, das als Brooks’ Gesetz bekannt ist: Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später. Frederick P. Brooks Jr. kam zu dieser düsteren Schlussfolgerung, nachdem er in den 1960er Jahren die schwierigen Bemühungen von IBM angeführt hatte, Software für seine 360-Mainframes zu schreiben. In seinem 1975 erschienenen Buch Der mythische Mann-Monat , beobachtete Brooks, dass die Arbeit in größeren Teams aufgrund der Koordinationskosten langsamer voranschreitet – die Zeit, die Programmierer verlieren, um sich gegenseitig über ihre Arbeit auf dem Laufenden zu halten.

Dies war der Hintergrund für Simonyis Dissertation von 1977 mit dem Titel Meta-Programming: A Software Production Method. Simonyi schlug einen neuen Ansatz zur Optimierung der Produktivität vor, bei dem ein leitender Programmierer oder Meta-Programmierer ein Produkt entwarf und alle seine Begriffe definierte und dann einen Entwurf an Techniker übergab, die die Implementierung durchführen würden. Simonyi wollte dem Brooks-Gesetz entkommen, indem er den Technikern verbot, miteinander zu sprechen: Die gesamte Kommunikation musste über den Meta-Programmierer laufen. Für seine Dissertation testete er die Idee mit zwei Gruppen an zwei Projekten, A und B. Sein despotischer Programmieransatz setzte sich nie durch, störte ihn aber kaum. Simonyis Hauptziel bei der Recherche seiner Dissertation war nicht, den Wert seiner Ideen zu beweisen, sondern Bravo, das neue Wysiwyg-Textverarbeitungsprogramm, schneller schreiben zu lassen. Er konnte die PARC-Chefs nicht davon überzeugen, zusätzliche Programmierer einzustellen, also nutzte er seine Dissertation als Vorwand, um Hilfe zu holen. Bravo selbst war Projekt B.

Im Laufe der 1970er Jahre wurde Simonyi ungeduldig, weil Xerox nicht in der Lage war, die bahnbrechende Forschung von PARC in erfolgreiche Produkte umzuwandeln. Eines Tages zeigte ihm ein Freund VisiCalc, das neue Tabellenkalkulationsprogramm für den Apple II. Es hat Simonyi begeistert. Hier war eine andere Anwendung wie Bravo, die das Leben der Menschen verändern könnte, aber im Gegensatz zu Bravo lief sie auf einem Massenmarktcomputer, den sich die Leute leisten konnten. Er erkannte, dass die Arbeit von PARC nie das Licht der Welt erblicken würde. Er bat seinen ehemaligen PARC-Kollegen Bob Metcalfe, der 1979 das Labor verlassen hatte, um 3Com zu gründen, angehende Chefs in der noch jungen PC-Branche zu empfehlen. An der Spitze der Liste stand Bill Gates.

1981 zog Simonyi nach Seattle, um die New-Applications-Gruppe bei Microsoft zu gründen, die bis dahin Programmiersprachen und Betriebssysteme verkauft hatte. Er war 33, aber das machte ihn zu einem Erwachsenen unter den Jünglingen von Microsoft (Gates war damals 26 Jahre alt, Steve Ballmer 25).

In all den Jahren, in denen Simonyi die Produkte beaufsichtigte, die schließlich zu der als Microsoft Office bekannten Programmsuite zusammengeführt wurden, suchte er weiterhin nach neuen Effizienzen in neuen Arten von Programmierabstraktionen. Vor allem hat er Generationen von Microsoft-Programmierern darin geschult, den Überblick über die unzähligen Variablennamen zu behalten, die in großen Programmen verwendet werden. In der Computerprogrammierung stellen Variablen Informationen dar, die sich während der Ausführung eines Programms ändern können. Zum Beispiel enthält das Warenkorbprogramm eines Online-Shops Variablen, die die Anzahl der zu kaufenden Artikel jeder Art, den Preis jedes Artikels sowie die Versandkosten und Steuern darstellen. Mit diesen Variablen kann ein Programmierer eine einfache Codezeile schreiben, die die Menge mit dem Preis multipliziert, Versand und Steuern hinzufügt und die Gesamtkosten berechnet – die zum Wert einer weiteren Variablen werden.

Ein großes Programm kann Tausende von verschiedenen Variablen haben, die ein Programmierteam in Ordnung halten muss. Es wird entscheidend, sie sorgfältig zu benennen. Heutzutage enthält der meiste Code Variablennamen, die den Programmierern, die ihn lesen, eine Bedeutung vermitteln sollen – Namen wie NumberOfItems oder ShoppingCartTotal. In Simonyis Namensschema, das er vor Jahren für seinen eigenen Gebrauch erfunden hatte, enthält jeder Variablenname ein Präfix, das Ihnen nützliche Informationen wie den Typ (z. B. ganze Zahl, Dezimalbruch oder Buchstabenfolge) mitteilt. Einige Systeme begrenzen die Länge von Variablennamen auf acht Zeichen; Simonyi hat die Vokale einfach weggelassen.

Der resultierende Code war dicht und schwer zu lesen. Simonyis System wurde als ungarische Notation bekannt, sowohl als Hommage an den Geburtsort seines Schöpfers als auch weil es Programme aussehen ließ, als wären sie in einer undurchschaubaren Fremdsprache geschrieben, so der Programmierpionier Andy Hertzfeld. Ungarisch wird von seinen Kritikern weithin verflucht. Der kanadische Java-Experte Roedy Green hat es scherzhaft als die taktische Nuklearwaffe der Quellcode-Verschleierungstechniken bezeichnet. Mozilla-Programmierer Alec Flett hat diese Parodie geschrieben:

prepBut nI vrbLike adjUngarisch! qWas ist KunstDas adjBig nProblem?

Hertzfeld schrieb über eine Begegnung bei Apple mit einem ungarischen Code, der von einem Kollegen geschrieben wurde, der mit Simonyi bei PARC zusammengearbeitet hatte, und sagte, die Namen sahen aus, als wären sie von Supermans Feind aus der 5. Dimension, Mr. Mxyzptlk, ausgewählt worden.

Aber während Kritiker meinen, Ungarisch mache Code unleserlich, ist Simonyi stolz darauf und verwendet ihn bis heute.

Meta-Euphorie

In den frühen 1990er Jahren hatte der Erfolg von Microsoft Simonyi zu einem Vermögen gemacht. (Seit einigen Jahren, Forbes hat es auf 1 Milliarde Dollar geschätzt.) Aber er fühlte immer noch das Ziehen unvollendeter Geschäfte. Die Verwirrung der Software hatte die Entwicklung von Office für Microsoft nervenaufreibend gemacht. Aber jetzt, mit Computern, die auf jedem Schreibtisch leistungsfähiger sind als der Alto, und dem Internet, das sie miteinander verbindet, war die Krise der Software die Krise aller. Simonyi begann zu denken, dass es an der Zeit sei, wieder Meta zu werden.

Charles hat immer versucht, seine Systeme so aufzubauen, dass der Abstraktionsgrad erhöht wird, damit Sie die Komplexität des Systems bewältigen können. Denn Komplexität ist der Tod, sagt Chuck Thacker, Simonyis alter Kollege von BCC und PARC, der bei Microsoft ein Forschungsprojekt zur Computerarchitektur leitet. Und leider führt heutzutage die Bereitstellung der Einrichtungen, die die Menschen tatsächlich wünschen, zu einem komplexen System. Wir hängen gerade mit unseren Fingerspitzen durch.

Simonyi wechselte zu einer Position bei Microsoft Research und begann, das Konzept der Intentional Programming, kurz IP, zu definieren. Absichtliche Programmierung würde der Praxis des Schreibens von Software eine völlig neue Abstraktionsebene hinzufügen. Es würde Programmierern ermöglichen, ihre Absichten auszudrücken, ohne im Sumpf sogenannter Implementierungsdetails zu versinken, die sie immer zu verschlingen drohten. Wie die Meta-Programmierer von Simonyis Dissertation, die Anweisungen an Arbeiter-Bienen-Codierer weitergaben, gab der absichtliche Programmierer die Arbeit ab – aber nicht an einen jüngeren Kollegen. Stattdessen erforderte die absichtliche Programmierung eine Art Code-Fabrik namens Generator, ein Programm, das eine Reihe von Befehlen auf relativ hoher Ebene aufnimmt und detaillierteren Arbeitscode ausspuckt. Das Ziel war nicht so sehr, die Programmierarbeit zu erleichtern, sondern es den Programmierern zu ermöglichen, ihr Gehirn von Trivialitäten zu befreien, damit sie tatsächlich kreativ sein können.

Seit seiner Einführung in die Programmierung als Teenager, der Opcodes in den Ural einstanzte, hatte Simonyi die Leiter der Abstraktion erklommen. Aber er hatte das Gefühl, nicht hoch genug zu sein. In vielerlei Hinsicht fühlte sich das Programmieren immer noch primitiv an. Warum wurden Programmierer immer noch mit inkompatiblen Programmiersprachensyntaxen gesattelt? Warum war es so schwer, ihre bevorzugten Sprachen auf neue Gebiete auszudehnen? Warum arbeiteten Programmierer immer noch mit Klartext und ordneten eine kleine Anzahl von Zeichen zu linearen Strings an, wie sie es in der Lochkarten-Vergangenheit getan hatten? Simonyis Wysiwyg-Arbeit hatte Büroangestellte davon befreit, komplexe Dokumente zu erstellen und zu bearbeiten. Ingenieure und Designer verwendeten fortschrittliche CAD/CAM-Tools, um Pläne für Wolkenkratzer und Flugzeuge zu entwerfen und zu modifizieren. Warum pickten Programmierer, die Zauberer, die all dies möglich gemacht hatten, immer noch Zeichen für Zeichen ihren Code heraus?

Sein Microsoft-Research-Team machte sich an die Arbeit, und bis März 1995 hatten sie ein funktionierendes System zum Erstellen von Programmen unter Verwendung des Intentional-Programming-Ansatzes aufgebaut. Simonyi sagte, IP habe vollständige Selbstversorgung erreicht: Das heißt, alle zukünftigen Arbeiten an IP würden mit IP selbst erledigt. Er belohnte sein Team mit T-Shirts, auf denen eines seiner Lieblingsbilder aus seiner Kindheit prangte: das Bild von Baron Münchhausen, der sich und sein Pferd aus einem Moor hebt, indem er an seinen eigenen Haaren zieht. Simonyi kündigte der Welt in einem Artikel vom September 1995 mit dem Titel The Death of Computer Languages ​​absichtliches Programmieren an. Es war an der Zeit, wie er später sagte, dass die Kinder des Schusters Schuhe besorgen.

In den 1990er Jahren und bis ins neue Jahrtausend hinein – während Microsoft seine Kriege mit Netscape und dem US-Justizministerium führte und die Dot-Com-Blase und Pleite überstanden – arbeiteten Simonyi und sein Team und lernten.

Unterdessen drängte Microsoft ab 2001 die Armeen der Entwickler, die Software für Windows schrieben, ein neues Programmiersystem namens .Net Framework einzuführen. Im Gegensatz zur absichtlichen Programmierung war .Net fertig und erforderte einen weniger radikalen Bruch mit bestehenden Programmiertechniken. Simonyi juckte es, seine Idee aus dem Labor zu holen und den Kunden vorzustellen, aber das war unter den gegebenen Umständen umständlich. Er erklärt: Als Microsoft in naher Zukunft enorme Fortschritte mit .Net machte, war es unpraktisch, jemanden aus derselben Organisation zu schicken, der sagt: So sollte man die Dinge nicht machen – was wäre, wenn man Dinge in diesem anderen tat? , störender Weg?

Simonyi war mehr als 20 Jahre lang ein Angestellter im Unternehmen. Aber 2002 verließ er Microsoft und gründete ein unabhängiges Unternehmen. Er ging mit einer Patent-Kreuzlizenzvereinbarung aus, die es ihm erlaubte, die Konzepte und Ideen seiner Forschungen zur absichtlichen Programmierung zu verwenden, ihm jedoch nicht erlaubte, seinen alten Code mitzunehmen. Er müsste von Grund auf eine neue Codebasis schreiben.

Unter dem Banner seines neuen Unternehmens ließ Simonyi das Wort Programmierung fallen und benannte sein Projekt in absichtliche Software um. Die Grundidee hatte sich nicht geändert, aber jetzt begann er, den Wert des Ansatzes für Nicht-Programmierer zu betonen. Simonyis Pitch ging ungefähr so: Heute kann nur noch der Programmierer direkt auf die Software einwirken. Fachexperten oder Domänenexperten – die Personen, die tatsächlich verstehen, was die Software tun muss, sei es die Führung von Krankenakten, die Unternehmensbuchhaltung oder die Klimamodellierung – können keine Änderungen an ihren Tools vornehmen. Sie sind gezwungen, dem Programmierer eine Art bescheidene Anfrage zu stellen. Intentional Software würde Softwareentwicklungstools nicht nur an Programmierer verkaufen, sondern auch an Domänenexperten, die ihr Gebiet wirklich kennen.

Die Strategie von Intentional Software orientiert sich an einem Programmiertrend, der als domänenspezifische Sprachen oder DSLs bekannt ist – kleine Programmierdialekte, die auf die Bedürfnisse bestimmter Disziplinen abgestimmt sind. Simonyi lobt DSLs, sagt aber, dass sie nicht weit genug gehen. Sie sind schwer zu erstellen und daher kostspielig; Sie benötigen am Ende mehr als eine (für ein medizinisches Abrechnungssystem benötigen Sie mindestens eine medizinische und eine finanzielle Sprache); und sie sind nicht miteinander kompatibel. Das System von Intentional Software ist wie eine Fabrik für mehrere DSLs, die miteinander kommunizieren können.

So könnte es funktionieren: Angenommen, eine internationale Bank möchte ein neues System zur Verwaltung von Transaktionen in mehreren Währungen entwickeln. Zunächst definieren die Experten der Bank im eigenen Bereich die Funktionalität des Systems, indem sie ihre üblichen Begriffe und Symbole verwenden und die wichtigsten Variablen (Zeit oder Wert oder Größe der Transaktion) und die gebräuchlichsten Verfahren (Bestände von einer Währung in eine andere umwandeln oder Absicherung kaufen) identifizieren gegen fallenden Wert). Dann würden die Programmierer diese Informationen nehmen und einen domänenspezifischen Programmgenerator bauen, der diese Informationen verkörpert. Ein separates Softwaretool würde es den Domänenexperten ermöglichen, mit verschiedenen Datensätzen zu experimentieren und diese Daten so einfach anzuzeigen, wie Geschäftsleute heute ihre Tabellenkalkulationen neu anordnen.

Der Programmierer müsste nicht jedes Mal gerufen werden, wenn eine neue Entwicklung in der Welt des internationalen Bankwesens oder einer anderen Domäne eine neue Softwarefunktion erfordert. Der Kunde würde sich nicht durch eine Programmiersprache eingeengt fühlen. Alle würden sich freuen.

Simonyi argumentiert, dass sein Ansatz einige der hartnäckigsten Probleme der Softwareentwicklung löst. Programmierer von heute, sagt er oft, seien ahnungslose Kryptographen: Sie sammeln Anforderungen und Wissen von ihren Kunden und verstecken dann diese wertvollen Informationen buchstäblich in einem Berg von Implementierungsdetails – das heißt Code. Der Haken daran ist, dass die Programmierer, sobald der Code geschrieben ist, alle Ergänzungen oder Änderungen durch Modifikationen vornehmen müssen der Code selbst . Diese Arbeit ist mühsam, langsam und fehleranfällig. Wir sollten den Code überhaupt nicht anfassen, sagt Simonyi. Wir sollten in der Lage sein, Funktionen und Datenstrukturen zu entwerfen – die absichtliche Programmierung als absichtliche Bäume repräsentiert – und den Generator den Code entsprechend modifizieren lassen. (Eine ausführlichere Beschreibung der absichtlichen Programmierung finden Sie unter Absichtliche Programmierung erklärt )

2002 stellte Simonyi ein neues Entwicklungsteam zusammen; heute umfasst es ein Dutzend Programmierer, aufgeteilt auf Bellevue und Ungarn. Sie begannen, Simonyis absichtlichen Programmiercode von Grund auf neu zu erstellen und arbeiteten mit einer Handvoll Kunden zusammen, um ihre Annahmen zu testen und Feedback zu erhalten. Vor einem Jahr haben sie, inspiriert von einer neuen Einsicht in die Präsentation mehrerer Ansichten heterogener Datentypen, einen Großteil ihres Codes weggeworfen und neu begonnen. Es ist kreative Zerstörung, sagt Simonyi. Bei Microsoft war das ziemlich schwer, alles wegzuwerfen. Aber Sie müssen auf Dinge verzichten, die schwer zu erweitern sind.

ThoughtWorks, ein globales IT-Beratungsunternehmen, ist ein früher Kunde von Intentional Software. Roy Singham, CEO von ThoughtWorks, sagt jedoch, dass viele seiner Kollegen im Unternehmen Simonyis neuem Projekt anfangs skeptisch gegenüberstanden: Viele Leute sehen sich das an und sagen: „Brillantes Konzept – aber es ist nicht umsetzbar.“ Also haben wir einige unserer gefragt Die besten technischen Köpfe, um nachzusehen, und alle kamen zurück und sagten, er sei auf dem richtigen Weg. Ja, es ist schwer. Ja, es wird Zeit brauchen – vielleicht viele Jahre. Aber intellektuell hat er es auf den Punkt gebracht. Es ist das richtige Problem zu lösen.

Ich bin frustriert, dass wir noch nichts haben, was wir tatsächlich in der Produktion verwenden können, sagt Martin Fowler, leitender Wissenschaftler bei ThoughtWorks. Charles scheint es mit dem Versand nicht eilig zu haben. Aber man sollte bedenken, dass er in der Vergangenheit mit Office ziemlich dramatische Dinge geliefert hat.

Das sichtbare Ergebnis der bisherigen Arbeit von Intentional ist ein raffiniertes Tool namens Domain Workbench, das die wichtigen Informationen eines Programms in einer Intentional-Tree-Datenbank speichert und Ihnen dann viele verschiedene Projektionen dieser Informationen bietet. In einer Demonstration, die Intentional im vergangenen Herbst auf zwei Konferenzen gab, nahm die Workbench – unter Verwendung einer Funktion namens Kaleidoskop – eine Reihe von Codefragmenten und zeigte sie in einer schwindelerregenden Vielfalt von Formaten an. Es spielte keine Rolle, wie die Syntax des Codes angegeben wurde; Sie können es anzeigen und ändern, indem Sie eine beliebige Notation verwenden. Sie können Ihr Programm als traditionellen Code in Klammern und eingerückt bearbeiten oder zur Umrissform wechseln oder es wie einen schematischen elektrischen Schaltplan aussehen lassen oder etwas wählen, das als Eisenbahndiagramm bezeichnet wird, eine Art Flussdiagramm-Notation, die von altmodischen Zugkarten abgeleitet ist . Jede Ansicht ist eine Übersetzung des zugrunde liegenden Baums, den Sie auch untersuchen und bearbeiten können.

Die Arbeit von Intentional Software provoziert zwei Hauptkritikpunkte. Einige theoretisch denkende Skeptiker halten Simonyis Ziel, die Absichten von Computernutzern zu erfassen, für unglaubwürdig. Wie vertritt man Absicht? fragt der Informatiker Jaron Lanier. Sobald wir wissen, wie das Gehirn Informationen speichert, können wir vielleicht Absichten darstellen. Für mich scheint es nur eine Fantasie zu sein. Ein anderes Argument, das Programmierern häufig vorkommt, ist praktischer. Viele Programmierer lieben ihre textbasierten Editoren und misstrauen Tools, die sie vom Rohcode distanzieren. Grafische Programmiersprachen wie Visual Basic und die integrierten Entwicklungsumgebungen (IDEs), die routinemäßige Programmieraufgaben automatisieren, betrachten sie mit Herablassung: Solche Werkzeuge, sagen sie, zwingen ihre eigenen Vorgehensweisen auf, schränken die Kreativität ein und halten Programmierer von der Code, dem sie früher oder später begegnen müssen. (Um zu verstehen, warum Programmierer so vorsichtig sind, lesen Sie Das Gesetz der undichten Abstraktionen.) Skeptische Programmierer betrachten Intentional Software und sehen die Aussicht auf eine weitere IDE. Für diejenigen, die denken, dass echte Programmierer Texte schreiben, ist absichtliches Programmieren weder sehr originell noch sehr erwünscht.

Aber meistens wird in den wimmelnden Programmierforen des Internets überraschend wenig über Intentional Software diskutiert. Das liegt zum Teil daran, dass so wenige seine Software gesehen haben. Die Arbeit von Intentional wurde mit einiger Geheimhaltung vorangetrieben.

Als er Intentional Software gründete, arbeitete Simonyi mit einem Professor der University of British Columbia namens Gregor Kiczales zusammen. Simonyi bewunderte die Arbeit von Kiczales zur aspektorientierten Programmierung – einer Methode zum Organisieren und Modifizieren von Code gemäß übergreifenden Anliegen, die der absichtlichen Programmierung ähnelt. Kiczales, ein weiterer PARC-Veteran, hat seine Karriere damit verbracht, an Möglichkeiten zu arbeiten, den Code wie das Design aussehen zu lassen. Kiczales sah in seinem Wechsel zu Simonyi eine Chance, dieses Ziel voranzutreiben. Aber Kiczales vertraute der Open-Source-Entwicklung, was Simonyi nicht tat. Der Closed-Shop-Ansatz im Microsoft-Stil fühlte sich für Kiczales einfach nicht organisch an. Ich hätte es in Java gemacht, sagt er. Die erste Veröffentlichung wäre in sechs Monaten gewesen. Die Meinungsverschiedenheiten seien freundlich, aber unversöhnlich gewesen, sagen beide Männer, und schon bald sei Kiczales gegangen.

Im Moment hat Intentional Software, geschützt durch Simonyis Reichtum, weder ein Zieldatum noch eine Versandfrist. Einer der beiden Hauptkunden behauptet jedoch, kurz vor der Bereitstellung von Intentional-Tools zu stehen. Capgemini – ein in Paris ansässiges internationales IT-Dienstleistungs- und Beratungsunternehmen, das große Unternehmen betreut und dessen CTO Andy Mulholland ein Bekannter von Simonyi ist – begann im vergangenen März mit Intentional zusammenzuarbeiten und erwägt, das System von Intentional für Projekte im europäischen Rentengeschäft einzusetzen. Die sehr komplexen Regeln des Bereichs, die mit der komplexen Geschäftsbereichsstruktur verflochten sind, lassen Simonyis Ansatz attraktiv erscheinen, sagt Henk Kolk, Financial Services Technology Officer bei Capgemini, der die Arbeit des Unternehmens mit Intentional leitet.

Bodenkontrolle

Simonyis Faszination für den Weltraum besteht ein Leben lang. Als 13-Jähriger gewann er einen Wettbewerb um Ungarns Junior Astronaut zu werden und reiste nach Moskau, um einen Kosmonauten zu treffen. Als neuer Mitarbeiter bei Microsoft im Jahr 1981 überzeugte er den Mitbegründer Paul Allen, von der Entwicklung des neuen Betriebssystems des IBM-PCs begeistert zu sein und nach Florida zu fliegen, um den ersten Flug des Space Shuttles zu sehen.

Simonyis bevorstehender Blasstoff bietet ihm ein Wiedersehen mit der Technologie aus der Sowjetzeit, die sein Leben bestimmt hat. Er trainiert seit Monaten im russischen Yuri Gagarin Cosmonaut Training Center in Star City, beherrscht die Details von Raumanzügen und Weltraumtoiletten und lernt Russisch.

Die Weltraumreise wird Simonyis Status als höchst unwahrscheinliches Ding bestätigen: ein berühmter Programmierer. Er hat zwei Jets und einen Pilotenschein, um sie zu fliegen. Er taucht in den Boulevardzeitungen als häufiger Begleiter der Hohepriesterin der Hauswirtschaft, Martha Stewart, auf. Er hat eine 233-Fuß-Yacht mit einem rundum verglasten Deck gebaut. Er hat seinem Freund Richard Dawkins, dem darwinistischen Theoretiker, eine Oxford-Professur finanziert.

All dies wird natürlich keinen Einfluss auf das Ergebnis von Simonyis Bemühen haben, die chronischen Probleme der Softwarebranche zu lindern. Es reicht nicht, ein großartiger Programmierer zu sein, sagte Simonyi einmal zu Michael Hiltzik, dem Autor einer Geschichte von PARC. Sie müssen ein großes Problem finden. Intentional könnte seine großen Versprechen nie einlösen. Aber niemand kann Simonyi vorwerfen, ein zu bescheidenes Problem gewählt zu haben.

Sein Zuhause ist heutzutage eine Villa am Lake Washington, am Ufer von Bill Gates' Haus, mit einer Kunstgalerie, einem verglasten Swimmingpool, einem Hubschrauberlandeplatz, einem Computerraum mit magnetisch ausgekleideten Wänden und einer Dreh- und Bohrmaschine im Keller (um das Verlangen nach Erector Set zu stillen). Der Bau des Hauses hat 10 Millionen US-Dollar gekostet: Es ist in einem Winkel von sieben Grad geneigt und sieht aus, als hätte es ein leichtes Erdbeben getroffen, in den Worten von New York Times Schriftstellerin Patricia Leigh Brown, die ihre hermetisch abgeschlossene, mathematische Präzision erstaunte und sie so groß fand, dass sich ein Besucher wie ein einsamer Asteroid fühlen kann, der um das Sonnensystem rattert.

[Nur] Charles würde ein 20.000 Quadratmeter großes Haus mit einem Schlafzimmer bauen, bemerkte Simonyis Dissertationsberater und PARC-Kollege Butler Lampson einmal. Das einzige Schlafzimmer verfügt über ein Cockpit-ähnliches Kontrollzentrum, mit dem Simonyi alle seine Systeme – Heizung, Unterhaltung, Telefon, Beleuchtung und Bewässerung – zu seiner Zufriedenheit einstellen kann. Wie ein U-Boot, erklärte er Brown. Sie müssen alle grün sein, bevor Sie untertauchen. Es gibt auch ein schwenkbares Bett, mit dem Simonyi seinen Blick auf den See verfeinern kann; oder hinüber zur Skyline von Seattle mit ihren Gewirr von Büroangestellten, die mit ihren Dokumenten und Tabellenkalkulationen ringen; oder hinauf in den sternenklaren Nachthimmel, wohin ihn bald seine neueste Reise führen wird.

Scott Rosenberg ist Vizepräsident für Sonderprojekte bei Salon.com. Er ist der Autor von Träumen im Code.

Absichtliche Programmierung erklärt
Simonyi und Co. sind Vorreiter bei der Programmierung per Knopfdruck.

[ Hier klicken für ein Diagramm des geplanten Vorgehens von Simonyi]

Shane Clifford, ein Entwickler bei Intentional Software, erzählt diese Fabel.

Es war einmal ein Dorf mit vier Parks, gepflegt von vier wettbewerbsfähigen Nachbarschaftsvereinen. Der erste Verein beschloss, seinen Park mit einer neuen Sitzbank aufzupeppen. Es holte Vorschläge von drei der weltweit führenden Bankhersteller ein. Keiner der Entwürfe gewann die Mehrheit der Stimmen der Nachbarn, sodass der Verband den beliebtesten Entwurf wählte. Der Prozess war demokratisch – aber am Ende waren die meisten mit der neuen Bank unzufrieden.

Der zweite Verband entschied sich für eine eigene Bank, die aber allen gefiel. Es fand einen Hersteller, der maßgeschneiderte Bänke aus Mix-and-Match-Teilen baute. Aber der Holzsitz, den die Mitglieder mochten, hatte nicht die richtige Länge und die dekorative Rückenlehne passte nicht zu den grünen Beinen, die ihnen gefallen haben. Also gingen sie Kompromisse bei Teilen ein, die zusammenarbeiteten. Die Nachbarn waren stolz auf die fertige Bank, aber oft saß niemand darauf.

Die Mitglieder des dritten Vereins sahen, wie viel Geld die ersten beiden ausgegeben hatten und entschieden, dass sie es besser machen könnten. Die Handwerker der Gruppe fragten alle nach Vorschlägen und bauten am Ende eine schlichte, elegante Bank, die nach Meinung aller die schönste im Dorf sei. Leider wackelte es gefährlich.

Auch der vierte Verband wollte eine Bank, wollte aber die Fehler der anderen Gruppen nicht wiederholen. Die Nachbarn wandten sich an einen wenig bekannten Bankmacher, der für ein neues Bankbauerlebnis warb. Der Bankmacher kam mit einem Pritschenwagen an, der mit seltsam aussehenden Maschinen beladen war. Er begann Fragen zu stellen wie Was ist das wichtigste Merkmal dieser Bank? Was ist das zweitwichtigste Feature? Welche Materialien mögen Sie? Was ist deine Lieblingsform für die Füße der Bank?

Nach jeder Antwort drehte der Bankbauer an seinen Maschinen ein paar Knöpfe und ein neues Bild der laufenden Bank erschien auf einem großen Bildschirm. Manchmal stimmte das Bild nicht ganz, sodass die Nachbarn zurücktraten und die Fragen anders beantworteten. Nach 50 Fragen drückte der Bankmacher einen großen Knopf. Die Maschinen summten eine Weile, dann spuckten sie eine wunderschöne Bank aus, die zum letzten Bild auf dem Bildschirm passte. Alle waren froh, einen Beitrag geleistet zu haben, und viele Menschen saßen jeden Tag auf der Bank.

Um eine Bank zu bekommen, die alle glücklich macht, müssen Sie eine automatische Bankbaumaschine bauen; den Klienten helfen, ihre genauen Hoffnungen für ihre Bank zu definieren; Übersetzen Sie diese Hoffnungen in Anweisungen, die die Tischmaschine versteht; und drücken Sie dann die Make-Taste. Kunden erhalten eine genaue Kontrolle über das Ergebnis, und Tischbauer, die von den sich wiederholenden und mechanischen Teilen des Tischbaus befreit sind, können mehr Zeit damit verbringen, ihre Fähigkeiten einzusetzen, um die Wünsche ihrer Kunden in die Maschine einzubringen.

Ersetzen Sie Software für Bänke, sagt Clifford, und Sie werden absichtliches Programmieren verstehen – so genannt, weil Programmierer sich darauf konzentrieren, wie ihre Kunden ein Programm funktionieren wollen, und nicht auf den Durcheinander von Code, der für die Implementierung dieser Absichten erforderlich ist.

Absichtliche Programmierung ähnelt im Konzept den Textverarbeitungsprogrammen, die man sieht, was man bekommt, die Charles Simonyi, Cliffords Chef, entwickelt hat. Mit Wysiwyg-Texteditoren können Computerbenutzer das Erscheinungsbild eines Dokuments auf dem Bildschirm manipulieren, ohne sie dazu zu zwingen, den zugrunde liegenden Code zu beherrschen. In ähnlicher Weise ermutigt absichtliche Programmierung Computerbenutzer, ihre Bedürfnisse in ihrer eigenen vertrauten Sprache auszudrücken, und zeigt ihnen dann verständliche Ansichten oder Projektionen des entstehenden Designs, bevor der ausführbare Code zusammengestellt wird. Es ist nicht die einzige Programmierphilosophie, die auf solchen grafischen Darstellungen beruht; die Mitte der 1990er Jahre bei Rational Software (jetzt Teil von IBM) entwickelte Unified Modeling Language (UML) verwendet ebenfalls grafische Diagramme, um die Funktion, Struktur und das Verhalten eines Programms darzustellen. Aber UML-Diagramme können nicht in fertige Software umgewandelt werden, was Simonyis Traum von bewusster Programmierung ist.

Wie will Intentional Software diesen Traum verwirklichen? Setzen wir Simonyis Plan in ein eigenes Diagramm (hier klicken). Der Softwareentwicklungsprozess beginnt natürlich beim Kunden: jeder Organisation mit einer informationsintensiven Aufgabe, die automatisiert werden muss. Simonyi nennt die Mitarbeiter dieser Organisationen Domänenexperten; sie, nicht die Programmierer, wissen, was das Programm tun soll.

Mit Hilfe der Programmierer listen die Domänenexperten alle Konzepte und Definitionen auf, die die Software umfassen muss. Alle diese Definitionen gehen in eine Datenbank ein, die Simonyi das Domänenschema nennt.

Wie der Tischbauer, der seine Knöpfe dreht, integrieren die Programmierer dann die Definitionen im Domänenschema in den Domänencode – eine High-Level-Darstellung der Funktionen der Software, ausgedrückt in einer domänenspezifischen Sprache oder DSL, die an die Bedürfnisse angepasst werden kann Branche in Frage. Aber während DSLs variieren können, wird jede Aktion, die die Software ausführen muss, in einem einheitlichen Format gespeichert, einem beabsichtigten Baum. Intentionale Bäume haben den Vorteil, dass sie optisch einfach, aber logisch umfassend sind, dh sie können nach Belieben manipuliert, überarbeitet und projiziert oder neu gestaltet werden.

ein anderer Planet in unserem Sonnensystem

Zum Beispiel die Berechnung, die durch die einfache Programmanweisung dargestellt wird

Rückgabe a = b / (c + 1) ;

wird durch den folgenden intentionalen Baum dargestellt:

Zurückkehren
(

Zuordnen
(

zu,
Abteilung
(

B,
Mehr
(

C,
eins

)

)

)

)

Einmal in Baumform kodiert, kann die Berechnung auf viele andere Weisen projiziert werden, die Domänenexperten vielleicht vertrauter sind, wie z

B
Rückgabe a = ——- ;
c + 1

Als erste konkrete Aufgabe arbeiten Simonyi und seine Kollegen von Intentional Software daran, ein spezielles Tool, die Domain Workbench, zu bauen, die diese Projektionen verwalten soll. Sowohl die Domänenexperten als auch die Programmierer verwenden die Domänen-Workbench, um die Projektionen zu bearbeiten und zu überarbeiten, bis sie richtig aussehen. Danach wird der Domänencode in einen Generator eingespeist – das Äquivalent zu den Maschinen des Bankherstellers –, der Zielcode in einer Sprache wie C++ oder Java ausgibt, die andere Computer verstehen, kompilieren und ausführen können.

Sobald der Zielcode generiert wurde, kann er nicht wieder in Domänencode umgewandelt werden. Insofern ist der Generator wie ein Verschlüsselungsprogramm, das Klartext irreversibel in Chiffretext umwandelt.

Allerdings – und das ist vielleicht der größte Vorteil der absichtlichen Programmierung – ist es einfach, alten Zielcode zu verschrotten und von Grund auf verbesserten Code zu generieren. Überarbeiten Sie einfach den Domänencode mit dem Wysiwyg-Editor der Domänen-Workbench und führen Sie ihn erneut durch den Generator. Bei den meisten älteren Ansätzen kann selbst die kleinste Änderung der ursprünglichen Annahmen erfordern, dass Programmierer Millionen von Codezeilen durchsuchen und jede Instanz eines Konzepts, einer Definition oder Berechnung von Hand aktualisieren.

Der Generator bleibt die größte Blackbox im Prozess von Intentional Software. In technischen Veröffentlichungen wird das Unternehmen über diese mysteriöse Komponente nur sagen, dass der Prototyp in der Programmiersprache C# von Microsoft geschrieben ist und über eine Anwendungsprogrammierschnittstelle auf das Domänenschema und den Domänencode zugreift, eine Möglichkeit für zwei Programme, miteinander zu kommunizieren. das ist in die Domänen-Workbench integriert. Das Schreiben des Generators selbst oder die Anpassung an eine bestimmte Branche oder DSL wird jedoch einen großen Teil der Kosten eines absichtlichen Programmierprojekts ausmachen.

Wysiwyg hat Millionen weiterer Benutzer ermöglicht, großartig aussehende Dokumente zu erstellen, schreibt Simonyi im Blog des Unternehmens. Es ist an der Zeit, dasselbe für Softwarebenutzer zu tun.

Von Wade Roush

Das Gesetz der undichten Abstraktionen
Auszug aus Träumen im Code: Zwei Dutzend Programmierer, drei Jahre, 4.732 Fehler und eine Suche nach transzendenter Software , von Scott Rosenberg, wird veröffentlicht von
Crown Books im Januar 2007.

Wie wir gesehen haben, besteht Software aus Schichten, wobei jede Schicht Informationen und Prozesse für die darüber und darunter liegenden Schichten übersetzt. Ganz unten in diesem Schichtenstapel sitzt die Maschine mit ihren rein binären Einsen und Nullen. An der Spitze stehen die Menschen, die diese Schichten aufbauen und nutzen. Simonyis Intentional Software schlägt im Kern einfach eine weitere Ebene zwischen der Maschine und uns vor.

Die Schichten der Software sind die Essenz und treiben den Fortschritt auf diesem Gebiet voran, aber sie haben eine anhaltende Schwäche. Sie lecken. Benutzer vieler Versionen von Microsoft Windows sind beispielsweise mit dem Phänomen des Blue Screen of Death müde vertraut. Sie arbeiten in einer Softwareanwendung wie einem Webbrowser oder Microsoft Word, und plötzlich wird Ihr Bildschirm wie aus dem Nichts blau und Sie sehen weißen Text darauf, der in etwa so lautet:

Eine schwerwiegende Ausnahme 0E ist aufgetreten um
0167: BFF9DFFF.

Die aktuelle Anwendung wird beendet.

Angesichts des monochromen Aussehens des Bildschirms und der blockhaften Schrift können erfahrene Benutzer spüren, dass sie in der Computerzeit zurückgeworfen wurden. Einige verstehen vielleicht sogar, dass der alarmierende Hinweis der Nachricht auf eine schwerwiegende Ausnahme bedeutet, dass das Programm auf einen Fehler gestoßen ist, den es nicht beheben kann, und dass er abgestürzt ist, oder dass die kryptischen Hexadezimalzahlen (Basis 16) die genaue Stelle im Computerspeicher beschreiben, an der der Absturz aufgetreten ist fand statt. Keine der Informationen ist für die meisten Benutzer von Wert. Die komfortable, vertraute Benutzeroberfläche der verwendeten Anwendung ist verschwunden; eine tiefere Abstraktionsschicht – in diesem Fall die Windows-Shell oder ein untergeordnetes Steuerungsprogramm – ist wie eine schräge Schicht Grundgestein ausgebrochen, die durch neuere geologische Schichten in das Sonnenlicht ragt.

(So ​​verblüffend der Blue Screen of Death auch ist, er stellte tatsächlich einen großen Fortschritt gegenüber früheren Versionen von Windows dar, da er es dem Benutzer manchmal ermöglicht, das störende Programm zu beenden und weiterzuarbeiten. Vor dem Bluescreen stürzte fast immer ein Windows-Programm ab. nahm die gesamte Maschine und alle ihre Programme herunter.)

In einem Essay mit dem Titel The Law of Leaky Abstractions schrieb Joel Spolsky: Alle nicht-trivialen Abstraktionen sind bis zu einem gewissen Grad undicht. Abstraktionen scheitern. Manchmal ein bisschen, manchmal viel. Es gibt Leckagen. Dinge laufen falsch. Für Benutzer bedeutet dies, dass sich Ihr Computer manchmal auf bizarre und verblüffende Weise verhält und manchmal werden Sie es wollen, wie Mitch Kapor in seinem . sagte Manifest für Softwaredesign , wirf es aus dem Fenster. Für Programmierer bedeutet dies, dass neue Tools und Ideen, die ein bisschen Rechenkomplexität auf niedriger Ebene bündeln und in eine neue, leichter zu manipulierende Abstraktion packen, großartig sind, aber nur bis sie kaputt gehen. Dann fließt all diese verborgene Komplexität in ihre Arbeit zurück. Theoretisch erlaubt die praktische neue obere Schicht Programmierern, das Chaos darunter zu vergessen; In der Praxis muss der Programmierer dieses Durcheinander immer noch verstehen, da er schließlich darin landen wird. Spolsky schrieb:

Abstraktionen vereinfachen unser Leben nicht wirklich so sehr, wie es beabsichtigt war. … Das Gesetz der undichten Abstraktionen bedeutet, dass, wenn jemand ein witziges neues Code-Generierungs-Tool entwickelt, das uns alle noch so effizient machen soll, viele Leute sagen hören: Lernen Sie zuerst, wie man es manuell macht Verwenden Sie das Wizzy-Tool, um Zeit zu sparen. Codegenerierungstools, die vorgeben, etwas zu abstrahieren, wie alle Abstraktionen, Lecks, und der einzige Weg, um kompetent mit den Lecks umzugehen, besteht darin, zu lernen, wie die Abstraktionen funktionieren und was sie abstrahieren. Die Abstraktionen sparen uns also Zeit beim Arbeiten, aber sie sparen uns keine Zeit beim Lernen. … Und all dies bedeutet paradoxerweise, dass es immer schwieriger wird, ein kompetenter Programmierer zu werden, auch wenn wir immer höhere Programmierwerkzeuge mit immer besseren Abstraktionen haben.

Auch wenn die Abstraktionen, die wir im Laufe der Jahre geschaffen haben, es uns ermöglichen, mit neuen Komplexitätsordnungen in der Softwareentwicklung umzugehen, mit denen wir uns vor zehn oder fünfzehn Jahren nicht auseinandersetzen mussten, und obwohl uns diese Werkzeuge viel ermöglichen unglaublich schnell erledigter Arbeit, schrieb Spolsky, eines Tages müssen wir plötzlich ein Problem finden, bei dem die Abstraktion durchgesickert ist, und das dauert zwei Wochen.

Das Gesetz der undichten Abstraktionen erklärt, warum so viele Programmierer, mit denen ich gesprochen habe, skeptisch mit den Augen rollen, wenn sie Beschreibungen von Intentional Programming oder anderen ähnlichen Ideen zur Überwindung der Komplexität von Software hören. Es ist nicht so, dass sie es nicht begrüßen würden, einen weiteren Schritt auf der Abstraktionsleiter zu gehen; Aber sie befürchten, dass sie, egal wie hoch sie auf dieser Leiter klettern, immer mehr auf und ab laufen müssen, als ihnen lieb ist – und je höher sie wird, desto länger wird die Reise.

verbergen

Tatsächliche Technologien

Kategorie

Unkategorisiert

Technologie

Biotechnologie

Technologierichtlinie

Klimawandel

Mensch Und Technik

Silicon Valley

Computer

Mit News Magazine

Künstliche Intelligenz

Platz

Intelligente Städte

Blockchain

Reportage

Alumni-Profil

Alumni-Verbindung

Mit News Feature

1865

Meine Sicht

77 Mass Avenue

Treffen Sie Den Autor

Profile In Großzügigkeit

Auf Dem Campus Gesehen

Lerne Den Autor Kennen

Alumni-Briefe

Nicht Kategorisiert

77 Massenallee

Rechnen

Tech-Richtlinie

Lernen Sie Den Autor Kennen

Nachrichten

Wahl 2020

Mit Index

Unter Der Kuppel

Feuerwehrschlauch

Unendliche Geschichten

Pandemie-Technologieprojekt

Vom Präsidenten

Titelstory

Fotogallerie

Empfohlen