211service.com
Alles wat je kunt doen, kan ik doen Meta
Op 9 april zal een grondcontroller op een afgelegen lanceerplatform op de vlakten van Kazachstan zijn aftelling voltooien; een Sojoez-raket zal vuren; en Charles Simonyi – de voormalige hoofdarchitect van Microsoft, het beschermgenie achter de beroemdste applicaties, de uitvinder van de methode om code te schrijven die de programmeurs van het bedrijf al 25 jaar gebruiken, en nu de voorstander van een ambitieus project om software te herprogrammeren – zal beginnen zijn opstijging in de ruimte.
Charles Simonyi, president en CEO van Intentional Software.
Knus in een Russisch ruimtepak en voelend dat vier G's hem in een nauwsluitend gevormde stoelbekleding drukken, zal de 58-jarige miljardair de vijfde ruimtetoerist worden die het internationale ruimtestation bezoekt. De reis, die Simonyi ongeveer $ 20 miljoen kost, zal zijn droom vervullen om een nerd in de ruimte te worden (om één naam te lenen die hij koos voor de website die zijn buitenaardse avontuur documenteert: www.nerdinspace.com ). Het geeft hem ook de kans om onze planeet van bovenaf en daarbuiten te bekijken.
Dit is altijd de voorkeur van Simonyi geweest. In een carrière van vier decennia heeft hij elke keer dat hij geconfronteerd werd met een hardnekkig probleem in software of in het leven, geprobeerd het op te lossen door er buiten of erboven te gaan staan. Hij heeft zelfs een naam voor zijn favoriete gambiet: hij noemt het meta gaan. In zijn jeugd in het Hongarije van de jaren zestig leerde hij de basis van computers op een verouderd Sovjet-mainframe dat werd aangedreven door vacuümbuizen, en ontwikkelde hij vervolgens zijn eigen ontsnapping naar het Westen. In de jaren zeventig schreef Simonyi in het legendarische Palo Alto Research Center (PARC) van Xerox, als onderdeel van het team dat personal computing uitvond, de eerste moderne applicatie: een tekstverwerker die de complexe codes verbant en vervolgens gebruikt om tekst te taggen en een document weer te geven als het zou er op papier uitzien. Of het nu gaat om zijn proefschrift aan de Stanford University over een meta-programmeringsbenadering om de productiviteit van programmeurs te verhogen, zijn carrière bij Microsoft die legioenen softwareontwikkelaars organiseert en hen leert hoe ze hun code moeten structureren, of zijn geplande reis naar een baan om de aarde dit voorjaar, waarbij hij verder gaat dan de gevestigde manieren dingen doen is altijd Simonyi's methode geweest. Nu beraamt hij wat hij hoopt dat zijn meest gewelfde meta-move van allemaal zal zijn. Simonyi gelooft dat hij een groot aantal hardnekkige problemen kan oplossen die computers altijd hebben geplaagd door iedereen die ze gebruikt, en de programmeurs die ze programmeren, een hogere-orde weergave van software te bieden.
Bill Gates noemt Simonyi een van de grote programmeurs aller tijden. Inderdaad, Simonyi is misschien wel de meest succesvolle codeur ter wereld, gemeten in termen van financiële beloning en het aantal mensen dat zijn creaties gebruikt. (Andere beroemde programmeurs-miljardairs, zoals Larry Ellison en Bill Gates zelf, verdienden hun geld en namen naam op met het oprichten en beheren van technologische ondernemingen.) Simonyi kon er gemakkelijk voor kiezen om de rest van zijn leven filantropische ondernemingen te schenken, vliegtuigen te vliegen of te cruisen in zijn jacht. In plaats daarvan, zegt hij, programmeert hij waarschijnlijk moeilijker dan ooit tevoren. Hij is geobsedeerd door een project dat hij anderhalf decennium lang heeft nagestreefd en dat hem vier jaar geleden regelrecht uit de deuren van Microsoft heeft gedragen. Hij is trots op zijn vak. Maar hij wordt ook achtervolgd door de gedachte waar programmeurs mee te maken krijgen elke keer dat ze gaan coderen. Hij vraagt: Waarom is het zo moeilijk om goede software te maken?
Multimedia
Extra foto's van Simonyi
Napoleontische code
Onze beschaving draait op software, zegt Bjarne Stroustrup, de uitvinder van de programmeertaal C++ (zie Het probleem met programmeren ) . Maar de software zelf werkt niet erg goed. Overal waar je kijkt, is software boven budget, achter op schema, onveilig, onbetrouwbaar en moeilijk te gebruiken. Telkens wanneer een organisatie probeert een nieuw systeem in te voeren of een oud systeem te upgraden, neemt dit een enorm risico; tegenwoordig zijn grote IT-projecten technologische teerputten die instellingen immobiliseren. Studies melden regelmatig dat tweederde van dergelijke projecten te maken heeft met grote vertragingen, aanzienlijke kostenoverschrijdingen of beide. De Amerikaanse regering heeft het bijna onmogelijk gevonden om grootschalige softwaresystemen te introduceren of te upgraden: decennialange inspanningen van de Federal Aviation Administration en de FBI zijn in chaos ingestort. Bedrijven hebben het niet beter gedaan. Om een enkel voorbeeld te geven: de leidinggevenden van McDonald's droomden van een webgebaseerd beheersysteem dat ze Innovate noemden en dat de realtime stroom van hamburgers, friet en kipnuggets in al hun restaurants over de hele wereld zou volgen. Tegen de tijd dat ze het project opgaven en annuleerden, moesten ze 170 miljoen dollar van de geschatte totale kosten van 1 miljard dollar afschrijven.
Dergelijke mislukkingen tellen op. Volgens een studie van het National Institute of Standards and Technology uit 2002 kostten softwarefouten elk jaar $ 59,5 miljard. Maar de prijs van slechte software kan ook worden gemeten in menselijke ellende – en zelfs in verloren levens. Tijdens de Golfoorlog van 1991 vuurde een Patriot-raketbatterij niet op een inkomende Scud vanwege defecte software; de voltreffer op een kazerne doodde 28 Amerikaanse soldaten.
De afgelopen halve eeuw computergebruik heeft geweldige vooruitgang geboekt. Programmeurs hebben ponskaarten en teletypes verlaten. Ze hebben ons een computer op elke desktop gegeven, gereedschap om te werken, speelgoed om mee te spelen en een netwerk dat huizen en bedrijven met elkaar verbindt om een krioelende wereldwijde pool van informatie en entertainment te vormen. Deze vooruitgang is aangewakkerd door de exponentiële curve van de wet van Moore, de voorspelling van Intel-oprichter Gordon Moore dat het vermogen van microchips elke één tot twee jaar zou verdubbelen (of hun kosten zouden halveren). Maar hoewel de wet van Moore de nieuwe computers elk jaar sneller en goedkoper heeft gemaakt, zijn de flexibiliteit en bruikbaarheid van onze computersystemen beperkt door de langzamere, ongelijkmatige evolutie van software. Een formulering van dit probleem staat bekend als de wet van Wirth, naar programmeerexpert Niklaus Wirth: Software wordt sneller langzamer dan hardware sneller.
Simonyi deelt veel van de algemene ontevredenheid over software. Software zoals we die kennen is de bottleneck op de digitale hoorn des overvloeds, zegt hij. Het kost enorm veel middelen in talent en tijd. Het is teleurstellend en moeilijk te veranderen. Het blokkeert innovatie in veel organisaties.
Het is de ambitie van Simonyi om dat knelpunt in de software ongedaan te maken, kenmerkend door meta te gaan doen. Hij heeft een aanpak ontwikkeld die hij opzettelijk programmeren (of, meer recentelijk, opzettelijke software) noemt, waarvan hij hoopt dat het programmeren omver zal werpen. Als Simonyi zijn zin krijgt, zullen programmeurs stoppen met proberen om aan de behoeften van hun klanten te voldoen. In plaats daarvan zullen ze voor elk probleem dat ze moeten aanpakken, of het nu gaat om het bijhouden van voorraden of raketgeleiding, generieke tools creëren die de computergebruikers zelf kunnen aanpassen om de toekomstige evolutie van de software te begeleiden.
Op een grijze middag afgelopen oktober zat ik met Simonyi in Bellevue, WA, voor twee aangrenzende schermen in zijn kantoor bij Intentional Software, het bedrijf dat hij oprichtte nadat hij in 2002 Microsoft verliet om zijn grote idee te ontwikkelen en te commercialiseren. Simonyi racete me door een presentatie die hij aan het voorbereiden was voor een aanstaande conferentie; hij gebruikte Microsoft Office PowerPoint-dia's om zijn visie te schetsen voor de voorgestelde grote sprong voorwaarts in programmeren. Hij was bezig met het verplaatsen van een dia toen de applicatie net niet meer reageerde.
In de hoek van het linkerscherm dook een verblinde paperclip op: de alom verguisde Office Assistant die Microsoft in 1997 introduceerde. Simonyi probeerde het gekke gefladder van de tekenfilmassistent te negeren, maar hij werd gedwarsboomd. Niets werkt, zuchtte hij. Dat komt omdat Clippy me wat hulp geeft.
Ik was verbaasd. Je bedoelt dat je Clippy niet hebt uitgeschakeld? Lang geleden had ik door de menu's van Office gejaagd en gecontroleerd welk vakje nodig was om de vervelende antropomorf voor eens en altijd te smoren.
Ik weet niet hoe, gaf Simonyi toe, met een lachje dat leek te zeggen: Ja, ik weet het, is het niet ironisch?
Het was. Simonyi leidde jarenlang de applicatieteams van Microsoft, de ontwikkelaars van Word en Excel, wiens producten elke dag door tientallen miljoenen mensen worden gebruikt. Hij wordt algemeen beschouwd als de vader van Microsoft Word. (Ik gebruik natuurlijk Word om deze zinnen te schrijven.) Zou Charles Simonyi zijn gelijke in Clippy hebben ontmoet?
Simonyi staarde naar zijn tegenstander, alsof hij verwikkeld was in telepathische gevechten. Toen wendde hij zich tot mij, zijn blauwe ogen glinsterden. Ik heb een helper nodig: een Super-Clippy om me te laten zien waar ik hem kan uitschakelen! Simonyi hunkerde naar een meta-Clippy.
In 2004 stelde Simonyi zijn eigen wet voor: alles wat gedaan kan worden, kan 'meta' worden gedaan. doen, ik kan meta doen! Maar zoals veel wonderkinderen die het goed hebben gedaan en goed oud zijn geworden, heeft Simonyi geleerd zijn eigenwijsheid te verminderen met een vleugje nederigheid en gratie. Tien jaar geleden beschreef hij zichzelf als een ruige kerel met een buitenlands accent. Hij geeft de voorkeur aan zwarte coltruien en blazers met dubbele rij knopen. Met zijn rechtopstaande houding en vierkant gezicht, een bos donker haar naar voren gekamd over zijn voorhoofd, wordt vaak gezegd dat hij op een Napoleon met grotere botten lijkt.
Opzettelijke software is een groots plan in een veld waar grote plannen zelden hebben gewerkt. Elke eerdere innovatie die werd geïntroduceerd als een complete oplossing voor de problemen van software, heeft uiteindelijk niet meer dan bescheiden, incrementele verbeteringen opgeleverd. Maar Simonyi bruist van het zelfvertrouwen van een zelfgemaakte immigrant die altijd een stevige greep op zijn eigen laarzen heeft gehad. Op een foto die boven zijn bureau hangt, staat hij in het Witte Huis onder een portret van Ronald Reagan. Zijn brede grijns weerspiegelt die van de president. Het bijschrift luidt De twee optimisten.
De kantoren van Simonyi's nieuwe bedrijf bezetten een suite in een strakke glazen wolkenkrabber, en als je tegen het raam leunt en naar beneden kijkt, kun je het dak zien van het gedrongen, onopvallende witte gebouw waarin in 1981 zijn eerste kantoor bij Microsoft was gevestigd. ( Het is nu een bank.) Sindsdien is Microsoft onherkenbaar gegroeid. De software-industrie heeft de wereld veranderd. Dus waarom zou Simonyi al zijn regels willen herschrijven? Het probleem is zo groot dat het onderdeel lijkt te zijn van de vaste orde der dingen. Simonyi's voorgestelde oplossing zou tientallen jaren in beslag kunnen nemen, en zijn critici zijn intens sceptisch. Niemand vraagt hem om de bekende routines van programmeren achter zich te laten en op weg te gaan naar een nieuwe wereld. Maar dergelijke migraties hebben in het verleden zijn vruchten afgeworpen.
De taal van de machine
Simonyi werd in 1948 in Boedapest geboren. Als zoon van een natuurkundeprofessor werd hij op 15-jarige leeftijd verliefd op zijn eerste computer: een gigantische Russische Oeral II in het Centraal Bureau voor de Statistiek van Hongarije. In de jaren zestig zou de Oeral, die zijn instructies ontving via kassa-achtige toetsen en een kamer vol vacuümbuizen had om berekeningen uit te voeren, al een overblijfsel zijn ergens anders in de wereld. Maar de communistische leiders van Hongarije probeerden de Sovjet-afdrijving te gebruiken om de trein- en vrachtwagenschema's te optimaliseren. De Ural was niet opgewassen tegen de taak: er was geen manier om realtime gegevens over zendingen in te voeren. Het was totaal hopeloos, herinnert Simonyi zich. Het had heel gemakkelijk kunnen worden gedaan door vraag en aanbod. Helaas was dat politiek incorrect.
Maar het kon Simonyi niet schelen. Ik hield van die computer, zegt hij, ook al was hij nutteloos. Als kind had hij een Erector Set-auto gebouwd met een vierversnellingsbak - niet zozeer omdat hij ermee wilde spelen, maar gewoon om te begrijpen hoe het werkte. Een voormalige leerling van zijn vader vond voor Simonyi een baan als nachtzuster van de Oeral. Omdat de machine elke keer dat hij aan en uit werd gezet een buis uitblies, liet het Bureau voor de Statistiek hem liever de hele nacht draaien. Dus, van zonsondergang tot zonsopgang, was het mainframe allemaal van Simonyi; hij had een personal computer voordat zulke dingen bestonden. Hij leerde het te programmeren door slimme maar nutteloze routines te schrijven om magische vierkanten te genereren - numerieke arrays waarin de sommen van de rijen, kolommen en diagonalen allemaal overeenkomen.
Programmeurs elders in de wereld hadden al een Babel van programmeertalen uitgevonden - Fortran, Cobol, Lisp (een legendarische taal: zie Ancient Text, p. 20), enzovoort - om hun werk te vergemakkelijken, dat toen net als nu bestond uit nauwgezet schrijven uitgebreide sets instructies voor computers om uit te voeren. In die talen namen de instructies de vorm aan van tekstregels die op toetsenborden werden ingevoerd en vaak op ponskaarten werden opgeslagen. Deze broncode werd vervolgens gecompileerd of vertaald in machinecode – de een s en 0 dat een digitale computer zou kunnen begrijpen. De methode blijft vandaag grotendeels ongewijzigd, zelfs als de meeste programmeurs nu programmeertools gebruiken die op gewone pc's draaien. Maar op de Oeral leerde Simonyi programmeren op een meer primitief niveau, waarbij hij moeizaam de opcodes van machinetaal intoetste en, instructie voor instructie, de reeksen van geheugenhaalt, toevoegingen, geheugenopslag en sprongen specificeerde die de computerprocessor moest volgen om zelfs de meest triviale operatie uit te voeren. Het was (zoals Simonyi de auteur Steve Lohr vertelde in het boek van 2001) Ga naar ) Programmeren uit het stenen tijdperk. Simonyi herinnert zich de codes nog. Tweeëntwintig is JUMP, zegt hij vandaag. Het is in mijn ROM gebrand.
Hongarije, dat in de jaren zestig nog terugdeinsde voor de Sovjetonderdrukking van de opstand van 1956, was geen plaats voor een ambitieuze jongeman met een voorliefde voor probleemoplossing. Op 17-jarige leeftijd liep Simonyi stage bij een Deens computerbedrijf door enkele van zijn programmeurs voorbeelden te laten zien van zijn handgecodeerde Ural-programma's. De Hongaarse autoriteiten verwachtten dat Simonyi zou terugkeren; hij had al een felbegeerde universiteitsplek gewonnen. In plaats daarvan vluchtte hij, op aanmoediging van zijn vader, naar de Verenigde Staten.
Een aanbevelingsbrief van de Deense programmeerexpert Peter Naur hielp hem toegang te krijgen tot de University of California, Berkeley. Hij betaalde de rekeningen met een baan bij Berkeley's computercentrum, waar hij de aandacht trok van een faculteitslid genaamd Butler Lampson. Lampson was een van de leiders van het Project Genie van het Amerikaanse Defense Advanced Research Projects Agency - een experiment in timesharing-computersystemen, waarbij meerdere gebruikers aan terminals de hersentijd van een enkele computer konden delen. Toen de makers van Project Genie een bedrijf startten, Berkeley Computer Corporation (BCC), dat tot doel had een machine te bouwen die hun werk zou commercialiseren, nam Lampson Simonyi aan.
Bij BCC debugde Simonyi het wankele prototype van het bedrijf de hele nacht, in samenwerking met systeemontwerper Chuck Thacker. Op een avond verscheen Simonyi in een doorzichtige zwarte outfit - een soort hippie-ding uit een van de winkels aan Telegraph Avenue, zegt hij. Tegenwoordig kan hij zich niet precies herinneren waarom - misschien van een feestje? Het debuggen ging die avond bijzonder goed en de outfit werd een geluksbrenger - Simonyi's debugging-pak.
BCC ging al na een paar jaar failliet, maar Lampson, Thacker en een groot deel van het BCC-team migreerden naar Xerox PARC. Simonyi - toen gewoon een willekeurige Hongaarse student zonder groene kaart, zoals hij nu zegt - kwam in 1972 bij hen werken, werkte bij Xerox terwijl hij tegelijkertijd promoveerde op Stanford. Bob Taylor, die tijdens een deel van dat legendarische tijdperk toezicht hield op PARC's Computer Science Lab, zegt dat Simonyi's creativiteit zelfs in de beroemde menigte van het lab opviel: hij kon zich manieren voorstellen om code en ideeën uit te drukken die hem van de hitlijsten afstootten.
Het was een onstuimige tijd. Het team van visionaire ingenieurs creëerde een reeks innovaties die de volgende kwart eeuw van het pc-tijdperk vorm zouden geven: de grafische gebruikersinterface, netwerken (Ethernet), de laserprinter, objectgeoriënteerd programmeren (Smalltalk), draagbare computers (de Dynabook), en meer. Deze doorbraken kwamen allemaal samen op een prototypische personal computer genaamd de Alto.
De Alto was een geweldige uitvinding, maar het was niet duidelijk wat je ermee kon doen totdat Simonyi en zijn collega's de bekendste toepassing ervan maakten: een tekstverwerker genaamd Bravo, waarvan het type op het scherm overeenkwam met wat het systeem zou produceren naar de nieuwe laserprinter. Bestaande tekstverwerkers hadden uitgebreide codesystemen voor het opmaken van tekst op het scherm (iedereen die WordPerfect in de jaren tachtig op een pc gebruikte, herinnert zich de ingebedde codes); Met Bravo kunt u de codes vergeten, het ontwerp van een document direct manipuleren en onmiddellijk getuige zijn van de wijzigingen. Een directeur van Citibank die op bezoek was, bekeek een demo en citeerde een kenmerkende regel van het brutale personage Geraldine van komiek Flip Wilson: What you see is what you get! De naam (gereduceerd tot het acroniem Wysiwyg en uitgesproken als wizzywig ) vast. Plotseling had Bravo gebruikers: familieleden en vrienden van PARC-onderzoekers begonnen het te gebruiken om schoolnieuwsbrieven af te drukken en academische papers op te maken. De vrouw van Lampson drukte haar proefschrift af met behulp van het systeem, en toen het tijd was voor Simonyi om zijn proefschrift af te drukken, deed hij hetzelfde.
Niveaus van abstractie
Wysiwyg is een voorbeeld van een abstractielaag: een tool op een hoger niveau waarmee computergebruikers een lagere complexiteit kunnen negeren. Programmeurs gebruiken de hele tijd abstracties. De tekstcode die in een programmeertaal is geschreven, is een abstractie van de machinecode die een computer daadwerkelijk begrijpt. Een webdomeinnaam is een abstractie van het numerieke Internet Protocol-adres van een server.
Maar de meeste abstractielagen in computersystemen zijn minder zichtbaar en geheimzinniger dan Wysiwyg. Sinds programmeurs zijn gestopt met het onthouden van de opcodes die Simonyi in zijn jeugd gebruikte, hebben ze nieuwe abstracties op oudere abstracties gelegd. Elke generatie programmeurs gebruikt de programmeertalen en tools van zijn tijd om de programma's van de volgende generatie te bouwen. Lagen van abstractie hebben zich als geologische lagen opgehoopt. Berichten vliegen constant omhoog vanuit de binaire basis van uw machine en weer terug, waardoor een muisklik zijn functie kan vervullen. Uw muisklik activeert een code in het besturingssysteem, die een bericht naar het tekstverwerkingsprogramma stuurt, dat het besturingssysteem instrueert om uw bestand op een harde schijf op te slaan. Maar dat ogenschijnlijk eenvoudige proces is alleen mogelijk dankzij vele, vele abstractielagen.
De geschiedenis van software is de geschiedenis van deze lagen, elk van hen tilt programmeurs verder van het binaire bestand, waardoor ze beter in staat zijn computers over te halen om nuttige taken uit te voeren. Geleidelijk kregen programmeurs meer macht. Maar ze pakten ook steeds ambitieuzere problemen aan. Programma's werden enorm groot en programmeurs raakten verdwaald in de warboel van wat ze spaghetticode noemden, die onmogelijk te ontrafelen en te repareren bleek te zijn. Zo werden grote softwareprojecten heldendichten van frustratie en vertraging. Programmamanagers kregen te maken met zakelijke problemen zoals: Hoe plan je een project realistisch? Hoe verbeter je de individuele productiviteit? Hoe coördineer je complexe werkzaamheden binnen een groot team? Elk van deze vragen bleek verrassend moeilijk te beantwoorden.
De moeilijkheid om het werk van een team te coördineren, inspireerde de beroemdste uitspraak van software-engineering, bekend als de wet van Brooks: het toevoegen van mankracht aan een laat softwareproject maakt het later. Frederick P. Brooks Jr. kwam tot deze sombere conclusie nadat hij in de jaren zestig leiding had gegeven aan IBM's moeizame poging om software te schrijven voor zijn 360 mainframes. In zijn boek uit 1975 De mythische man-maand , merkte Brooks op dat het werk bij grotere teams langzamer verloopt vanwege de coördinatiekosten - de tijd die programmeurs verliezen om elkaar op de hoogte te houden van hun werk.
Dit was het decor voor Simonyi's proefschrift uit 1977, Meta-Programming: A Software Production Method. Simonyi stelde een nieuwe benadering voor om de productiviteit te optimaliseren, waarbij één hoofdprogrammeur, of meta-programmeur, een product ontwierp en al zijn termen definieerde, en vervolgens een blauwdruk overhandigde aan technici, programmeurs van werkbijen die de implementatie zouden doen. Simonyi probeerde aan de wet van Brooks te ontsnappen door de technici te verbieden met elkaar te praten: alle communicatie moest via de meta-programmeur verlopen. Voor zijn proefschrift testte hij het idee met twee groepen op twee projecten, A en B. Zijn despotische benadering van programmeren sloeg nooit aan, maar dat stoorde hem nauwelijks. Simonyi's voornaamste doel bij het onderzoeken van zijn proefschrift was niet om de waarde van zijn ideeën te bewijzen, maar om Bravo, de nieuwe Wysiwyg-tekstverwerker, sneller te laten schrijven. Hij kon de PARC-kopers niet overtuigen om extra programmeurs in te huren, dus gebruikte hij zijn proefschrift als een uitvlucht om hulp in te schakelen. Bravo zelf was project B.
Naarmate de jaren zeventig vorderden, werd Simonyi ongeduldig met het onvermogen van Xerox om het baanbrekende onderzoek van PARC om te zetten in succesvolle producten. Op een dag liet een vriend hem VisiCalc zien, het nieuwe spreadsheetprogramma voor de Apple II. Het ontroerde Simonyi. Hier was nog een applicatie, zoals Bravo, die het leven van mensen zou kunnen veranderen, maar in tegenstelling tot Bravo draaide het op een massamarktcomputer die mensen zich konden veroorloven om te kopen. PARC's werk, realiseerde hij zich, zou nooit het daglicht zien. Hij vroeg zijn voormalige PARC-collega Bob Metcalfe, die het lab in 1979 had verlaten om 3Com te beginnen, om potentiële bazen in de jonge pc-industrie aan te bevelen. Bovenaan de lijst stond Bill Gates.
In 1981 verhuisde Simonyi naar Seattle om de groep voor nieuwe toepassingen bij Microsoft op te richten, dat tot dan toe programmeertalen en besturingssystemen had verkocht. Hij was 33, maar dat maakte hem een volwassene onder de jongetjes van Microsoft (Gates was toen 26 jaar oud, Steve Ballmer 25).
Gedurende al de jaren dat Simonyi toezicht hield op de producten die uiteindelijk samensmolten tot de programmasuite die bekend staat als Microsoft Office, bleef hij zoeken naar nieuwe efficiëntie in nieuwe soorten programmeerabstracties. Met name heeft hij generaties Microsoft-programmeurs opgeleid in het bijhouden van de talloze variabelenamen die in grote programma's worden gebruikt. Bij computerprogrammering vertegenwoordigen variabelen informatie die kan veranderen als een programma wordt uitgevoerd. Het winkelwagenprogramma van een online winkel heeft bijvoorbeeld variabelen die het aantal items van elk type vertegenwoordigen dat moet worden gekocht, de prijs van elk item en de verzendkosten en belastingen. Met behulp van die variabelen kan een programmeur een eenvoudige regel code schrijven die de hoeveelheid vermenigvuldigt met de prijs, verzendkosten en belastingen toevoegt en de totale kosten berekent - die de waarde van weer een andere variabele worden.
Een groot programma kan duizenden verschillende variabelen hebben die een programmeerteam recht moet houden. Het zorgvuldig benoemen ervan wordt cruciaal. Tegenwoordig bevat de meeste code variabelenamen die zijn ontworpen om betekenis over te brengen aan de programmeurs die het zullen lezen, namen zoals NumberOfItems of ShoppingCartTotal. In Simonyi's naamgevingsschema, dat hij jaren eerder voor eigen gebruik had uitgevonden, wordt elke variabelenaam geleverd met een voorvoegsel dat u nuttige informatie erover vertelt, zoals het type (een geheel getal, bijvoorbeeld een decimale breuk of een reeks letters). Sommige systemen beperken de lengte van variabelenamen tot acht tekens; Simonyi liet de klinkers gewoon weg.
De resulterende code was compact en moeilijk te lezen. Simonyi's systeem werd bekend als Hongaarse notatie, zowel als eerbetoon aan de geboorteplaats van de maker, en omdat het programma's eruit liet zien alsof ze in een ondoorgrondelijke vreemde taal waren geschreven, volgens programmeerpionier Andy Hertzfeld. Hongaars wordt alom vervloekt door zijn tegenstanders. De Canadese Java-expert Roedy Green heeft het gekscherend het tactische kernwapen van broncode-verduisteringstechnieken genoemd. Mozilla-programmeur Alec Flett schreef deze parodie:
prepBut nI vrbLike adjHongaars! qWat is kunstHet adjBig nProbleem?
Hertzfeld, die schreef over een ontmoeting bij Apple met Hongaarse code geschreven door een collega die met Simonyi bij PARC had gewerkt, zei dat de namen eruitzagen alsof ze waren gekozen door Supermans vijand uit de 5e dimensie, de heer Mxyzptlk.
Maar hoewel critici vinden dat Hongaars code onleesbaar maakt, blijft Simonyi er trots op en gebruikt het tot op de dag van vandaag.
Meta-euforie
Begin jaren negentig had het succes van Microsoft Simonyi's fortuin gemaakt. (Voor meerdere jaren, Forbes heeft het geschat op $ 1 miljard.) Maar hij voelde nog steeds het slepen van onafgemaakte zaken. De verwarring van Software had de oprichting van Office zenuwslopend gemaakt voor Microsoft. Maar nu, met computers die krachtiger zijn dan de Alto op elk bureau en het internet ze met elkaar verbindt, was de softwarecrisis de crisis van iedereen. Simonyi begon te denken dat het tijd was om weer meta te gaan doen.
Charles heeft altijd geprobeerd zijn systemen te bouwen op een manier die het abstractieniveau verhoogt, zodat je de complexiteit van het systeem kunt beheersen. Omdat complexiteit de dood is, zegt Chuck Thacker, Simonyi's oude collega van BCC en PARC, die bij Microsoft een onderzoeksproject over computerarchitectuur leidt. En helaas leidt het bieden van de faciliteiten die mensen eigenlijk willen tegenwoordig tot een complex systeem. We hangen nu met onze vingertoppen vast.
Simonyi verhuisde naar een functie bij Microsoft Research en begon het concept van intentioneel programmeren, of kortweg IP, te definiëren. Opzettelijk programmeren zou een geheel nieuwe laag van abstractie toevoegen aan de praktijk van het schrijven van software. Het zou programmeurs in staat stellen hun bedoelingen te uiten zonder weg te zinken in het slijk van zogenaamde implementatiedetails die hen altijd dreigden te verzwelgen. Net als de meta-programmeurs van Simonyi's proefschrift, die instructies doorgaven aan codeurs van werkbijen, zou de opzettelijke programmeur het scut-werk overdragen, maar niet aan een junior-collega. In plaats daarvan vroeg opzettelijk programmeren om een soort codefabriek, een generator genaamd, een programma dat een reeks relatief hoogwaardige opdrachten opneemt en meer gedetailleerde werkcode uitspuugt. Het doel was niet zozeer om het programmeerwerk te vergemakkelijken, maar om programmeurs hun hersens te laten zuiveren van trivialiteiten, zodat ze echt creatief konden zijn.
Vanaf zijn programmeerinitiatie als tiener die opcodes in de Oeral ponsde, had Simonyi de ladder van abstractie beklommen. Maar hij vond dat hij niet hoog genoeg was. Programmeren voelde in veel opzichten nog primitief aan. Waarom werden programmeurs nog steeds opgezadeld met incompatibele syntaxis van programmeertalen? Waarom was het zo moeilijk om hun voorkeurstalen uit te breiden naar nieuwe gebieden? Waarom werkten programmeurs nog steeds met platte tekst, waarbij ze een klein aantal tekens rangschikten in lineaire reeksen zoals ze dat in het verleden met ponskaarten hadden gedaan? Simonyi's Wysiwyg-werk had kantoormedewerkers de vrijheid gegeven om complexe documenten te maken en te bewerken. Ingenieurs en ontwerpers gebruikten geavanceerde CAD/CAM-tools om blauwdrukken voor wolkenkrabbers en vliegtuigen te ontwerpen en aan te passen. Waarom pikten programmeurs, de tovenaars die dit alles mogelijk hadden gemaakt, nog steeds hun code letter voor letter uit?
Zijn Microsoft Research-team ging aan de slag en in maart 1995 hadden ze een werkend systeem gebouwd voor het bouwen van programma's met behulp van de intentionele programmeerbenadering. Simonyi zei dat IP volledige zelfvoorziening had bereikt: dat wil zeggen dat al het toekomstige werk aan IP zou worden gedaan met behulp van IP zelf. Hij beloonde zijn team met T-shirts met een van zijn favoriete foto's uit zijn kindertijd: het beeld van baron Munchausen die zichzelf en zijn paard uit een moeras tilt door aan zijn eigen haar te trekken. Simonyi kondigde opzettelijk programmeren aan de wereld aan in een paper van september 1995 getiteld The Death of Computer Languages. Het werd tijd, zoals hij het later uitdrukte, dat de kinderen van de schoenlapper wat schoenen gingen halen.
Gedurende de jaren negentig en in het nieuwe millennium - terwijl Microsoft zijn oorlogen vocht met Netscape en het Amerikaanse ministerie van Justitie en de dotcom-zeepbel en de mislukking uitreed - werkten Simonyi en zijn team hard en leerden.
Ondertussen, vanaf 2001, dwong Microsoft de legers van ontwikkelaars die software voor Windows schreven om een nieuw programmeersysteem te gebruiken, het .Net Framework. In tegenstelling tot opzettelijk programmeren, was .Net voltooid en was een minder radicale breuk met bestaande programmeertechnieken vereist. Simonyi stond te popelen om zijn idee uit het lab te halen en voor te stellen aan klanten, maar dat was onder de omstandigheden onhandig. Hij legt uit: Het was onpraktisch, toen Microsoft op korte termijn enorme vooruitgang boekte met .Net, om op de een of andere manier iemand van dezelfde organisatie te sturen die zegt: Dit is niet hoe je dingen zou moeten doen - wat als je dingen deed in deze andere , meer ontwrichtende manier?
Simonyi was al meer dan 20 jaar een man bij het bedrijf. Maar in 2002 verliet hij Microsoft en richtte hij een onafhankelijk bedrijf op. Hij liep weg met een patent-cross-licentieovereenkomst die hem de concepten en ideeën van zijn onderzoek naar doelbewuste programmering liet gebruiken, maar hem niet toestond zijn oude code mee te nemen. Hij zou helemaal opnieuw moeten beginnen met het schrijven van een nieuwe codebasis.
Onder de vlag van zijn nieuwe bedrijf liet Simonyi het woord programmeren vallen en veranderde hij zijn project in opzettelijke software. Het basisidee was niet veranderd, maar nu begon hij de waarde van de aanpak voor niet-programmeurs te benadrukken. Simonyi's pitch ging ongeveer als volgt: vandaag kan alleen de programmeur een direct effect hebben op de software. Vakexperts of domeinexperts - de mensen die echt begrijpen wat de software moet doen, of het nu gaat om het bijhouden van medische dossiers, bedrijfsboekhouding of klimaatmodellering - kunnen geen wijzigingen aanbrengen in hun tools; ze worden gedwongen een soort bescheiden verzoek in te dienen bij de programmeur. Intentional Software zou softwareontwikkelingstools niet alleen verkopen aan programmeurs, maar ook aan domeinexperts die hun vakgebied echt kennen.
De strategie van Intentional Software leent van een trend in programmeren die bekend staat als domeinspecifieke talen of DSL's - kleine programmeerdialecten die zijn afgestemd op de behoeften van specifieke disciplines. Simonyi prijst DSL's, maar zegt dat ze niet ver genoeg gaan. Ze zijn moeilijk te maken en daarom kostbaar; je hebt er uiteindelijk meer dan één nodig (voor een medisch factureringssysteem heb je op zijn minst een medische en financiële taal nodig); en ze zijn onverenigbaar met elkaar. Het systeem van Intentional Software is als een fabriek voor meerdere DSL's die met elkaar kunnen praten.
Zo zou het kunnen werken: stel dat een internationale bank een nieuw systeem wil ontwikkelen voor het beheren van transacties in meerdere valuta's. Ten eerste zouden de eigen domeinexperts van de bank de functionaliteit van het systeem definiëren, gebruikmakend van hun gebruikelijke termen en symbolen en de belangrijkste variabelen identificeren (tijd of waarde of transactiegrootte) en de meest gebruikelijke procedures (tegoeden omzetten van de ene valuta naar de andere of hedges kopen). tegen dalende waarde). Dan zouden de programmeurs die informatie nemen en een domeinspecifieke programmagenerator bouwen die die informatie belichaamt. Met een aparte softwaretool kunnen domeinexperts experimenteren met verschillende gegevenssets en manieren om die gegevens te bekijken, net zo gemakkelijk als zakenmensen tegenwoordig hun spreadsheets herschikken.
De programmeur zou niet elke keer hoeven te worden opgeroepen als een nieuwe ontwikkeling in de wereld van internationaal bankieren of een ander domein een nieuwe softwarefunctie vereist. De klant zou zich niet in het nauw gedreven voelen door een programmeertaal. Iedereen zou blij zijn.
Simonyi stelt dat zijn aanpak een aantal van de meest hardnekkige problemen van software-engineering oplost. Programmeurs van tegenwoordig, zegt hij vaak, zijn onwetende cryptografen: ze verzamelen vereisten en kennis van hun klanten en verbergen die waardevolle informatie vervolgens letterlijk in een berg implementatiedetails, dat wil zeggen code. De vangst is dat, zodra de code is geschreven, de programmeurs eventuele toevoegingen of wijzigingen moeten aanbrengen door te wijzigen de code zelf . Dat werk is pijnlijk, traag en foutgevoelig. We zouden de code helemaal niet moeten aanraken, zegt Simonyi. We zouden in staat moeten zijn om functies en datastructuren te ontwerpen - die opzettelijke programmering vertegenwoordigt als opzettelijke bomen - en de generator de code dienovereenkomstig te laten aanpassen. (Voor een meer volledige beschrijving van opzettelijk programmeren, zie Intentionele programmering uitgelegd)
In 2002 stelde Simonyi een nieuw ontwikkelingsteam samen; vandaag omvat het een tiental programmeurs, verdeeld over Bellevue en Hongarije. Ze begonnen Simonyi's opzettelijke programmeercode helemaal opnieuw te maken en werkten samen met een handvol klanten om hun aannames te testen en feedback te krijgen. Een jaar geleden, geïnspireerd door een nieuw inzicht in het presenteren van meerdere weergaven van heterogene soorten gegevens, gooiden ze een groot deel van hun code weg en begonnen opnieuw. Het is creatieve destructie, zegt Simonyi. Bij Microsoft was het vrij moeilijk om dat te doen, om alles weg te gooien. Maar je moet afstand doen van dingen die moeilijk uit te breiden zijn.
ThoughtWorks, een wereldwijd IT-adviesbureau, is een vroege klant van Intentional Software. Maar de CEO van ThoughtWorks, Roy Singham, zegt dat veel van zijn collega's bij het bedrijf aanvankelijk sceptisch stonden tegenover Simonyi's nieuwe project: veel mensen kijken hiernaar en zeggen: 'Briljant concept, maar het is niet uitvoerbaar'. beste technische breinen om te gaan kijken, en ze kwamen allemaal terug en zeiden dat hij op de goede weg was. Ja, het is moeilijk. Ja, het zal tijd kosten, misschien vele jaren. Maar intellectueel heeft hij het voor elkaar. Het is het juiste probleem om op te lossen.
Ik heb enige frustratie gevoeld dat we nog niet iets hebben dat we echt in de productie kunnen gebruiken, zegt Martin Fowler, hoofdwetenschapper bij ThoughtWorks. Charles lijkt geen haast te hebben om te verzenden. Maar een ding om in gedachten te houden is dat hij in het verleden dingen heeft verzonden - behoorlijk dramatische dingen, met Office.
De zichtbare vrucht van het werk van Intentional tot nu toe is een handige tool, de Domain Workbench genaamd, die de essentiële informatie van een programma opslaat in een intentionele boomdatabase en u vervolgens veel verschillende projecties van die informatie biedt. In een demonstratie die Intentional afgelopen herfst op twee conferenties gaf, nam de Workbench - met behulp van een functie genaamd de Kaleidoscope - een reeks codefragmenten en toonde deze in een duizelingwekkende verscheidenheid aan formaten. Het maakte niet uit hoe de syntaxis van de code was gespecificeerd; je zou het kunnen bekijken en veranderen, met elke gewenste notatie. Je zou je programma kunnen bewerken als traditionele code tussen haakjes en ingesprongen, of overschakelen naar een overzichtsvorm, of het eruit laten zien als een schematisch elektrisch bedradingsschema, of iets kiezen dat een spoorwegdiagram wordt genoemd, een soort stroomdiagram dat is afgeleid van ouderwetse treinkaarten . Elke weergave is een vertaling van de onderliggende boom, die u ook kunt bekijken en bewerken.
Het werk van Intentional Software roept twee hoofdlijnen van kritiek op. Sommige theoretisch ingestelde sceptici zeggen dat Simonyi's doel om de bedoelingen van computergebruikers vast te leggen onwaarschijnlijk is. Hoe representeer je intentie? vraagt computerwetenschapper Jaron Lanier. Zodra we weten hoe de hersenen informatie opslaan, kunnen we misschien intentie weergeven. Voor mij lijkt het gewoon een fantasie. Een ander argument, dat veel voorkomt bij programmeurs, is praktischer. Veel programmeurs houden van hun op tekst gebaseerde editors en wantrouwen tools die hen distantiëren van onbewerkte code. Wat betreft grafische programmeertalen zoals Visual Basic en de geïntegreerde ontwikkelomgevingen (IDE's) die routinematige programmeertaken automatiseren, ze beschouwen ze neerbuigend: zulke tools, zeggen ze, leggen hun eigen manier van werken op, beperken creativiteit en houden programmeurs buiten de code waarmee ze vroeg of laat te maken krijgen. (Om te begrijpen waarom programmeurs zo op hun hoede zijn, zie The Law of Leaky Abstractions ) Sceptische programmeurs kijken naar Intentional Software en zien het vooruitzicht van gewoon weer een IDE. Voor degenen die denken dat echte programmeurs tekst schrijven, is opzettelijk programmeren niet erg origineel en ook niet erg gewild.
Maar meestal is er verrassend weinig discussie over opzettelijke software in de krioelende codeerforums van internet. Gedeeltelijk komt dat omdat zo weinigen de software hebben gezien. Het werk van Intentional is met enige geheimhouding verlopen.
Toen hij Intentional Software begon, werkte Simonyi samen met een professor aan de University of British Columbia, Gregor Kiczales genaamd. Simonyi bewonderde het werk van Kiczales op het gebied van aspectgeoriënteerd programmeren - een manier om code te organiseren en aan te passen volgens transversale problemen die lijkt op opzettelijk programmeren. Kiczales, een andere veteraan van PARC, heeft zijn hele carrière gewerkt aan manieren om de code op het ontwerp te laten lijken. Kiczales zag zich bij Simonyi aansluiten als een kans om dat doel te bevorderen. Maar Kiczales vertrouwde op open source-ontwikkeling, waar Simonyi dat niet deed. De gesloten-shop-aanpak in Microsoft-stijl voelde gewoon niet organisch aan voor Kiczales. Ik zou het op Java gedaan hebben, zegt hij. De eerste release zou over zes maanden zijn geweest. Het meningsverschil was vriendelijk maar onverzoenlijk, zeggen beide mannen, en het duurde niet lang of Kiczales was vertrokken.
Voorlopig, beschermd door Simonyi's rijkdom, heeft Intentional Software geen streefdatum of verzenddeadline. Maar een van zijn twee belangrijkste klanten beweert dicht bij de implementatie van Intentional-tools te zijn. Capgemini – een in Parijs gevestigd internationaal IT-service- en adviesbureau dat grote ondernemingen bedient en waarvan de CTO, Andy Mulholland, een kennis van Simonyi is – begon afgelopen maart met Intentional samen te werken en overweegt het systeem van Intentional te gebruiken voor projecten in de Europese pensioensector. De zeer complexe regels van het veld, verweven met de complexe structuur van het bedrijfsdomein, maken Simonyi's aanpak aantrekkelijk, zegt Henk Kolk, de technologiefunctionaris voor financiële dienstverlening van Capgemini, die samen met Intentional leiding geeft aan het werk van het bedrijf.
Grondbediening
Simonyi's fascinatie voor de ruimte is een leven lang. Als 13-jarige won hij een wedstrijd om Hongaarse Junior Astronaut te worden en reisde hij naar Moskou om een kosmonaut te ontmoeten. Als nieuwe medewerker bij Microsoft in 1981, overtuigde hij medeoprichter Paul Allen ervan om hooky te spelen bij de ontwikkeling van het nieuwe besturingssysteem van de IBM PC en naar Florida te vliegen om de eerste vlucht van de spaceshuttle te zien.
Simonyi's aanstaande ontploffing biedt hem een volledige reünie met de technologie uit het Sovjettijdperk die de koers van zijn leven heeft bepaald. Hij traint al maanden in het Russische Yuri Gagarin Cosmonaut Training Center in Star City, beheerst de details van ruimtepakken en ruimtetoiletten en leert Russisch.
De ruimtereis zal Simonyi's status bevestigen als dat hoogst onwaarschijnlijke ding: een beroemdheidsprogrammeur. Hij heeft twee jets en een vliegbrevet om ermee te vliegen. Hij verschijnt in de roddelbladen als de frequente metgezel van de hogepriesteres van het huishouden, Martha Stewart. Hij heeft een 233-voet jacht gebouwd met een omhullend dek met glazen wanden. Hij heeft een hoogleraarschap in Oxford gefinancierd voor zijn vriend Richard Dawkins, de darwinistische theoreticus.
Dit alles zal natuurlijk geen enkel verschil maken in de uitkomst van Simonyi's zoektocht om de chronische ellende van het softwareveld te verlichten. Het is niet genoeg om een geweldige programmeur te zijn, zei Simonyi ooit tegen Michael Hiltzik, auteur van een geschiedenis van PARC. Je moet een groot probleem vinden. Opzettelijk zal zijn grote beloften misschien nooit waarmaken. Maar niemand kan Simonyi verwijten dat hij een te bescheiden probleem heeft gekozen.
Zijn huis is tegenwoordig een herenhuis aan Lake Washington, langs de kust van het huis van Bill Gates, met een kunstgalerie, een met glas omsloten zwembad, een helihaven, een computerlab met magnetisch beklede muren en een draaibank en boormachine in de kelder (om die verlangens van de Erector Set te vervullen). Het huis kostte $ 10 miljoen om te bouwen: het is gekanteld in een hoek van zeven graden en ziet eruit als een lichte aardbeving die het heeft getroffen, in de woorden van New York Times schrijver Patricia Leigh Brown, die verbaasd was over de hermetisch afgesloten, wiskundige precisie en deze zo groot vond dat een bezoeker zich een eenzame asteroïde kan voelen die door het zonnestelsel ratelt.
[Alleen] Charles zou een huis van 20.000 vierkante meter met één slaapkamer bouwen, merkte Simonyi's proefschriftadviseur en PARC-collega Butler Lampson ooit op. De enige slaapkamer heeft een cockpit-achtig controlecentrum waarmee Simonyi al zijn systemen – verwarming, entertainment, telefoon, verlichting en bewatering – tot zijn tevredenheid kan aanpassen. Als een onderzeeër, legde hij uit aan Brown. Ze moeten allemaal groen zijn voordat je onder water gaat. Er is ook een draaibaar bed, dat Simonyi kan gebruiken om zijn uitzicht over het meer te verfijnen; of naar de skyline van Seattle, met zijn wirwar van kantoormedewerkers die worstelen met hun documenten en spreadsheets; of naar de sterrenhemel, waar zijn laatste reis hem spoedig zal brengen.
Scott Rosenberg is vice-president van speciale projecten bij Salon.com. Hij is de auteur van Dromen in code.
Opzettelijke programmering uitgelegd
Simonyi en het bedrijf pionieren met een drukknopbenadering van programmeren.
[ Klik hier voor een diagram van Simonyi's geplande aanpak]
Shane Clifford, een ontwikkelaar bij Intentional Software, vertelt deze fabel.
Er was eens een dorp met vier parken, onderhouden door vier competitieve buurtverenigingen. De eerste vereniging besloot haar park op te fleuren met een nieuwe bank. Het vroeg om voorstellen van drie van 's werelds toonaangevende bankfabrikanten. Geen van de ontwerpen won de meerderheid van de stemmen van de buren, dus koos de vereniging het meest populaire ontwerp. Het proces was democratisch, maar uiteindelijk waren de meesten niet tevreden met de nieuwe bank.
De tweede vereniging besloot dat ze een eigen bank wilde, maar wel eentje die iedereen leuk vond. Het vond een fabrikant die op maat gemaakte banken bouwde van mix-and-match onderdelen. Maar de houten zitting die de leden leuk vonden, had niet de juiste lengte en de decoratieve rugleuning werkte niet met de groene poten die ze leuk vonden. Dus ze compromissen op onderdelen die wel samenwerkten. De buren waren trots op de afgewerkte bank, maar er zat niet vaak iemand op.
De leden van de derde vereniging zagen hoeveel geld de eerste twee hadden uitgegeven en besloten dat ze het beter konden doen. De ambachtslieden in de groep vroegen iedereen om suggesties en uiteindelijk bouwden ze een eenvoudige, elegante bank waarvan iedereen het eens was dat deze de mooiste van het dorp was. Helaas wiebelde hij gevaarlijk.
De vierde bond wilde ook een bank, maar wilde de fouten van de andere groepen niet herhalen. De buren wendden zich tot een weinig bekende bankenmaker die reclame maakte voor een nieuwe ervaring met het maken van banken. De bankmaker arriveerde met een dieplader geladen met vreemd uitziende machines. Hij begon vragen te stellen als Wat is het belangrijkste kenmerk van deze bank? Wat is de op een na belangrijkste functie? Welke materialen vind je leuk? Wat is je favoriete vorm voor de poten van de bank?
Na elk antwoord draaide de bankmaker aan een paar knoppen op zijn machines en verscheen er een nieuw beeld van de bank in uitvoering op een groot scherm. Soms klopte het beeld niet helemaal, waardoor de buren teruggingen en de vragen anders beantwoordden. Na 50 vragen drukte de bankjesmaker op een grote knop. De machines zoemden een tijdje en braken toen een prachtige bank uit die overeenkwam met het uiteindelijke beeld op het scherm. Iedereen was blij dat hij een bijdrage had kunnen leveren, en elke dag zaten er veel mensen op de bank.
Om een bank te krijgen waar iedereen blij van wordt, moet je een automatische bankmachine bouwen; klanten helpen hun precieze verwachtingen voor hun bank te definiëren; vertaal die hoop in instructies die de machine voor het maken van banken begrijpt; en druk vervolgens op de Make-knop. Klanten krijgen volledige controle over het resultaat, en bankmakers, bevrijd van de repetitieve en mechanische onderdelen van het maken van banken, kunnen meer tijd besteden aan het gebruiken van hun vaardigheden om de wensen van hun klanten in de machine te verwerken.
Vervang banken door software, zegt Clifford, en je zult begrijpen wat opzettelijk programmeren wordt genoemd - zo genoemd omdat programmeurs zijn gefocust op de manier waarop hun klanten een programma willen laten werken, en niet op de rommel van code die nodig is om die bedoelingen uit te voeren.
Opzettelijk programmeren is qua concept vergelijkbaar met wat-je-zie-is-wat-je-krijgt tekstverwerkingsprogramma's, waarmee Charles Simonyi, de baas van Clifford, pionierde. Wysiwyg-teksteditors laten computergebruikers het uiterlijk van een document op het scherm manipuleren zonder hen te dwingen de onderliggende code onder de knie te krijgen. Op dezelfde manier moedigt opzettelijk programmeren computergebruikers aan om hun behoeften in hun eigen vertrouwde taal uit te drukken, en toont hen vervolgens begrijpelijke weergaven of projecties van het opkomende ontwerp voordat de uitvoerbare code wordt samengesteld. Het is niet de enige programmeerfilosofie die op dergelijke grafische weergaven vertrouwt; de Unified Modeling Language (UML), ontwikkeld in het midden van de jaren negentig bij Rational Software (nu onderdeel van IBM), gebruikt ook grafische diagrammen om de functie, structuur en het gedrag van een programma weer te geven. Maar UML-diagrammen kunnen niet worden omgezet in afgewerkte software, wat Simonyi's droom is voor opzettelijk programmeren.
Hoe hoopt Intentional Software die droom te realiseren? Laten we Simonyi's plan in een eigen diagram zetten (klik hier). Het proces voor het bouwen van software begint natuurlijk bij de klant: elke organisatie met een informatie-intensieve taak die moet worden geautomatiseerd. Simonyi noemt de mensen van deze organisaties domeinexperts; zij, niet de programmeurs, weten wat het programma moet doen.
Met de hulp van de programmeurs maken de domeinexperts een lijst van alle concepten en definities die de software nodig heeft. Al deze definities gaan naar een database die Simonyi het domeinschema noemt.
Zoals de bankmaker aan zijn knoppen draait, nemen de programmeurs de definities in het domeinschema vervolgens op in domeincode - een weergave op hoog niveau van de softwarefuncties, uitgedrukt in een domeinspecifieke taal of DSL, die kan worden aangepast aan de branche in kwestie. Maar hoewel DSL's kunnen variëren, wordt elke actie die de software moet uitvoeren, opgeslagen in een uniform formaat, een opzettelijke boom. Opzettelijke bomen hebben het voordeel dat ze visueel eenvoudig maar logisch veelomvattend zijn, wat betekent dat ze naar believen kunnen worden gemanipuleerd, herzien en geprojecteerd of gereviseerd.
Bijvoorbeeld de berekening die wordt weergegeven door de eenvoudige programma-instructie
retourneer a = b / (c +1) ;
wordt weergegeven door de volgende opzettelijke boom:
Opbrengst
(
Toewijzen
(
naar,
div
(
B,
Meer
(
C,
een
)
)
)
)
Eenmaal gecodeerd in boomvorm, kan de berekening op veel andere manieren worden geprojecteerd die voor domeinexperts misschien bekender zijn, zoals
B
retourneer a = ——- ;
c + 1
Als eerste concrete taak werken Simonyi en zijn collega's bij Intentional Software aan het bouwen van een speciale tool, de Domain Workbench, die is ontworpen om deze projecties te beheren. Zowel de domeinexperts als de programmeurs gebruiken de Domain Workbench om de projecties te bewerken en opnieuw te bewerken totdat ze er goed uitzien. Daarna wordt de domeincode ingevoerd in een generator - het equivalent van de vrachtwagenlading machines van de bankmaker - die doelcode produceert in een taal zoals C++ of Java die andere computers kunnen begrijpen, compileren en uitvoeren.
Zodra de doelcode is gegenereerd, kan deze niet meer worden omgezet in domeincode. In dat opzicht is de generator als een versleutelingsprogramma dat platte tekst onomkeerbaar omzet in cijfertekst.
Maar - en dit is misschien wel het grootste voordeel van opzettelijk programmeren - het is gemakkelijk om oude doelcode te schrappen en vanaf het begin verbeterde code te genereren. Pas eenvoudig de domeincode aan met behulp van de Wysiwyg-editor van Domain Workbench en voer deze opnieuw door de generator. In de meeste oudere benaderingen kan zelfs de kleinste verandering in de oorspronkelijke veronderstellingen vereisen dat programmeurs miljoenen regels code doorzoeken en elke instantie van een concept, definitie of berekening met de hand bijwerken.
De generator blijft de grootste black box in het proces van Intentional Software. In technische publicaties zal het bedrijf alleen maar zeggen over dit mysterieuze onderdeel dat het prototype wordt geschreven in de C#-programmeertaal van Microsoft en dat het toegang krijgt tot het domeinschema en de domeincode met behulp van een applicatieprogrammeerinterface, een manier voor twee programma's om te communiceren, dat is ingebouwd in de Domain Workbench. Het is echter duidelijk dat het schrijven van de generator zelf, of het aanpassen ervan voor een specifieke industrie of DSL, een groot deel van de kosten zal uitmaken van elk opzettelijk programmeerproject.
Wysiwyg stelde miljoenen meer gebruikers in staat om prachtige documenten te schrijven, schrijft Simonyi op de blog van het bedrijf. Het is tijd om hetzelfde te doen voor softwaregebruikers.
Door Wade Roush
De wet van lekkende abstracties
overgenomen uit Dreaming in Code: twee dozijn programmeurs, drie jaar, 4.732 bugs en één zoektocht naar transcendente software , door Scott Rosenberg, uit te geven door:
Crown Books in januari 2007.
We hebben gezien dat software bestaat uit lagen, waarbij elke laag informatie en processen vertaalt voor de lagen erboven en eronder. Onderaan deze stapel lagen zit de machine met zijn zuivere binaire enen en nullen. Aan de top staan de mensen, die deze lagen bouwen en gebruiken. Simonyi's Intentional Software stelt in wezen gewoon een extra laag voor tussen de machine en ons.
De lagen van software zijn de essentie ervan, en ze zijn de drijvende kracht achter de vooruitgang in het veld, maar ze hebben een aanhoudende zwakte. Ze lekken. Gebruikers van veel versies van Microsoft Windows zijn bijvoorbeeld vermoeid bekend met het fenomeen Blue Screen of Death. Je bent aan het werk in een softwaretoepassing zoals een webbrowser of Microsoft Word, en plotseling, uit het niets, wordt je scherm blauw en zie je wat witte tekst erop met de volgende tekst:
Er is een fatale uitzondering 0E opgetreden bij
0167: BFF9DFFF.
De huidige aanvraag wordt beëindigd.
Kijkend naar het monochrome uiterlijk van het scherm en het blokachtige lettertype, kunnen ervaren gebruikers het gevoel hebben dat ze achteruit zijn geslingerd in computertijd. Sommigen begrijpen misschien zelfs dat de alarmerende verwijzing in het bericht naar een fatale uitzondering betekent dat het programma een bug heeft aangetroffen waarvan het niet kan worden hersteld en dat het is gecrasht, of dat de cryptische hexadecimale getallen (grondtal 16) de exacte locatie in het computergeheugen beschrijven waar de crash plaatsvond vond plaats. Geen van de informatie is van enige waarde voor de meeste gebruikers. De comfortabele, vertrouwde interface van de applicatie die ze gebruikten is verdwenen; een diepere laag van abstractie - in dit geval de Windows-shell of een lager besturingsprogramma - is uitgebroken als een schuine laag gesteente die omhoog steekt door recentere geologische lagen en in het zonlicht.
(Hoe verwarrend het Blue Screen of Death ook is, het was in feite een grote vooruitgang ten opzichte van eerdere versies van Windows, omdat het de gebruiker soms in staat stelt het gewraakte programma af te sluiten en verder te werken. Vóór het blauwe scherm crasht een Windows-programma bijna altijd heeft de hele machine en al zijn programma's uitgeschakeld.)
In een essay getiteld The Law of Leaky Abstractions, schreef Joel Spolsky: Alle niet-triviale abstracties zijn tot op zekere hoogte lek. Abstracties mislukken. Soms een beetje, soms veel. Er is lekkage. Dingen gaan verkeerd. Voor gebruikers betekent dit dat uw computer zich soms op bizarre, verwarrende manieren gedraagt, en soms wilt u, zoals Mitch Kapor zei in zijn Softwareontwerpmanifest , gooi het uit het raam. Voor programmeurs betekent dit dat nieuwe tools en ideeën die een beetje computercomplexiteit op laag niveau bundelen en in een nieuwe, gemakkelijker te manipuleren abstractie verpakken, geweldig zijn, maar alleen totdat ze kapot gaan. Dan lekt al die verborgen complexiteit terug in hun werk. In theorie zorgt de handige nieuwe toplaag ervoor dat programmeurs de rommel eronder kunnen vergeten; in de praktijk moet de programmeur die rotzooi nog begrijpen, want uiteindelijk gaat hij erin belanden. Spolsky schreef:
Abstracties vereenvoudigen ons leven niet zo veel als ze bedoeld waren. ... De wet van lekkende abstracties betekent dat wanneer iemand met een wizzy nieuwe code-generatietool komt die ons allemaal zo efficiënt zou moeten maken, je veel mensen hoort zeggen: leer eerst hoe je het handmatig moet doen, en gebruik de wizzy-tool om tijd te besparen. Tools voor het genereren van codes die doen alsof ze iets abstraheren, zoals alle abstracties, lekken, en de enige manier om competent met de lekken om te gaan, is door te leren hoe de abstracties werken en wat ze abstraheren. Dus de abstracties besparen ons tijd bij het werken, maar ze besparen ons geen tijd bij het leren. … En dit alles betekent dat paradoxaal genoeg, zelfs als we programmeertools op een hoger en hoger niveau hebben met steeds betere abstracties, het steeds moeilijker wordt om een bekwame programmeur te worden.
Dus hoewel de abstracties die we in de loop der jaren hebben gemaakt ons in staat stellen om te gaan met nieuwe complexiteiten in softwareontwikkeling waar we tien of vijftien jaar geleden niet mee te maken hadden, en hoewel we met deze tools veel kunnen krijgen van het werk ongelooflijk snel gedaan, schreef Spolsky, plotseling moeten we op een dag een probleem vinden waar de abstractie lekte, en het duurt twee weken.
De wet van lekkende abstracties verklaart waarom zoveel programmeurs met wie ik heb gesproken sceptisch met hun ogen rollen als ze beschrijvingen horen van opzettelijk programmeren of andere soortgelijke ideeën om de complexiteit van software te overstijgen. Het is niet dat ze het niet leuk zouden vinden om nog een stap op de abstractieladder te zetten; maar ze zijn bang dat hoe hoog ze ook op die ladder klimmen, ze altijd meer op en neer zullen moeten rennen dan ze zouden willen - en hoe groter het wordt, hoe langer de reis.