Allt du kan göra kan jag göra Meta

Den 9 april, vid en fjärrstartplatta på Kazakstans slätter, kommer en markkontrollant att avsluta sin nedräkning; en sojusraket kommer att avfyras; och Charles Simonyi – Microsofts före detta chefsarkitekt, tutelargeniet bakom dess mest kända applikationer, uppfinnaren av metoden att skriva kod som företagets programmerare har använt i 25 år, och nu förespråkare för ett ambitiöst projekt för omprogrammering av programvara – kommer att börja hans uppstigning i rymden.

Charles Simonyi VD och koncernchef för Intentional Software.

Smidig i en rymddräkt, känner fyra Gs trycka ner honom i ett formtillpassat gjutet sätesfoder, kommer den 58-årige miljardären att bli den femte rymdturisten som besöker den internationella rymdstationen. Resan, som kommer att kosta Simonyi runt 20 miljoner dollar, kommer att uppfylla hans dröm om att bli en nörd i rymden (för att låna ett namn som han valde för webbplatsen som dokumenterar hans utomjordiska äventyr: www.nerdinspace.com ). Det kommer också att ge honom en möjlighet att se vår planet från ovan och bortom.

Detta har alltid varit Simonyis föredragna fördel. Under en karriär som sträcker sig över fyra decennier, varje gång han har ställts inför något svårlöst problem i mjukvaran eller livet, har han försökt lösa det genom att kliva utanför eller över det. Han har till och med ett namn för sin favoritgambit: han kallar det att gå meta. I sin ungdom i 1960-talets Ungern lärde han sig grunderna i datoranvändning på en föråldrad sovjetisk stordator som drivs av vakuumrör, och konstruerade sedan sin egen flykt till väst. På 1970-talet, vid Xerox legendariska Palo Alto Research Center (PARC), som en del av teamet som uppfann persondatorer, skrev Simonyi den första moderna applikationen: en ordbehandlare som förvisade de komplexa koder som sedan användes för att tagga text och visade ett dokument som det skulle se ut på papper. Vare sig i sin doktorsavhandling vid Stanford University om en metaprogrammeringsmetod för att öka programmerarens produktivitet, hans karriär på Microsoft organiserar legioner av mjukvaruutvecklare och lär dem hur de strukturerar sin kod, eller hans planerade resa in i jordens omloppsbana i vår, som går bortom etablerade sätt att göra saker har alltid varit Simonyis metod. Nu planerar han vad han hoppas ska bli hans mest välvda meta-rörelse av alla. Simonyi tror att han kan lösa en mängd envisa problem som alltid har plågat datorer genom att erbjuda alla som använder dem, och kodarna som programmerar dem, en högre ordnings syn på programvara.

Bill Gates kallar Simonyi en av de stora programmerarna genom tiderna. I själva verket är Simonyi utan tvekan den mest framgångsrik kodare i världen, mätt i termer av ekonomisk belöning och antalet personer som använder hans skapelser. (Andra hyllade programmerare-miljardärer, som Larry Ellison och Bill Gates själv, tjänade sina pengar och namn på att grunda och leda tekniksatsningar.) Simonyi kunde lätt välja att tillbringa resten av sitt liv med att ge filantropiska satsningar, flyga flygplan eller kryssa i sitt eget liv. Yacht. Istället, säger han, programmerar han förmodligen hårdare än någonsin tidigare. Han är besatt av ett projekt som han har drivit i ett och ett halvt decennium, och som för fyra år sedan bar honom direkt ut från Microsofts dörrar. Han är stolt över sitt yrke. Men han förföljs också av tanken på vad programmerare måste brottas med varje gång de sätter sig för att koda. Han frågar, varför är det så svårt att skapa bra mjukvara?

Multimedia

• Ytterligare bilder av Simonyi

Napoleons kod

Vår civilisation körs på mjukvara, säger Bjarne Stroustrup, uppfinnaren av programmeringsspråket C++ (se Problemet med programmering) . Men själva programvaran fungerar inte särskilt bra. Vart du än ser är programvaran över budget, efter schemat, osäker, opålitlig och svår att använda. Varje gång en organisation försöker introducera ett nytt system, eller uppgradera ett gammalt, tar det en kolossal risk; idag är stora informationsteknikprojekt tekniska tjärgropar som immobiliserar institutioner. Studier rapporterar regelbundet att två tredjedelar av sådana projekt stöter på stora förseningar, betydande kostnadsöverskridanden eller både och. Den amerikanska regeringen har funnit det nästan omöjligt att införa eller uppgradera storskaliga mjukvarusystem: decennielånga ansträngningarna vid Federal Aviation Administration och FBI har kollapsat i kaos. Företagen har inte klarat sig bättre. För att ge ett enda exempel drömde McDonalds chefer om ett webbaserat hanteringssystem som de kallade Innovate som skulle spåra realtidsflödet av hamburgare, pommes frites och kycklingnuggets i var och en av deras restauranger runt om i världen. När de gav upp och avbröt projektet var de tvungna att skriva av 170 miljoner dollar av dess beräknade totala kostnad på 1 miljard dollar.

Sådana misslyckanden räcker till. Varje år, enligt en studie från 2002 av National Institute of Standards and Technology, kostar programvarufel 59,5 miljarder dollar. Men priset på dålig programvara kan också mätas i mänskligt elände – och till och med i förlorade liv. Under Gulfkriget 1991 sköt inte ett Patriot-missilbatteri mot en inkommande Scud på grund av felaktig programvara; direktträffen på en barack dödade 28 amerikanska soldater.

Det senaste halvseklets datoranvändning har sett fantastiska framsteg. Programmerare har övergett hålkort och teletyper. De har gett oss en dator på varje skrivbord, verktyg för arbetet, leksaker för lek och ett nätverk som länkar hem och företag för att bilda en myllrande global pool av information och underhållning. Dessa framsteg har underblåsts av den exponentiella kurvan av Moores lag, Intels grundare Gordon Moores förutsägelse att mikrochips effekt skulle fördubblas (eller att deras kostnad skulle halveras) vartannat till vartannat år. Men även när Moores lag har gjort varje års nya datorer snabbare och billigare, har flexibiliteten och användbarheten hos våra datorsystem begränsats av mjukvarans långsammare, ojämna utveckling. En formulering av detta problem är känd som Wirths lag, efter programmeringsexperten Niklaus Wirth: Programvaran blir långsammare snabbare än hårdvaran blir snabbare.

Simonyi delar mycket av det vanliga missnöjet med mjukvara. Programvara som vi känner den är flaskhalsen på överflöds digitala horn, säger han. Det tar upp enorma resurser i talang och tid. Det är en besvikelse och svårt att ändra. Det blockerar innovation i många organisationer.

Simonyis ambition är att få stopp på den mjukvaruflaskhalsen – karakteristiskt sett genom att gå meta. Han har utvecklat ett tillvägagångssätt som han kallar avsiktlig programmering (eller, på senare tid, avsiktlig programvara), som han hoppas kommer att störta programmering. Om Simonyi får sin vilja igenom kommer programmerare att sluta försöka hantera sina kunders behov. Istället kommer de att för varje problem de ombeds ta itu med – oavsett om lagerspårning eller missilvägledning – skapa generiska verktyg som datoranvändarna själva kan modifiera för att vägleda programvarans framtida utveckling.

En grå eftermiddag i oktober förra året satte jag mig ner med Simonyi i Bellevue, WA, framför två intilliggande skärmar på hans kontor på Intentional Software, företaget som han grundade efter att han lämnade Microsoft 2002 för att utveckla och kommersialisera sin stora idé. Simonyi körde mig igenom en presentation som han förberedde för en kommande konferens; han använde Microsoft Office PowerPoint-bilder för att beskriva sin vision för det föreslagna stora steget framåt i programmering. Han var mitt uppe i att flytta runt en bild när applikationen precis slutade svara.

I hörnet på den vänstra skärmen dök ett gem med glasögon upp: den vida utskällda Office Assistant som Microsoft introducerade 1997. Simonyi försökte ignorera den tecknade medhjälparens krånglande, men han blev förkyld. Ingenting fungerar, suckade han. Det beror på att Clippy ger mig lite hjälp.

Jag blev förbryllad. Du menar att du inte har stängt av Clippy? För länge sedan hade jag letat igenom Offices menyer och markerat vilken ruta som krävdes för att strypa den irriterande antropomorfen en gång för alla.

Jag vet inte hur, erkände Simonyi, med ett litet skratt som tycktes säga, Ja, jag vet, är det inte ironiskt?

Det var. Simonyi tillbringade flera år med att leda applikationsteamen hos Microsoft, utvecklarna av Word och Excel, vars produkter används varje dag av tiotals miljoner människor. Han anses allmänt vara fadern till Microsoft Word. (Jag använder naturligtvis Word för att skriva dessa meningar.) Kan Charles Simonyi ha träffat sin match i Clippy?

Simonyi stirrade på sin motståndare, som om han var låst i telepatiska strider. Sedan vände han sig mot mig med blåa ögon som lyste. Jag behöver en hjälpare: en Super-Clippy som visar mig var jag ska stänga av honom! Simonyi var sugen på en meta-Clippy.

2004 föreslog Simonyi sin egen lag: Allt som kan göras kunde göras 'meta.' I hans yngre dagar – när han grandiost hade döpt ett projekt till Simonyis Infinitely Glorious Network – skulle han förmodligen ha varit mer arrogant: Allt du kan gör, jag kan göra meta! Men som många underbarn som har gjort det bra och åldrats bra, har Simonyi lärt sig att skära av sin kaxighet med inslag av ödmjukhet och nåd. För ett decennium sedan beskrev han sig själv som en lurvig kille med utländsk accent. Han föredrar svarta turtlenecks och dubbelknäppta blazers. Med sin upprättstående hållning och fyrkantiga ansikte, en chock av mörkt hår framkammat över pannan, sägs han ofta likna en Napoleon med större ben.

Avsiktlig programvara är en storslagen plan inom ett område där stora system sällan har fungerat. Varje tidigare innovation som introducerats som en komplett lösning på mjukvarans problem har slutat med att inte ge mer än blygsamma, inkrementella förbättringar. Men Simonyi fylls av självförtroendet hos en självgjord invandrare som alltid har haft ett fast grepp om sina egna stövlar. På ett foto som hänger över hans skrivbord står han i Vita huset under ett porträtt av Ronald Reagan. Hans breda leende speglar presidentens. Bildtexten lyder De två optimisterna.

Kontoret för Simonyis nya företag upptar en svit i en elegant glasskyskrapa, och om du lutar dig in i fönstret och tittar ner kan du se taket på den hukande, obeskrivliga vita byggnaden som inhyste hans första kontor på Microsoft, redan 1981. ( Det är en bank nu.) Sedan dess har Microsoft vuxit till oigenkännlighet. Mjukvaruindustrin har förändrat världen. Så varför skulle Simonyi sätta sig för att skriva om alla dess regler? Problemet är så stort att det verkar vara en del av den fasta ordningen. Simonyis föreslagna lösning kan ta årtionden att slutföra, och hans kritiker är intensivt skeptiska. Ingen ber honom att lämna bakom sig de kända rutinerna för programmering och ge sig av mot en ny värld. Men sådana migrationer har lönat sig för honom tidigare.

Maskinens språk

Simonyi föddes i Budapest 1948. Son till en fysikprofessor, blev han kär vid 15 år i sin första dator – en maffig rysk Ural II på Ungerns centrala statistikkontor. På 1960-talet skulle Ural, som fick sina instruktioner genom kassaliknande nycklar och hade ett rum fullt av vakuumrör för att utföra beräkningar, redan ha varit en kvarleva någon annanstans i världen. Men Ungerns kommunistiska ledare försökte använda den sovjetiska förkastningen för att optimera tåg- och lastbilstider. Ural klarade inte uppgiften: det fanns inget sätt att mata in realtidsdata om försändelser. Det var helt hopplöst, minns Simonyi. Det kunde ha gjorts mycket enkelt av utbud och efterfrågan. Tyvärr var det politiskt inkorrekt.

Men Simonyi brydde sig inte. Jag älskade den där datorn, säger han, även om den var värdelös. Som barn hade han byggt en Erector Set-bil med en fyrväxlad växellåda – inte så mycket för att han ville leka med den bara för att förstå hur den fungerade. En tidigare elev till hans far hittade Simonyi ett jobb som Urals nattsköterska. Eftersom maskinen blåste ut ett rör varje gång den stängdes av och på, föredrog statistikkontoret att låta den gå hela natten. Alltså, från skymning till gryning var stordatorn helt Simonyis; han hade en persondator innan sådana saker fanns. Han lärde sig att programmera det genom att skriva smarta men värdelösa rutiner för att skapa magiska kvadrater – numeriska arrayer där summan av raderna, kolumnerna och diagonalerna matchar.

Programmerare på andra håll i världen hade redan uppfunnit ett Babel av programmeringsspråk – Fortran, Cobol, Lisp (ett sagospråk: se Ancient Text, s. 20), och så vidare – för att underlätta deras arbete, som då som nu bestod av att mödosamt skriva utarbetade uppsättningar instruktioner för datorer att exekvera. På dessa språk tog instruktionerna formen av textrader som skrevs in på tangentbord och ofta lagrades på hålkort. Denna källkod kompilerades sedan eller översattes till maskinkod – den ett s och 0 s som en digital dator kan förstå. Metoden är i stort sett oförändrad idag, även om de flesta programmerare nu använder programmeringsverktyg som körs på vanliga datorer. Men på Ural lärde sig Simonyi att programmera på en mer primitiv nivå, mödosamt att stansa in maskinspråkets opkoder, specificera, instruktioner för instruktion, sekvenserna av minneshämtningar, tillägg, minneslagringar och hopp som datorns processor var tvungen att följa att utföra även den mest triviala operationen. Det var (som Simonyi sa till författaren Steve Lohr i 2001 års bok Gå till ) Stenåldersprogrammering. Simonyi kommer fortfarande ihåg koderna. Tjugotvå är JUMP, säger han i dag. Det har bränts in i min ROM.

Ungern på 1960-talet, som fortfarande ryckte undan det sovjetiska undertryckandet av dess revolt 1956, var inte en plats för en ambitiös ung man med smak för problemlösning. Som 17-åring fick Simonyi en praktikplats hos ett danskt dataföretag genom att visa några av dess programmerare exempel på hans handkodade Ural-program. De ungerska myndigheterna förväntade sig att Simonyi skulle återvända; han hade redan vunnit en eftertraktad universitetsplats. Istället, med sin fars uppmuntran, flydde han till USA.

Ett rekommendationsbrev från den danske programmeringsexperten Peter Naur hjälpte honom att vinna inträde till University of California, Berkeley. Han betalade räkningarna med ett jobb på Berkeleys datorcenter, där han fångade uppmärksamheten hos en lärare vid namn Butler Lampson. Lampson var en av ledarna för U.S. Defense Advanced Research Projects Agencys Project Genie – ett experiment i tidsdelningsdatorsystem, där flera användare som sitter vid terminaler kunde dela en enda dators hjärntid. När skaparna av Project Genie startade ett företag, kallat Berkeley Computer Corporation (BCC), vars syfte var att bygga en maskin som skulle kommersialisera deras arbete, rekryterade Lampson Simonyi.

På BCC skulle Simonyi felsöka företagets tråkiga prototyp hela natten, i samarbete med systemdesignern Chuck Thacker. En natt dök Simonyi upp i en genomskinlig svart outfit – en sorts hippiegrej från en av butikerna på Telegraph Avenue, säger han. Idag kommer han inte ihåg exakt varför – kanske han kommer från en fest? Felsökningen gick särskilt bra den kvällen, och outfiten blev en lyckoapp – Simonyis felsökningskostym.

BCC gick upp efter bara några år, men Lampson, Thacker och mycket av BCC-teamet migrerade till Xerox PARC. Simonyi – då bara en slumpmässig ungersk student utan grönt kort, som han säger nu – gick med i dem 1972, arbetade på Xerox samtidigt som han fortsatte sin doktorsexamen i Stanford. Bob Taylor, som övervakade PARC:s datavetenskapslabb under en del av den legendariska eran, säger att Simonyis kreativitet stack ut även i labbets berömda publik: Han kunde bara föreställa sig sätt att uttrycka kod och idéer som satte honom utanför listorna.

Det var en berusande tid. Teamet av visionära ingenjörer skapade en serie innovationer som skulle forma nästa kvartssekel av PC-eran: det grafiska användargränssnittet, nätverk (Ethernet), laserskrivaren, objektorienterad programmering (Smalltalk), bärbar datoranvändning (den Dynabook) och mer. Dessa genombrott konvergerade alla på en prototypisk persondator som kallas Alto.

Alto var en fantastisk uppfinning, men det var inte klart vad du kunde göra med den förrän Simonyi och hans kollegor skapade dess mest kända applikation: en ordbehandlare som heter Bravo, vars skärmvisning av typ matchade vad systemet skulle mata ut till den nya laserskrivaren. Befintliga ordbehandlare hade utarbetade system med koder för att formatera text på skärmen (alla som använde WordPerfect på en PC på 1980-talet kommer ihåg dess inbäddade koder); Bravo låter dig glömma koderna, direkt manipulera utformningen av ett dokument och omedelbart bevittna förändringarna. En besökande Citibank-chef tittade på en demo och citerade en signaturrad av komikern Flip Wilsons fräcka karaktär Geraldine: Vad du ser är vad du får! Namnet (reducerat till akronymen Wysiwyg och uttalat wizzywig ) fastnat. Plötsligt hade Bravo användare: släktingar och vänner till PARC-forskare började be om att få använda den för att skriva ut skolnyhetsbrev och formatera akademiska uppsatser. Lampsons fru skrev ut sin avhandling med hjälp av systemet, och när det var dags för Simonyi att skriva ut sin, gjorde han detsamma.

Nivåer av abstraktion

Wysiwyg är ett exempel på ett lager av abstraktion – ett verktyg på högre nivå som låter datoranvändare ignorera viss komplexitet på lägre nivå. Programmerare använder abstraktioner hela tiden. Textkoden skriven på ett programmeringsspråk är en abstraktion av maskinkoden som en dator faktiskt förstår. Ett webbdomännamn är en abstraktion av en servers numeriska Internet Protocol-adress.

Men de flesta av abstraktionsskikten i datorsystem är mindre synliga och mer svårbegripliga än Wysiwyg. Ända sedan programmerare slutade memorera opkoderna som Simonyi använde i sin ungdom, har de lagt nya abstraktioner på äldre abstraktioner. Varje generation av programmerare använder sin eras programmeringsspråk och verktyg för att bygga nästa generations program. Lager av abstraktion har ackumulerats som geologiska skikt. Meddelanden rusar ständigt upp från din maskins binära berggrund och tillbaka ner igen, vilket gör det möjligt för ett musklick för att utföra sin funktion. Ditt musklick utlöser viss kod i operativsystemet, som skickar ett meddelande till ordbehandlingsprogrammet, som instruerar operativsystemet att spara din fil på en hårddisk. Men den till synes enkla processen är möjlig bara på grund av många, många lager av abstraktion.

Programvarans historia är historien om dessa lager, var och en av dem lyfter programmerare längre från det binära, vilket gör dem bättre kapabla att lura datorer till att utföra användbara uppgifter. Programmerare fick stadigt mer makt. Men de tacklade också allt mer ambitiösa problem. Program ökade i storlek och programmerare började gå vilse i härvor av vad de kallade spagettikod, som visade sig omöjlig att reda ut och reparera. Sålunda blev stora mjukvaruprojekt epos av frustration och förseningar. Programledare stötte på affärsproblem som, Hur schemalägger du ett projekt realistiskt? Hur förbättrar du individuell produktivitet? Hur koordinerar du komplext arbete i ett stort team? Var och en av dessa frågor visade sig vara förvånansvärt svåra att besvara.

Svårigheten att koordinera ett teams arbete inspirerade programvaruteknikens mest kända påstående, känd som Brooks's Law: Adding manpower to a late software project gör det senare. Frederick P. Brooks Jr. kom till denna dystra slutsats efter att ha lett IBM:s oroliga försök att skriva mjukvara för sina 360 stordatorer på 1960-talet. I sin bok från 1975, Den mytiska man-månaden , observerade Brooks att arbetet går långsammare i större team på grund av koordineringskostnader – den tid som programmerare förlorar på att hålla varandra informerade om sitt arbete.

Detta var bakgrunden till Simonyis avhandling från 1977, Meta-Programming: A Software Production Method. Simonyi föreslog ett nytt tillvägagångssätt för att optimera produktiviteten, där en huvudprogrammerare, eller metaprogrammerare, designade en produkt och definierade alla dess termer, och sedan lämnade över en ritning till tekniker, arbetar-bi-programmerare som skulle göra implementeringen. Simonyi siktade på att undkomma Brooks lag genom att förbjuda teknikerna att prata med varandra: all kommunikation måste gå genom metaprogrammeraren. För sin avhandling testade han idén med två grupper i två projekt, A och B. Hans despotiska inställning till programmering slog aldrig fast, men det bekymrade honom knappast. Simonyis främsta mål med sin avhandling var inte att bevisa värdet av sina idéer utan att få Bravo, den nya Wysiwyg-ordbehandlaren, skriven snabbare. Han kunde inte övertala PARC-mässan att anställa ytterligare programmerare, så han använde sin avhandling som ett redskap för att få in lite hjälp. Bravo i sig var projekt B.

När 1970-talet fortsatte, blev Simonyi otålig med Xerox oförmåga att omvandla PARC:s banbrytande forskning till framgångsrika produkter. En dag visade en vän honom VisiCalc, det nya kalkylprogrammet för Apple II. Det gladde Simonyi. Här fanns en annan applikation, som Bravo, som kunde förändra människors liv, men till skillnad från Bravo kördes den på en massmarknadsdator som folk hade råd att köpa. PARC:s arbete, insåg han, skulle aldrig se dagens ljus. Han bad sin tidigare PARC-kollega Bob Metcalfe, som lämnade labbet 1979 för att starta 3Com, att rekommendera blivande chefer i den nya PC-industrin. I spetsen på listan stod Bill Gates.

1981 flyttade Simonyi till Seattle för att starta den nya applikationsgruppen hos Microsoft, som fram till dess hade sålt programmeringsspråk och operativsystem. Han var 33, men det gjorde honom till en vuxen bland Microsofts unga barn (Gates var då 26 år gammal, Steve Ballmer 25).

Under alla år som Simonyi övervakade produkterna som så småningom smälte samman i programsviten känd som Microsoft Office, fortsatte han att söka nya effektivitetsvinster i nya typer av programmeringsabstraktioner. Mest anmärkningsvärt är att han utbildade generationer av Microsoft-programmerare i disciplinen att hålla reda på de otaliga variabelnamnen som används i stora program. I datorprogrammering representerar variabler information som kan ändras när ett program körs. Till exempel kommer en webbutiks kundvagnsprogram att ha variabler som representerar antalet varor av varje typ som ska köpas, varje varas pris och fraktkostnader och skatter. Med hjälp av dessa variabler kan en programmerare skriva en enkel kodrad som multiplicerar kvantitet med pris, lägger till frakt och skatter och beräknar den totala kostnaden – vilket blir värdet av ännu en variabel.

Ett stort program kan ha tusentals olika variabler som ett programmeringsteam måste hålla rakt. Att namnge dem noggrant blir avgörande. Idag har de flesta koder variabelnamn utformade för att förmedla mening till programmerarna som kommer att läsa den – namn som NumberOfItems eller ShoppingCartTotal. I Simonyis namnschema, som han hade uppfunnit för eget bruk år tidigare, kommer varje variabelnamn med ett prefix som berättar användbar information om det, som dess typ (heltal, säg eller decimalbråk eller sträng av bokstäver). Vissa system begränsar längden på variabelnamn till åtta tecken; Simonyi utelämnade helt enkelt vokalerna.

Den resulterande koden var tät och svår att läsa. Simonyis system kom att bli känt som ungersk notation, både som en hyllning till skaparens födelseplats och för att det fick program att se ut som om de var skrivna på något outgrundligt främmande språk, enligt programmeringspionjären Andy Hertzfeld. Ungerskan är allmänt förbannad av sina belackare. Den kanadensiska Java-experten Roedy Green har skämtsamt kallat det för det taktiska kärnvapen som används för tekniker för förvirring av källkod. Mozilla-programmeraren Alec Flett skrev denna parodi:

prepMen nI vrbLike adjUngerska! qVad är konstThe adjBig nProblem?

Hertzfeld, som skrev om ett möte hos Apple med någon ungersk kod skriven av en kollega som hade arbetat med Simonyi på PARC, sa att namnen såg ut som om de var valda av Stålmannens fiende från den 5:e dimensionen, Mr. Mxyzptlk.

Men medan kritiker tror att ungerska gör koden oläslig, är Simonyi fortfarande stolt över den och använder den till denna dag.

Meta-eufori

I början av 1990-talet hade Microsofts framgång gjort Simonyi s förmögenhet. (För några år, Forbes har uppskattat det till 1 miljard dollar.) Men han kände fortfarande draget av oavslutade ärenden. Programvarans förvirring hade gjort skapandet av Office nervkittlande för Microsoft. Men nu, med datorer kraftfullare än Alto på varje skrivbord och Internet som länkar dem samman, var programvarans kris allas kris. Simonyi började tänka att det var dags att gå meta igen.

Charles har alltid försökt bygga sina system på sätt som höjer abstraktionsnivån, så att man kan hantera komplexiteten i systemet. För komplexitet är död, säger Chuck Thacker, Simonyis gamla kollega från BCC och PARC, som leder ett forskningsprojekt om datorarkitektur på Microsoft. Och tyvärr, nuförtiden, resulterar det i ett komplext system om de faciliteter människor faktiskt vill ha. Vi hänger på med fingertopparna just nu.

Simonyi flyttade till en position på Microsoft Research och började definiera begreppet avsiktlig programmering, eller förkortat IP. Avsiktlig programmering skulle lägga till ett helt nytt lager av abstraktion till praktiken att skriva programvara. Det skulle göra det möjligt för programmerare att uttrycka sina avsikter utan att sjunka ner i myren av så kallade implementeringsdetaljer som alltid hotade att svälja dem. Liksom metaprogrammerarna i Simonyis avhandling, som skickade instruktioner till arbetar-bikodare, skulle den avsiktliga programmeraren lämna över scut-arbetet – men inte till en yngre kollega. Istället krävde avsiktlig programmering en sorts kodfabrik som kallas en generator, ett program som tar in en uppsättning relativt högnivåkommandon och spottar ut mer detaljerad arbetskod. Målet var inte så mycket att underlätta programmeringsarbetet som att låta programmerare rensa sina hjärnor från trivialiteter så att de faktiskt kunde vara kreativa.

Från sin programmeringsinitiering som tonåring som slog in opkoder i Ural, hade Simonyi klättrat på abstraktionsstegen. Men han kände att han inte var tillräckligt hög. På många sätt kändes programmering fortfarande primitiv. Varför var programmerare fortfarande sadlade med inkompatibla programmeringsspråkssyntaxer? Varför var det så svårt att utöka deras föredragna språk till nya områden? Varför arbetade programmerare fortfarande med vanlig text och ordnade ett litet antal tecken i linjära strängar som de gjorde förr i tiden? Simonyis Wysiwyg-arbete hade befriat kontorsanställda att skapa och redigera komplexa dokument. Ingenjörer och designers använde avancerade CAD/CAM-verktyg för att designa och modifiera ritningar för skyskrapor och flygplan. Varför plockade programmerare, trollkarlarna som hade gjort allt detta möjligt, fortfarande ut sin kod ett tecken i taget?

Hans Microsoft Research-team började arbeta och i mars 1995 hade de byggt ett fungerande system för att konstruera program med avsiktlig programmering. Simonyi sa att IP hade uppnått fullständig självförsörjning: det vill säga allt framtida arbete med IP skulle göras med hjälp av IP själv. Han belönade sitt team med t-shirts prydda med en av hans favoritbilder från barndomen: bilden av Baron Munchausen som lyfter upp sig själv och sin häst ur en myr genom att rycka i sitt eget hår. Simonyi tillkännagav avsiktlig programmering för världen i en uppsats från september 1995 med titeln The Death of Computer Languages. Det var dags, som han senare uttryckte det, för skomakarens barn att få några skor.

Genom 1990-talet och in i det nya millenniet – medan Microsoft utkämpade sina krig med Netscape och det amerikanska justitiedepartementet och red ut dotcom-bubblan och bysten – arbetade Simonyi och hans team och lärde sig.

Under tiden, med början 2001, pressade Microsoft arméerna av utvecklare som skrev programvara för Windows att anta ett nytt programmeringssystem som kallas .Net Framework. Till skillnad från avsiktlig programmering var .Net färdigt, och det krävde ett mindre radikalt avbrott från befintlig programmeringsteknik. Simonyi längtade efter att ta ut sin idé från labbet och lägga fram den för kunder, men det var besvärligt under omständigheterna. Han förklarar: Det var opraktiskt, när Microsoft gjorde enorma framsteg med .Net på kort sikt, att på något sätt skicka ut någon från samma organisation som säger: Det är inte så du ska göra saker – tänk om du gjorde saker i den här andra , mer störande sätt?

Simonyi hade varit en företagsman i mer än 20 år. Men 2002 lämnade han Microsoft och startade ett oberoende företag. Han gick ut med ett patent-korslicensavtal som lät honom använda begreppen och idéerna från hans avsiktliga programmeringsforskning men tillät honom inte att ta med sig någon av sin gamla kod. Han skulle behöva börja skriva en ny kodbas från början.

Under sitt nya företags fana släppte Simonyi ordet programmering och döpte om sitt projekt till avsiktlig programvara. Grundidén hade inte förändrats, men nu började han betona tillvägagångssättets värde för icke-programmerare. Simonyis pitch gick ungefär så här: Idag är det bara programmeraren som kan ha en direkt effekt på programvaran. Ämnesexperter eller domänexperter – de människor som faktiskt förstår vad programvaran behöver göra, oavsett om det är journalföring, företagsredovisning eller klimatmodellering – kan inte göra ändringar i sina verktyg; de tvingas skicka in en sorts ödmjuk begäran till programmeraren. Intentional Software skulle sälja verktyg för mjukvaruutveckling inte bara till programmerare utan till domänexperter som verkligen kunde sina områden.

Intentional Softwares strategi lånar från en trend inom programmering som kallas domänspecifika språk eller DSL – små programmeringsdialekter som är inställda på specifika discipliners behov. Simonyi berömmer DSL:er men säger att de inte går tillräckligt långt. De är svåra att skapa och därför dyra; det slutar med att du behöver mer än ett (för ett medicinskt faktureringssystem behöver du åtminstone ett medicinskt och ett finansiellt språk); och de är oförenliga med varandra. Intentional Softwares system är som en fabrik för flera DSL:er som kan prata med varandra.

Så här kan det fungera: Anta att en internationell bank ville utveckla ett nytt system för att hantera transaktioner i flera valutor. Först skulle bankens egna domänexperter definiera systemets funktionalitet, med hjälp av deras vanliga termer och symboler och identifiera de viktigaste variablerna (tid eller värde eller storlek på transaktionen) och de vanligaste procedurerna (konvertera innehav från en valuta till en annan eller köpsäkring mot fallande värde). Sedan skulle programmerarna ta den informationen och bygga en domänspecifik programgenerator som förkroppsligar den informationen. Ett separat mjukvaruverktyg skulle göra det möjligt för domänexperterna att experimentera med olika uppsättningar data och sätt att se dessa data lika enkelt som affärsmän i dag ordnar om sina kalkylblad.

Programmeraren skulle inte behöva tillkallas varje gång någon ny utveckling inom den internationella bankvärlden, eller någon annan domän, krävde en ny mjukvarufunktion. Kunden skulle inte känna sig tvångströja av ett programmeringsspråk. Alla skulle vara glada.

Simonyi hävdar att hans tillvägagångssätt löser flera av mjukvaruteknikens mest ihållande problem. Programmerare idag, säger han ofta, är ovetande kryptografer: de samlar in krav och kunskap från sina kunder och döljer sedan, bokstavligen, den värdefulla informationen i ett berg av implementeringsdetaljer – det vill säga kod. Haken är att när koden väl är skriven måste programmerarna göra några tillägg eller ändringar genom att modifiera själva koden . Det arbetet är smärtsamt, långsamt och benäget att misstag. Vi borde inte röra koden alls, säger Simonyi. Vi borde kunna designa funktioner och datastrukturer – som avsiktlig programmering representerar som avsiktliga träd – och låta generatorn modifiera koden därefter. (För en mer fullständig beskrivning av avsiktlig programmering, se Avsiktlig programmering förklarad)

2002 satte Simonyi ihop ett nytt utvecklingsteam; idag omfattar det ett dussin programmerare, fördelat på Bellevue och Ungern. De började återskapa Simonyis avsiktliga programmeringskod från början och arbetade med en handfull kunder för att testa sina antaganden och få feedback. För ett år sedan, inspirerade av en ny insikt i hur man presenterar flera synpunkter på heterogena typer av data, kastade de ut mycket av sin kod och började igen. Det är kreativ förstörelse, säger Simonyi. Hos Microsoft var det ganska svårt att göra det, att slänga allt. Men man måste överge saker som är svåra att förlänga.

ThoughtWorks, ett globalt IT-konsultföretag, är en tidig Intentional Software-kund. Men ThoughtWorks VD, Roy Singham, säger att många av hans kollegor på företaget från början var skeptiska till Simonyis nya projekt: Många tittar på det här och säger: 'Briljant koncept – men det går inte att implementera.' Så vi frågade några av våra bästa tekniska hjärnor att gå och titta, och alla kom tillbaka och sa att han är på rätt väg. Ja, det är svårt. Ja, det kommer att ta tid - kanske många år. Men intellektuellt sett har han fått grejen fast. Det är rätt problem att lösa.

Jag har känt en viss frustration över att vi inte har något vi faktiskt kan använda i produktionen ännu, säger Martin Fowler, chefsforskare på ThoughtWorks. Charles verkar inte ha så bråttom att skicka. Men en sak att tänka på är att han har skickat saker tidigare – ganska dramatiska saker, med Office.

Den synliga frukten av Intentionals arbete hittills är ett snyggt verktyg som kallas Domain Workbench, som lagrar ett programs viktiga information i en databas med avsiktligt träd och sedan erbjuder dig många olika projektioner av den informationen. I en demonstration som Intentional gav vid två konferenser i höstas tog Workbench – med hjälp av en funktion som kallas Kalejdoskopet – en serie kodfragment och visade dem i en svindlande mängd olika format. Det spelade ingen roll hur syntaxen för koden hade specificerats; du kan se den och ändra den, med vilken notation du föredrar. Du kan redigera ditt program som traditionell kod med hakparenteser och indragen kod, eller byta till konturform, eller få det att se ut som ett schematiskt elektriskt kopplingsschema, eller välja något som kallas ett järnvägsdiagram, en sorts flödesschemanotation härledd från gammaldags tågkartor . Varje vy är en översättning av det underliggande trädet – som du också kan granska och redigera.

Intentional Softwares arbete framkallar två huvudlinjer av kritik. Vissa teoretiskt sinnade skeptiker säger att Simonyis mål att fånga datoranvändares avsikter är osannolikt. Hur representerar du avsikt? frågar datavetaren Jaron Lanier. Så snart vi vet hur hjärnan lagrar information, kanske vi kan representera avsikt. För mig verkar det bara som en fantasi. Ett annat argument, vanligt bland programmerare, är mer praktiskt. Många programmerare älskar sina textbaserade redigerare och misstroende verktyg som distanserar dem från råkod. När det gäller grafiska programmeringsspråk som Visual Basic och de integrerade utvecklingsmiljöerna (IDE) som automatiserar rutinprogrammeringsuppgifter, betraktar de dem med nedlåtenhet: sådana verktyg, säger de, tvingar fram sina egna sätt att göra saker på, begränsar kreativiteten och håller programmerare från att kod som de förr eller senare måste konfrontera. (För att förstå varför programmerare är så försiktiga, se The Law of Leaky Abstractions ) Skeptiska programmerare tittar på Intentional Software och ser möjligheten till ännu en IDE. För dem som tror att riktiga programmerare skriver text är avsiktlig programmering varken särskilt originell eller mycket eftertraktad.

Men för det mesta finns det förvånansvärt lite diskussion om Intentional Software i Internets myllrande kodarforum. Delvis beror det på att så få har sett dess programvara. Intentionals arbete har fortskridit med viss sekretess.

När han startade Intentional Software samarbetade Simonyi med en professor vid University of British Columbia vid namn Gregor Kiczales. Simonyi beundrade Kiczales arbete med aspektorienterad programmering – ett sätt att organisera och modifiera kod enligt tvärgående problem som liknar avsiktlig programmering. Kiczales, en annan veteran från PARC, har ägnat sin karriär åt att arbeta på sätt att få koden att se ut som designen. Kiczales såg att gå med Simonyi som en chans att främja det målet. Men Kiczales litade på öppen källkodsutveckling, där Simonyi inte gjorde det. Microsoft-stilen med stängda butiker kändes helt enkelt inte organisk för Kiczales. Jag skulle ha gjort det på Java, säger han. Den första releasen skulle ha varit om sex månader. Oenigheten var vänlig men oförsonlig, säger båda männen, och snart hade Kiczales lämnat.

För närvarande, skyddad av Simonyis rikedom, har Intentional Software inget måldatum eller leveransdeadline. Men en av dess två huvudkunder säger sig vara nära att distribuera avsiktliga verktyg. Capgemini – ett Parisbaserat internationellt IT-tjänst- och konsultföretag som betjänar stora företag och vars CTO, Andy Mulholland, är en bekant till Simonyi – började arbeta med Intentional i mars förra året och överväger att använda Intentionals system för projekt inom den europeiska pensionsbranschen. Fältets mycket komplexa regler, sammanflätade med komplex affärsdomänstruktur, gör att Simonyis tillvägagångssätt ser attraktivt ut, säger Henk Kolk, Capgeminis tekniska chef för finansiella tjänster, som leder företagets arbete med Intentional.

Grundkontroll

Simonyis fascination för rymden har varit livslång. Som 13-åring vann han en tävling om att bli Ungerns juniorastronaut och reste till Moskva för att träffa en kosmonaut. Som nyanställd på Microsoft 1981, övertygade han medgrundaren Paul Allen att spela hooky från att utveckla IBM PC:s nya operativsystem och flyga till Florida för att se rymdfärjans första flygning.

Simonyis kommande blastoff erbjuder honom en helcirkelåterförening med sovjettidens teknologi som satte hans livs kurs. Han har tränat i flera månader vid Rysslands Yuri Gagarin Cosmonaut Training Center i Star City, bemästrat detaljerna i rymddräkter och rymdtoaletter och lärt sig ryska.

Rymdresan kommer att bekräfta Simonyis status som den mycket osannolika saken: en kändisprogrammerare. Han har två jetplan och ett pilotcertifikat för att flyga dem. Han dyker upp i tabloiderna som den frekventa följeslagaren till hemmakningens översteprästinna, Martha Stewart. Han har byggt en 233 fot lång yacht med ett däck med glasväggar omslutande. Han har finansierat en Oxford-professur åt sin vän Richard Dawkins, den darwinistiska teoretikern.

Inget av detta kommer naturligtvis att göra någon skillnad i resultatet av Simonyis strävan att lindra de kroniska problemen inom mjukvaruområdet. Det räcker inte att vara en bra programmerare, sa Simonyi en gång till Michael Hiltzik, författare till PARCs historia. Du måste hitta ett stort problem. Avsiktlig kanske aldrig håller sina stora löften. Men ingen kan anklaga Simonyi för att ha valt ett för blygsamt problem.

Hans hem nuförtiden är en herrgård vid Lake Washington, längs stranden från Bill Gates hus, med ett konstgalleri, en inglasad pool, en heliport, ett datorlabb med magnetiskt fodrade väggar och en svarv och borrpress i källare (för att uppfylla dessa Erector Set-begär). Huset kostade 10 miljoner dollar att bygga: det lutar i sju graders vinkel och ser ut som om en lätt jordbävning träffade det, enligt New York Times författaren Patricia Leigh Brown, som förundrades över dess hermetiskt tillslutna, matematiska precision och fann den så stor att en besökare kan känna sig som en ensam asteroid som skramlar runt solsystemet.

[Bara] Charles skulle bygga ett 20 000 kvadratmeter stort hem med ett sovrum, sa Simonyis avhandlingsrådgivare och PARC-kollega Butler Lampson en gång. Det ensamma sovrummet har ett cockpitliknande kontrollcenter som låter Simonyi justera alla sina system – uppvärmning, underhållning, telefon, belysning och vattning – till hans belåtenhet. Som en ubåt, förklarade han för Brown. De måste alla vara gröna innan du sänker dig. Det finns också en svängbar säng som Simonyi kan använda för att finjustera sin utsikt – ut över sjön; eller över till Seattles skyline, med dess fält av kontorsarbetare som brottas med sina dokument och kalkylblad; eller upp på den stjärnklara natthimlen, dit hans senaste resa snart tar honom.

Scott Rosenberg är vice vd för specialprojekt på Salon.com. Han är författare till Drömma i kod.

Avsiktlig programmering förklaras
Simonyi och företaget är banbrytande för en tryckknappsstrategi för programmering.

[ Klicka här för ett diagram över Simonyis planerade tillvägagångssätt]

Shane Clifford, en utvecklare på Intentional Software, berättar denna fabel.

En gång fanns det en by med fyra parker, underhållna av fyra konkurrenskraftiga grannskapsföreningar. Den första föreningen bestämde sig för att piffa upp sin park med en ny bänk. Den begärde in förslag från tre av världens ledande bänktillverkare. Ingen av designen fick en majoritet av grannarnas röster, så föreningen valde den mest populära designen. Processen var demokratisk – men till slut var de flesta missnöjda med den nya bänken.

Den andra föreningen beslutade att den ville ha en egen bänk, men en som alla gillade. Den hittade en tillverkare som byggde skräddarsydda bänkar från mix-and-match-delar. Men träsitsen som medlemmarna gillade fick inte rätt längd, och den dekorativa ryggen fungerade inte med de gröna benen de gillade. Så de kompromissade med delar som fungerade tillsammans. Grannarna var stolta över den färdiga bänken, men ingen satt på den särskilt ofta.

Medlemmarna i den tredje föreningen såg hur mycket pengar de två första hade lagt ut och bestämde sig för att de kunde göra bättre ifrån sig. Hantverkarna i gruppen bad alla om förslag och till slut byggde de en enkel, elegant bänk som alla var överens om var den finaste i byn. Tyvärr vinglade det farligt.

Den fjärde föreningen ville också ha en bänk, men den ville inte upprepa de andra gruppernas misstag. Grannarna vände sig till en föga känd bänkmakare som annonserade om en ny bänktillverkningsupplevelse. Bänkmakaren kom med en lastbil med flak lastad med konstiga maskiner. Han började ställa frågor som Vad är den här bänkens viktigaste egenskap? Vilken är den näst viktigaste funktionen? Vilka material gillar du? Vilken är din favoritform för bänkens fötter?

Efter varje svar skulle bänkmakaren vrida på några rattar på sina maskiner och en ny bild av den pågående bänken skulle dyka upp på en stor skärm. Ibland stämde inte bilden helt, så grannarna backade och svarade på frågorna annorlunda. Efter 50 frågor tryckte bänkmakaren på en stor knapp. Maskinerna nynnade en stund och sög sedan en vacker bänk som matchade den slutliga bilden på skärmen. Alla var glada över att ha fått möjlighet att bidra och många satt på bänken varje dag.

För att få en bänk som gör alla nöjda måste du bygga en automatisk bänktillverkningsmaskin; hjälpa kunder att definiera sina exakta förhoppningar för sin bänk; översätt dessa förhoppningar till instruktioner som bänkmaskinen förstår; och tryck sedan på knappen Skapa. Kunder får nära kontroll över resultatet, och bänktillverkare, befriade från de repetitiva och mekaniska delarna av bänktillverkning, får ägna mer tid åt att använda sina färdigheter för att mata in sina kunders önskemål i maskinen.

Ersätt mjukvara för bänkar, säger Clifford, och du kommer att förstå avsiktlig programmering – så kallad för att programmerare är fokuserade på hur deras kunder avser att ett program ska fungera, och inte på röran av kod som krävs för att implementera dessa avsikter.

Avsiktlig programmering liknar i konceptet vad-du-ser-är-vad-du-får ordbehandlingsprogram, som Charles Simonyi, Cliffords chef, var pionjär. Wysiwyg textredigerare låter datoranvändare manipulera ett dokuments utseende på skärmen utan att tvinga dem att bemästra den underliggande koden. På samma sätt uppmuntrar avsiktlig programmering datoranvändare att uttrycka sina behov på sitt eget bekanta språk, och visar dem sedan begripliga vyer eller projektioner av den framväxande designen innan den körbara koden sätts ihop. Det är inte den enda programmeringsfilosofin som förlitar sig på sådana grafiska representationer; Unified Modeling Language (UML), utvecklat i mitten av 1990-talet på Rational Software (nu en del av IBM), använder också grafiska diagram för att representera ett programs funktion, struktur och beteende. Men UML-diagram kan inte omvandlas till färdig programvara, vilket är Simonyis dröm för avsiktlig programmering.

Hur hoppas Intentional Software kunna förverkliga den drömmen? Låt oss lägga in Simonyis plan i sitt eget diagram (klicka här). Processen för att bygga mjukvara börjar naturligtvis med kunden: varje organisation med en informationsintensiv uppgift som behöver automatiseras. Simonyi kallar personerna på dessa organisationer för domänexperter; de, inte programmerarna, vet vad programmet ska göra.

Med programmerarnas hjälp listar domänexperterna alla begrepp och definitioner som programvaran måste omfatta. Alla dessa definitioner går in i en databas som Simonyi kallar domänschemat.

Liksom bänktillverkaren vrider på sina rattar, införlivar programmerarna sedan definitionerna i domänschemat i domänkoden – en representation på hög nivå av programvarans funktioner, uttryckt i ett domänspecifikt språk, eller DSL, som kan skräddarsys för att passa branschen i fråga. Men även om DSL kan variera, lagras varje åtgärd som programvaran måste utföra i ett enhetligt format, ett avsiktligt träd. Avsiktliga träd har fördelen av att vara visuellt enkla men logiskt heltäckande, vilket innebär att de kan manipuleras, revideras och projiceras eller regnvisas efter behag.

Till exempel beräkningen som representeras av den enkla programsatsen

returnera a = b / (c +1) ;

representeras av följande avsiktliga träd:

Lämna tillbaka
(

Tilldela
(

till,
Div
(

b,
Mer
(

c,
ett

)

)

)

)

När den väl är kodad i trädform kan beräkningen projiceras på många andra sätt som kanske är mer bekanta för domänexperter, som t.ex.

b
returnera a = ——- ;
c + 1

Som sin första konkreta uppgift arbetar Simonyi och hans kollegor på Intentional Software med att bygga ett specialverktyg, Domain Workbench, designat för att hantera dessa projektioner. Både domänexperterna och programmerarna använder Domain Workbench för att redigera och omredigera projektionerna tills de ser rätt ut. Därefter matas domänkoden in i en generator – motsvarigheten till bänktillverkarens lastbil med maskiner – som tar fram målkod på ett språk som C++ eller Java som andra datorer kan förstå, kompilera och köra.

När målkoden väl har genererats kan den inte omvandlas till domänkod igen. I det avseendet är generatorn som ett krypteringsprogram som irreversibelt omvandlar klartext till chiffertext.

Men – och detta är kanske avsiktlig programmerings största fördel – det är lätt att skrota gammal målkod och generera förbättrad kod från början. Revidera helt enkelt domänkoden med Domain Workbenchs Wysiwyg-redigerare och kör den genom generatorn igen. I de flesta äldre tillvägagångssätt kan även den minsta förändring i de ursprungliga antagandena kräva att programmerare sållar igenom miljontals rader kod och uppdaterar varje instans av ett koncept, definition eller beräkning för hand.

Generatorn förblir den största svarta lådan i Intentional Softwares process. I tekniska publikationer kommer allt företaget att säga om denna mystiska komponent att prototypen skrivs i Microsofts programmeringsspråk C# och att den kommer åt domänschemat och domänkoden med hjälp av ett applikationsprogrammeringsgränssnitt, ett sätt för två program att kommunicera, som är inbyggt i Domain Workbench. Men att skriva själva generatorn, eller skräddarsy den för en specifik bransch eller DSL, kommer att vara en stor del av kostnaden för alla avsiktliga programmeringsprojekt.

Wysiwyg gav miljontals fler användare möjlighet att skriva snygga dokument, skriver Simonyi på företagets blogg. Det är dags att göra samma sak för programanvändare.

Av Wade Roush

Lagen om läckande abstraktioner
Utdrag ur Drömmer i kod: två dussin programmerare, tre år, 4 732 buggar och en strävan efter transcendent programvara , av Scott Rosenberg, utges av
Crown Books i januari 2007.

Programvara, vi har sett, är en sak av lager, där varje lager översätter information och processer för lagren över och under. Längst ner i denna bunt av lager sitter maskinen med sina rena binära ettor och nollor. Överst är människorna som bygger och använder dessa lager. Simonyis Intentional Software, i grunden, föreslår helt enkelt ytterligare ett lager mellan maskinen och oss.

Programvarans lager är dess väsen, och det är de som driver framsteg på området, men de har en ihållande svaghet. De läcker. Till exempel är användare av många versioner av Microsoft Windows trötta bekanta med fenomenet Blue Screen of Death. Du arbetar iväg inuti något program som en webbläsare eller Microsoft Word, och plötsligt, från ingenstans, blir din skärm blå och du ser lite vit text på den som lyder ungefär så här:

Ett dödligt undantag 0E har inträffat vid
0167: BFF9DFFF.

Den aktuella ansökan kommer att avslutas.

Genom att se skärmens monokroma utseende och det blockiga typsnittet kan veterananvändare känna att de har kastats bakåt i datortid. Vissa kanske till och med förstår att meddelandets alarmerande hänvisning till ett dödligt undantag betyder att programmet har stött på en bugg som det inte kan återhämta sig från och har kraschat, eller att de kryptiska hexadecimala (bas 16) siffrorna beskriver den exakta platsen i datorns minne där kraschen tog plats. Ingen av informationen är av något värde för de flesta användare. Det bekväma, välbekanta gränssnittet för programmet de använde har försvunnit; ett djupare lager av abstraktion – i det här fallet Windows-skalet eller kontrollprogrammet på lägre nivå – har brutit ut som ett lutande lager av berggrund som sticker upp genom nyare geologiska skikt och in i solljuset.

(Förvirrande som Blue Screen of Death är, det representerade faktiskt ett stort framsteg från tidigare versioner av Windows eftersom det ibland tillåter användaren att stänga av det felande programmet och fortsätta arbeta. Innan den blå skärmen kraschade ett Windows-program nästan alltid tog ner hela maskinen och alla dess program.)

I en uppsats med titeln The Law of Leaky Abstractions skrev Joel Spolsky: Alla icke-triviala abstraktioner, till viss del, är läckande. Abstraktioner misslyckas. Ibland lite, ibland mycket. Det finns läckage. Saker och ting går fel. För användare betyder detta att din dator ibland beter sig på bisarra, förvirrande sätt, och ibland kommer du att vilja, som Mitch Kapor sa i sin Programvarudesignmanifest , kasta ut den genom fönstret. För programmerare betyder det att nya verktyg och idéer som samlar ihop lite datorkomplexitet på låg nivå och paketerar den i en ny, lättare att manipulera abstraktion är fantastiska, men bara tills de går sönder. Sedan läcker all den dolda komplexiteten tillbaka in i deras arbete. I teorin tillåter det praktiska nya topplagret programmerare att glömma röran under det; i praktiken måste programmeraren fortfarande förstå den röran, för så småningom kommer han att landa i den. Spolsky skrev:

Abstraktioner förenklar egentligen inte våra liv så mycket som de var menade att göra. … Lagen om läckande abstraktioner innebär att när någon kommer med ett tjusigt nytt kodgenereringsverktyg som ska göra oss alla så effektiva, hör du många människor som säger: Lär dig hur man gör det manuellt först, sedan använd Wizzy-verktyget för att spara tid. Kodgenereringsverktyg som låtsas abstrahera ut något, som alla abstraktioner, läcker, och det enda sättet att hantera läckorna kompetent är att lära sig om hur abstraktionerna fungerar och vad de abstraherar. Så abstraktionerna sparar oss tid att arbeta, men de sparar oss inte tid att lära. … Och allt detta betyder att paradoxalt nog, även när vi har programmeringsverktyg på högre och högre nivå med bättre och bättre abstraktioner, blir det svårare och svårare att bli en skicklig programmerare.

Så även om de abstraktioner vi har skapat genom åren tillåter oss att hantera nya ordningar av komplexitet i mjukvaruutveckling som vi inte behövde hantera för tio eller femton år sedan, och även om dessa verktyg låter oss få mycket av arbete som gjorts otroligt snabbt, skrev Spolsky, plötsligt en dag måste vi ta reda på ett problem där abstraktionen läckte, och det tar två veckor.

The Law of Leaky Abstractions förklarar varför så många programmerare jag har pratat med himlar skeptiskt med ögonen när de hör beskrivningar av avsiktlig programmering eller andra liknande idéer för att överskrida mjukvarans komplexitet. Det är inte så att de inte skulle välkomna att ta ytterligare ett steg uppför abstraktionsstegen; men de fruktar att oavsett hur högt de klättrar på den stegen, kommer de alltid att behöva springa upp och ner för den mer än de skulle vilja – och ju högre den blir desto längre blir resan.

Dölj