Alt hvad du kan gøre, kan jeg gøre Meta

Den 9. april, ved en fjern affyringsrampe på Kasakhstans sletter, vil en jordkontroller afslutte sin nedtælling; en Soyuz-raket vil affyre; og Charles Simonyi – Microsofts tidligere chefarkitekt, vejledningsgeniet bag dets mest berømte applikationer, opfinderen af ​​metoden til at skrive kode, som virksomhedens programmører har brugt i 25 år, og nu fortaleren for et ambitiøst projekt til omprogrammering af software – vil begynde hans opstigning ud i rummet.

Charles Simonyi præsident og CEO for Intentional Software.

Tilpas i en russisk rumdragt og mærke fire G'ere presse ham ned i en formtilpasset støbt sædeforing, vil den 58-årige milliardær blive den femte rumturist, der besøger den internationale rumstation. Rejsen, som vil koste Simonyi omkring 20 millioner dollars, vil opfylde hans drøm om at blive en nørd i rummet (for at låne et navn, han valgte til hjemmesiden, der dokumenterer hans udenjordiske eventyr: www.nerdinspace.com ). Det vil også give ham en mulighed for at se vores planet fra oven og ud.

Dette har altid været Simonyis foretrukne udsigtspunkt. I en karriere, der strækker sig over fire årtier, har han, hver gang han har konfronteret et eller andet uløseligt problem i software eller liv, forsøgt at løse det ved at træde udenfor eller over det. Han har endda et navn til sin yndlingsgambit: han kalder det at gå meta. I sin ungdom i 1960'ernes Ungarn lærte han det grundlæggende i at computere på en forældet sovjetisk mainframe drevet af vakuumrør, og udviklede derefter sin egen flugt til Vesten. I 1970'erne, på Xerox' legendariske Palo Alto Research Center (PARC), som en del af holdet, der opfandt personlig computer, skrev Simonyi den første moderne applikation: et tekstbehandlingsprogram, der forviste de komplekse koder, der derefter blev brugt til at mærke tekst og viste et dokument som det ville se ud på papiret. Hvad enten han er i sin doktorafhandling ved Stanford University om en metaprogrammeringstilgang til at øge programmørens produktivitet, hans karriere hos Microsoft, der organiserer legioner af softwareudviklere og lærer dem at strukturere deres kode, eller hans planlagte rejse ind i jordens kredsløb dette forår, der bevæger sig ud over etablerede måder. at gøre ting har altid været Simonyis metode. Nu planlægger han, hvad han håber vil være hans mest hvælvede meta-bevægelse af alle. Simonyi tror på, at han kan løse et væld af genstridige problemer, der altid har plaget computere, ved at tilbyde alle, der bruger dem, og de kodere, der programmerer dem, et højere-ordens syn på software.

Bill Gates kalder Simonyi for en af ​​tidens store programmører. Faktisk er Simonyi uden tvivl den mest succesfuld koder i verden, målt i form af økonomisk belønning og antallet af mennesker, der bruger hans kreationer. (Andre fejrede programmør-milliardærer, såsom Larry Ellison og Bill Gates selv, tjente deres penge og navne på at grundlægge og styre teknologiforetagender.) Simonyi kunne nemt vælge at bruge resten af ​​sit liv på at give filantropiske satsninger, flyve fly eller sejle i sit liv. yacht. I stedet, siger han, programmerer han sandsynligvis hårdere end nogensinde før. Han er besat af et projekt, som han har forfulgt i halvandet årti, og som for fire år siden bar ham lige ud af Microsofts døre. Han er stolt af sit fag. Men han er også hjemsøgt af tanken om, hvad programmører skal slås med, hver gang de sætter sig til at kode. Han spørger: Hvorfor er det så svært at skabe god software?

Multimedier

• Yderligere billeder af Simonyi

Napoleons kode

Vores civilisation kører på software, siger Bjarne Stroustrup, opfinderen af ​​programmeringssproget C++ (se Problemet med programmering) . Men selve softwaren kører ikke særlig godt. Uanset hvor du ser hen, er software over budget, forsinket, usikker, upålidelig og svær at bruge. Hver gang en organisation forsøger at introducere et nyt system eller opgradere et gammelt, tager det en kolossal risiko; i dag er store informationsteknologiske projekter teknologiske tjæregrave, der immobiliserer institutioner. Undersøgelser rapporterer jævnligt, at to tredjedele af sådanne projekter støder på store forsinkelser, betydelige omkostningsoverskridelser eller begge dele. Den amerikanske regering har fundet det næsten umuligt at indføre eller opgradere softwaresystemer i stor skala: årtier lange indsatser hos Federal Aviation Administration og FBI er kollapset i kaos. Virksomhederne har ikke klaret sig bedre. For at give et enkelt eksempel, drømte McDonald's-chefer om et webbaseret administrationssystem, de kaldte Innovate, som kunne spore realtidsstrømmen af ​​burgere, pommes frites og kyllingenuggets i hver eneste af deres restauranter rundt om i verden. Da de gav op og annullerede projektet, var de nødt til at afskrive $170 millioner af dets anslåede $1 milliard samlede omkostninger.

Sådanne fiaskoer lægger op. Hvert år, ifølge en undersøgelse fra 2002 fra National Institute of Standards and Technology, koster softwarefejl 59,5 milliarder dollars. Men prisen på dårlig software kan også måles i menneskelig elendighed – og endda i tabte liv. Under Golfkrigen i 1991 skød et Patriot-missilbatteri ikke mod en indkommende Scud på grund af defekt software; det direkte angreb på en barak dræbte 28 amerikanske soldater.

Det sidste halve århundredes databehandling har set vidunderlige fremskridt. Programmører har forladt hulkort og teletyper. De har givet os en computer på alle skriveborde, værktøjer til arbejdet, legetøj til leg og et netværk, der forbinder hjem og virksomheder for at danne en myldrende global pulje af information og underholdning. Dette fremskridt er blevet drevet af den eksponentielle kurve af Moores lov, Intel-grundlægger Gordon Moores forudsigelse om, at mikrochips' effekt ville fordobles (eller deres omkostninger ville halveres) hvert til hvert andet år. Men selvom Moores lov har gjort hvert års nye computere hurtigere og billigere, er fleksibiliteten og anvendeligheden af ​​vores computersystemer blevet begrænset af den langsommere, ujævne udvikling af software. En formulering af dette problem er kendt som Wirths lov, efter programmeringsekspert Niklaus Wirth: Software bliver langsommere hurtigere end hardware bliver hurtigere.

Simonyi deler meget af den almindelige utilfredshed med software. Software, som vi kender det, er flaskehalsen på det digitale overflødighedshorn, siger han. Det tager enorme ressourcer i talent og tid. Det er skuffende og svært at ændre. Det blokerer for innovation i mange organisationer.

Simonyis ambition er at fjerne denne softwareflaskehals – karakteristisk ved at gå meta. Han har udviklet en tilgang, han kalder forsætlig programmering (eller for nylig, forsætlig software), som han håber vil vælte programmering. Hvis Simonyi har sin vilje, vil programmører holde op med at forsøge at styre deres kunders behov. I stedet vil de for hvert problem, de bliver bedt om at tackle – hvad enten det er lagersporing eller missilvejledning – skabe generiske værktøjer, som computerbrugerne selv kan ændre for at guide softwarens fremtidige udvikling.

På en grå eftermiddag i oktober sidste år satte jeg mig ned med Simonyi i Bellevue, WA, foran to tilstødende skærme på hans kontor hos Intentional Software, firmaet han grundlagde efter at han forlod Microsoft i 2002 for at udvikle og kommercialisere sin store idé. Simonyi kørte mig gennem en præsentation, han var ved at forberede til en kommende konference; han brugte Microsoft Office PowerPoint-slides til at skitsere sin vision for det foreslåede store spring fremad inden for programmering. Han var i gang med at flytte et dias rundt, da applikationen lige holdt op med at reagere.

I hjørnet af den venstre skærm dukkede et papirklip med goggleøjede op: den vidt udskældte Office Assistant, som Microsoft introducerede i 1997. Simonyi forsøgte at ignorere tegnefilmassistentens anti-fidling, men han blev forhindret. Intet virker, sukkede han. Det er fordi Clippy giver mig noget hjælp.

Jeg var forundret. Du mener, at du ikke har slået Clippy fra? For længe siden havde jeg søgt gennem Offices menuer og tjekket hvilken boks der var påkrævet for at drosle den irriterende antropomorf én gang for alle.

Jeg ved ikke hvordan, indrømmede Simonyi, med et lille grin, der syntes at sige, Ja, jeg ved det, er det ikke ironisk?

Det var. Simonyi brugte år på at lede applikationsteamene hos Microsoft, udviklerne af Word og Excel, hvis produkter bruges hver dag af titusinder af mennesker. Han betragtes bredt som faderen til Microsoft Word. (Jeg bruger selvfølgelig Word til at skrive disse sætninger.) Kunne Charles Simonyi have mødt sin match i Clippy?

Simonyi stirrede på sin modstander, som om han var låst i telepatisk kamp. Så vendte han sig mod mig med blå øjne skinnende. Jeg har brug for en hjælper: en Super-Clippy til at vise mig, hvor jeg skal slukke ham! Simonyi længtes efter en meta-Clippy.

I 2004 foreslog Simonyi sin egen lov: Alt, der kan gøres, kunne gøres 'meta.' I sine yngre dage – da han storartet havde kaldt et projekt Simonyi's Infinitely Glorious Network – ville han sandsynligvis have været mere arrogant: Alt hvad du kan gør, jeg kan gøre meta! Men ligesom mange vidunderbørn, der har gjort det godt og ældet godt, har Simonyi lært at skære sin kækhed med strejf af ydmyghed og ynde. For et årti siden beskrev han sig selv som en fyr med en udenlandsk accent. Han foretrækker sorte rullekrave og dobbeltradede blazere. Med sin oprejste kropsholdning og firkantede ansigt, et chok af mørkt hår kæmmet frem over panden, siges han ofte at ligne en Napoleon med større knogler.

Forsætlig software er en storslået ordning på et felt, hvor store ordninger sjældent har virket. Enhver tidligere innovation introduceret som en komplet løsning på softwarens problemer er endt med kun at give beskedne, trinvise forbedringer. Men Simonyi er fyldt med selvtillid fra en selvfremstillet immigrant, der altid har haft et fast greb om sine egne støvlestropper. På et foto, der hænger over hans skrivebord, står han i Det Hvide Hus under et portræt af Ronald Reagan. Hans brede grin afspejler præsidentens. Billedteksten lyder De to optimister.

Kontorerne i Simonyis nye firma indtager en suite i en slank glasskyskraber, og hvis du læner dig ind ad vinduet og kigger ned, kan du se taget på den squate, ubestemmelige hvide bygning, der husede hans første kontor hos Microsoft, tilbage i 1981. ( Det er en bank nu.) Siden da er Microsoft vokset til ukendelighed. Softwareindustrien har forvandlet verden. Så hvorfor skulle Simonyi sætte sig for at omskrive alle sine regler? Problemet er så stort, at det ser ud til at være en del af tingenes faste orden. Simonyis foreslåede løsning kan tage årtier at fuldføre, og hans kritikere er intenst skeptiske. Ingen beder ham om at efterlade de kendte rutiner for programmering og tage af sted til en ny verden. Men sådanne migrationer har tidligere betalt sig for ham.

Maskinens sprog

Simonyi blev født i Budapest i 1948. Som søn af en fysikprofessor blev han som 15-årig forelsket i sin første computer – en mammut russisk Ural II i Ungarns statistiske kontor. I 1960'erne ville Ural, som modtog sine instruktioner gennem nøgler i kasse-stil og havde et rum fuld af vakuumrør til at udføre beregninger, allerede have været et levn andre steder i verden. Men Ungarns kommunistiske ledere forsøgte at bruge den sovjetiske forkastelse til at optimere tidsplaner for jernbaner og lastbiler. Ural var ikke klar til opgaven: der var ingen måde at indtaste realtidsdata om forsendelser på. Det var fuldstændig håbløst, husker Simonyi. Det kunne være gjort meget nemt ved udbud og efterspørgsel. Det var desværre politisk ukorrekt.

Men Simonyi var ligeglad. Jeg elskede den computer, siger han, selvom den var ubrugelig. Som barn havde han bygget en Erector Set-bil med en fire-trins gearkasse – ikke så meget fordi han ville lege med den, men bare for at forstå, hvordan den fungerede. En tidligere elev af sin far fandt Simonyi et job som Urals natsygeplejerske. Fordi maskinen blæste et rør ud, hver gang den blev slukket og tændt, foretrak Statistikkontoret at lade den køre hele natten. Fra solnedgang til daggry var mainframen således helt Simonyis; han havde en personlig computer før sådanne ting fandtes. Han lærte at programmere det ved at skrive smarte, men ubrugelige rutiner til at generere magiske firkanter – numeriske arrays, hvor summen af ​​rækkerne, kolonnerne og diagonalerne alle matcher.

Programmører andre steder i verden havde allerede opfundet en Babel af programmeringssprog – Fortran, Cobol, Lisp (et sagnomspundne sprog: se Ancient Text, s. 20) og så videre – for at lette deres arbejde, der dengang som nu bestod i omhyggeligt at skrive udførlige sæt instruktioner, som computere skal udføre. På disse sprog tog instruktionerne form af tekstlinjer, der blev indtastet på tastaturer og ofte gemt på hulkort. Denne kildekode blev derefter kompileret eller oversat til maskinkode – den en s og 0 s, som en digital computer kunne forstå. Metoden forbliver stort set uændret i dag, selvom de fleste programmører nu bruger programmeringsværktøjer, der kører på almindelige pc'er. Men på Ural lærte Simonyi at programmere på et mere primitivt niveau, møjsommeligt at punche maskinsprogets opkoder, specificere, instruktion for instruktion, sekvenserne af hukommelseshentninger, tilføjelser, hukommelseslagre og hop, som computerens processor skulle følge at udføre selv den mest trivielle operation. Det var (som Simonyi fortalte forfatteren Steve Lohr i bogen fra 2001 Gå til ) Stenalderprogrammering. Simonyi husker stadig koderne. Toogtyve er JUMP, siger han i dag. Det er brændt ind i min ROM.

Ungarn i 1960'erne, der stadig viger tilbage fra den sovjetiske undertrykkelse af dets oprør i 1956, var ikke et sted for en ambitiøs ung mand med smag for problemløsning. Som 17-årig kom Simonyi i praktik hos en dansk computervirksomhed ved at vise nogle af dets programmører eksempler på hans håndkodede Ural-programmer. De ungarske myndigheder forventede, at Simonyi ville vende tilbage; han havde allerede vundet en eftertragtet universitetsplads. I stedet flygtede han med sin fars opmuntring til USA.

Et anbefalingsbrev fra den danske programmeringsekspert Peter Naur hjalp ham med at vinde adgang til University of California, Berkeley. Han betalte regningerne med et job på Berkeleys computercenter, hvor han fangede opmærksomheden fra et fakultetsmedlem ved navn Butler Lampson. Lampson var en af ​​lederne af U.S. Defense Advanced Research Projects Agencys Project Genie – et eksperiment i tidsdelingscomputersystemer, hvor flere brugere, der sad ved terminaler, kunne dele en enkelt computers hjernetid. Da Project Genie-skaberne startede et firma kaldet Berkeley Computer Corporation (BCC), hvis formål var at bygge en maskine, der ville kommercialisere deres arbejde, rekrutterede Lampson Simonyi.

Hos BCC ville Simonyi fejlsøge virksomhedens skrøbelige prototype natten over i samarbejde med systemdesigneren Chuck Thacker. En aften dukkede Simonyi op i et gennemsigtigt sort outfit – en slags hippieting fra en af ​​butikkerne på Telegraph Avenue, siger han. I dag kan han ikke huske præcis hvorfor – måske kommer han fra en fest? Fejlretningen gik særligt godt den aften, og tøjet blev en heldækkende charme - Simonyis fejlretningsdragt.

BCC gik i vejret efter kun et par år, men Lampson, Thacker og en stor del af BCC-teamet migrerede til Xerox PARC. Simonyi – dengang blot en tilfældig ungarsk studerende uden grønt kort, som han siger nu – sluttede sig til dem i 1972 og arbejdede hos Xerox, mens han samtidig forfulgte sin Stanford-doktorgrad. Bob Taylor, der havde tilsyn med PARC's Computer Science Lab under en del af den legendariske æra, siger, at Simonyis kreativitet skilte sig ud selv i laboratoriets berømte publikum: Han kunne bare forestille sig måder at udtrykke kode og ideer på, der satte ham ud af hitlisterne.

Det var en hæsblæsende tid. Teamet af visionære ingeniører skabte en række innovationer, der ville forme det næste kvarte århundrede af pc-æraen: den grafiske brugergrænseflade, netværk (Ethernet), laserprinteren, objektorienteret programmering (Smalltalk), bærbar computer (den Dynabook) og mere. Disse gennembrud kom alle sammen på en prototypisk personlig computer kaldet Alto.

Alto var en fantastisk opfindelse, men det var ikke klart, hvad du kunne gøre med den, før Simonyi og hans kolleger skabte dens bedst kendte applikation: et tekstbehandlingsprogram kaldet Bravo, hvis skærmvisning af typen matchede, hvad systemet ville udsende. til den nye laserprinter. Eksisterende tekstbehandlere havde omfattende kodesystemer til formatering af tekst på skærmen (enhver, der brugte WordPerfect på en pc i 1980'erne, vil huske dets indlejrede koder); Bravo lader dig glemme koderne, manipulere designet af et dokument direkte og straks overvære ændringerne. En besøgende Citibank-direktør kiggede på en demo og citerede en signaturlinje af komikeren Flip Wilsons frække karakter Geraldine: What you see is what you get! Navnet (reduceret til akronymet Wysiwyg og udtalt wizzywig ) sidde fast. Pludselig havde Bravo brugere: slægtninge og venner til PARC-forskere begyndte at bede om at bruge det til at udskrive skolenyhedsbreve og formatere akademiske artikler. Lampsons kone udskrev sit speciale ved hjælp af systemet, og da det var tid for Simonyi at udskrive sin, gjorde han det samme.

Abstraktionsniveauer

Wysiwyg er et eksempel på et abstraktionslag – et værktøj på højere niveau, der tillader computerbrugere at ignorere noget kompleksitet på lavere niveau. Programmører bruger abstraktioner hele tiden. Tekstkoden skrevet i et programmeringssprog er en abstraktion af den maskinkode, som en computer faktisk forstår. Et webdomænenavn er en abstraktion af en servers numeriske internetprotokoladresse.

Men de fleste abstraktionslag i computersystemer er mindre synlige og mere mystiske end Wysiwyg. Lige siden programmører holdt op med at huske de opkoder, som Simonyi brugte i sin ungdom, har de lagt nye abstraktioner oven på ældre abstraktioner. Hver generation af programmører bruger sin tids programmeringssprog og værktøjer til at bygge den næste generations programmer. Lag af abstraktion har akkumuleret som geologiske lag. Beskeder suser konstant op fra din maskines binære klippe og ned igen, hvilket gør det muligt for et museklik at udføre sin funktion. Dit museklik udløser noget kode i styresystemet, som sender en besked til tekstbehandlingsprogrammet, som instruerer styresystemet om at gemme din fil på en harddisk. Men den tilsyneladende simple proces er kun mulig på grund af mange, mange lag af abstraktion.

Softwarens historie er historien om disse lag, som hver af dem løfter programmører længere fra det binære, og efterlader dem bedre i stand til at lokke computere til at udføre nyttige opgaver. Støt og roligt fik programmører mere magt. Men de tog også fat på stadig mere ambitiøse problemer. Programmer voksede i størrelse, og programmører begyndte at fare vild i virvar af det, de kaldte spaghettikode, som viste sig umuligt at optrevle og reparere. Således blev store softwareprojekter episke frustration og forsinkelser. Programledere stod over for forretningsproblemer som: Hvordan planlægger du realistisk et projekt? Hvordan forbedrer du den enkeltes produktivitet? Hvordan koordinerer du komplekst arbejde på tværs af et stort team? Hvert af disse spørgsmål viste sig at være overraskende vanskeligt at besvare.

Vanskeligheden ved at koordinere et teams arbejde inspirerede softwareingeniørens mest berømte diktum, kendt som Brooks's lov: Tilføjelse af arbejdskraft til et sent softwareprojekt gør det senere. Frederick P. Brooks Jr. nåede til denne dystre konklusion efter at have ledet IBMs problemfyldte indsats for at skrive software til sine 360 ​​mainframes i 1960'erne. I sin bog fra 1975, Den mytiske man-måned , observerede Brooks, at arbejdet forløber langsommere på større teams på grund af koordineringsomkostninger – den tid, programmører mister ved at holde hinanden orienteret om deres arbejde.

Dette var baggrunden for Simonyis afhandling fra 1977, Meta-Programming: A Software Production Method. Simonyi foreslog en ny tilgang til at optimere produktiviteten, hvor en hovedprogrammør eller meta-programmør designede et produkt og definerede alle dets vilkår og derefter afleverede en plan til teknikere, arbejder-bi-programmører, som ville udføre implementeringen. Simonyi havde til formål at undslippe Brooks's lov ved at forbyde teknikerne at tale med hinanden: al kommunikation skulle passere gennem meta-programmøren. Til sin afhandling testede han ideen ved hjælp af to grupper på to projekter, A og B. Hans despotiske tilgang til programmering fangede aldrig, men det bekymrede ham næppe. Simonyis hovedmål med at forske i sin afhandling var ikke at bevise værdien af ​​hans ideer, men at få Bravo, det nye Wysiwyg-tekstbehandler, skrevet hurtigere. Han kunne ikke overtale PARC-messingerne til at ansætte flere programmører, så han brugte sin afhandling som et underskud for at få hjælp. Bravo selv var projekt B.

Som 1970'erne skred frem, blev Simonyi utålmodig med Xerox' manglende evne til at omdanne PARCs banebrydende forskning til succesfulde produkter. En dag viste en ven ham VisiCalc, det nye regnearksprogram til Apple II. Det begejstrede Simonyi. Her var en anden applikation, som Bravo, der kunne ændre folks liv, men i modsætning til Bravo kørte den på en massemarkedscomputer, som folk havde råd til at købe. PARCs arbejde, indså han, ville aldrig se dagens lys. Han bad sin tidligere PARC-kollega Bob Metcalfe, som forlod laboratoriet i 1979 for at starte 3Com, om at anbefale potentielle chefer i den spæde pc-industri. I spidsen for listen stod Bill Gates.

I 1981 flyttede Simonyi til Seattle for at starte den nye applikationsgruppe hos Microsoft, som indtil da havde solgt programmeringssprog og operativsystemer. Han var 33, men det gjorde ham til en voksen blandt Microsofts unge (Gates var dengang 26 år, Steve Ballmer 25).

Gennem alle årene, hvor Simonyi havde tilsyn med de produkter, der til sidst forenede sig i programpakken kendt som Microsoft Office, fortsatte han med at søge nye effektivitetsgevinster i nye former for programmeringsabstraktioner. Mest bemærkelsesværdigt underviste han generationer af Microsoft-programmører i disciplinen at holde styr på de utallige variabelnavne, der bruges i store programmer. I computerprogrammering repræsenterer variabler information, der kan ændre sig, efterhånden som et program kører. For eksempel vil en onlinebutiks indkøbskurvprogram have variabler, der repræsenterer antallet af varer af hver type, der skal købes, hver vares pris og forsendelsesomkostninger og afgifter. Ved at bruge disse variabler kan en programmør skrive en simpel kodelinje, der multiplicerer mængde med pris, tilføjer forsendelse og afgifter og beregner de samlede omkostninger - som bliver værdien af ​​endnu en variabel.

Et stort program kan have tusindvis af forskellige variabler, som et programmeringsteam skal holde ved lige. At navngive dem omhyggeligt bliver afgørende. I dag har de fleste kode variable navne designet til at formidle mening til de programmører, der vil læse den - navne som NumberOfItems eller ShoppingCartTotal. I Simonyis navngivningsskema, som han havde opfundet til eget brug år før, kommer hvert variabelnavn med et præfiks, der fortæller dig nyttige oplysninger om det, som dets type (heltal, f.eks. eller decimalbrøk eller streng af bogstaver). Nogle systemer begrænser længden af ​​variabelnavne til otte tegn; Simonyi udelod simpelthen vokalerne.

Den resulterende kode var tæt og svær at læse. Simonyis system blev kendt som ungarsk notation, både som en hyldest til dets skabers fødested, og fordi det fik programmer til at se ud som om de var skrevet på et eller andet uudgrundeligt fremmedsprog, ifølge programmeringspioneren Andy Hertzfeld. Ungarsk er bredt forbandet af sine modstandere. Den canadiske Java-ekspert Roedy Green har i spøg kaldt det det taktiske atomvåben i teknikker til sløring af kildekoder. Mozilla-programmøren Alec Flett skrev denne parodi:

prepMen nI vrbLike adjUngarsk! qHvad er kunstThe adjBig nProblem?

Hertzfeld, der skrev om et møde hos Apple med en ungarsk kode skrevet af en kollega, der havde arbejdet med Simonyi hos PARC, sagde, at navnene så ud som om, de var valgt af Supermans fjende fra den 5. dimension, Mr. Mxyzptlk.

Men mens kritikere mener, at ungarsk gør kode ulæselig, er Simonyi stadig stolt af den og anvender den den dag i dag.

Meta-eufori

I begyndelsen af ​​1990'erne havde Microsofts succes gjort Simonyi's formue. (For flere år, Forbes har anslået, at det er 1 milliard dollars.) Men han mærkede stadig træk i uafsluttede forretninger. Softwarens forvirring havde gjort oprettelsen af ​​Office nervepirrende for Microsoft. Men nu, med computere, der er stærkere end Alto'en på hvert skrivebord, og internettet, der forbinder dem, var softwarekrisen alles krise. Simonyi begyndte at tænke, at det var tid til at gå meta igen.

Charles har altid forsøgt at bygge sine systemer på måder, der hæver abstraktionsniveauet, så man kan styre systemets kompleksitet. For kompleksitet er død, siger Chuck Thacker, Simonyis gamle kollega fra BCC og PARC, som leder et forskningsprojekt om computerarkitektur hos Microsoft. Og desværre, i disse dage, resulterer det i et komplekst system, hvis de faciliteter, folk faktisk ønsker. Vi hænger på med fingerspidserne lige nu.

Simonyi flyttede til en stilling hos Microsoft Research og begyndte at definere begrebet forsætlig programmering, eller forkortet IP. Forsætlig programmering ville tilføje et helt nyt lag af abstraktion til praksis med at skrive software. Det ville gøre det muligt for programmører at udtrykke deres hensigter uden at synke ned i mosen af ​​såkaldte implementeringsdetaljer, der altid truede med at sluge dem. Ligesom meta-programmørerne i Simonyi's afhandling, der videregiver instruktioner til arbejder-bi-kodere, ville den forsætlige programmør aflevere spidsarbejdet - men ikke til en yngre kollega. I stedet krævede bevidst programmering en slags kodefabrik kaldet en generator, et program, der tager et sæt af relativt højt niveau kommandoer ind og spytter mere detaljeret arbejdskode ud. Målet var ikke så meget at lette programmeringsarbejdet som at lade programmører rense deres hjerner for trivialiteter, så de rent faktisk kunne være kreative.

Fra sin programmeringsindledning som teenager, der slog opkoder ind i Ural, havde Simonyi klatret op ad abstraktionsstigen. Men han følte, at han ikke var høj nok. På mange måder føltes programmering stadig primitiv. Hvorfor var programmører stadig beklædt med inkompatible programmeringssprogssyntakser? Hvorfor var det så svært at udvide deres foretrukne sprog til nye områder? Hvorfor arbejdede programmører stadig med almindelig tekst, idet de arrangerede et lille antal tegn i lineære strenge, som de havde tidligere? Simonyis Wysiwyg arbejde havde befriet kontorarbejdere til at skabe og redigere komplekse dokumenter. Ingeniører og designere brugte avancerede CAD/CAM-værktøjer til at designe og ændre tegninger til skyskrabere og fly. Hvorfor pillede programmører, troldmændene, der havde gjort alt dette muligt, stadig deres kode ét tegn ad gangen?

Hans Microsoft Research-team begyndte at arbejde, og i marts 1995 havde de bygget et fungerende system til at konstruere programmer ved hjælp af den tilsigtede programmeringstilgang. Simonyi sagde, at IP havde opnået fuldstændig selvforsyning: det vil sige, at alt fremtidigt arbejde med IP ville blive udført ved hjælp af IP selv. Han belønnede sit hold med T-shirts med et af hans yndlingsbilleder fra barndommen: billedet af Baron Munchausen, der løfter sig selv og sin hest op af en mose ved at hive i sit eget hår. Simonyi annoncerede forsætlig programmering til verden i et papir fra september 1995 med titlen The Death of Computer Languages. Det var på tide, som han senere udtrykte det, at skomagerens børn fik nogle sko.

Gennem 1990'erne og ind i det nye årtusinde – mens Microsoft kæmpede sine krige med Netscape og det amerikanske justitsministerium og red ud af dotcom-boblen og busten – arbejdede Simonyi og hans team og lærte.

I mellemtiden, begyndende i 2001, pressede Microsoft hærene af udviklere, der skrev software til Windows, til at indføre et nyt programmeringssystem kaldet .Net Framework. I modsætning til bevidst programmering var .Net færdig, og det krævede en mindre radikal pause fra eksisterende programmeringsteknikker. Simonyi kløede efter at tage sin idé ud af laboratoriet og præsentere den for kunderne, men det var akavet under omstændighederne. Han forklarer: Det var upraktisk, da Microsoft gjorde enorme fremskridt med .Net på kort sigt, at på en eller anden måde sende nogen ud fra den samme organisation, der sagde: Sådan skal du ikke gøre tingene – hvad nu hvis du gjorde ting i denne anden , mere forstyrrende måde?

Simonyi havde været firmamand i mere end 20 år. Men i 2002 forlod han Microsoft og lancerede et selvstændigt firma. Han gik ud med en patent-kryds-licensaftale, der lod ham bruge koncepterne og ideerne fra hans forsætlige programmeringsforskning, men tillod ham ikke at tage noget af sin gamle kode med sig. Han skulle begynde at skrive en ny kodebase fra bunden.

Under sit nye firmas banner droppede Simonyi ordet programmering og omdøbte sit projekt til bevidst software. Den grundlæggende idé havde ikke ændret sig, men nu begyndte han at understrege tilgangens værdi for ikke-programmører. Simonyis pitch lød sådan her: I dag er det kun programmøren, der er i stand til at have en direkte effekt på softwaren. Emneeksperter eller domæneeksperter – de mennesker, der rent faktisk forstår, hvad softwaren skal gøre, uanset om det er journalføring, virksomhedsregnskab eller klimamodellering – kan ikke foretage ændringer i deres værktøjer; de er tvunget til at sende en slags ydmyg anmodning til programmøren. Intentional Software ville sælge softwareudviklingsværktøjer ikke kun til programmører, men til domæneeksperter, der virkelig kendte deres felter.

Intentional Softwares strategi låner fra en trend inden for programmering kendt som domænespecifikke sprog eller DSL'er – små programmeringsdialekter, der er afstemt efter behovene i specifikke discipliner. Simonyi roser DSL'er, men siger, at de ikke går langt nok. De er svære at skabe og derfor dyre; du ender med at have brug for mere end én (til et medicinsk faktureringssystem har du i det mindste brug for et medicinsk og et finansielt sprog); og de er uforenelige med hinanden. Intentional Softwares system er som en fabrik for flere DSL'er, der kan tale med hinanden.

Sådan kan det fungere: Antag, at en international bank ønskede at udvikle et nyt system til styring af transaktioner i flere valutaer. Først vil bankens egne domæneeksperter definere systemets funktionalitet ved at bruge deres sædvanlige termer og symboler og identificere de vigtigste variabler (tid eller værdi eller størrelse af transaktionen) og de mest almindelige procedurer (konvertere beholdninger fra en valuta til en anden eller købe hedge mod faldende værdi). Så ville programmørerne tage den information og bygge en domænespecifik programgenerator, der inkarnerer denne information. Et separat softwareværktøj ville give domæneeksperterne mulighed for at eksperimentere med forskellige datasæt og måder at se disse data på lige så let, som forretningsfolk i dag omarrangerer deres regneark.

Programmøren skulle ikke tilkaldes hver gang en ny udvikling i den internationale bankverden eller et hvilket som helst andet domæne krævede en ny softwarefunktion. Kunden ville ikke føle sig i spændetrøje af et programmeringssprog. Alle ville være glade.

Simonyi hævder, at hans tilgang løser flere af softwareingeniørens mest vedvarende problemer. Programmører i dag, siger han ofte, er uvidende kryptografer: de samler krav og viden fra deres kunder og skjuler derefter, bogstaveligt talt, den værdifulde information i et bjerg af implementeringsdetaljer – det vil sige kode. Fangsten er, når koden er skrevet, skal programmørerne foretage eventuelle tilføjelser eller ændringer ved at modificere selve koden . Det arbejde er smertefuldt, langsomt og tilbøjeligt til at fejle. Vi skal slet ikke røre ved koden, siger Simonyi. Vi bør være i stand til at designe funktioner og datastrukturer – som bevidst programmering repræsenterer som bevidste træer – og lade generatoren ændre koden i overensstemmelse hermed. (For en mere fuldstændig beskrivelse af tilsigtet programmering, se Forsætlig programmering forklaret)

I 2002 samlede Simonyi et nyt udviklingsteam; i dag omfatter det et dusin programmører, fordelt på Bellevue og Ungarn. De begyndte at genskabe Simonyis tilsigtede programmeringskode fra bunden og arbejdede med en håndfuld kunder for at teste deres antagelser og få feedback. For et år siden, inspireret af en ny indsigt i, hvordan man præsenterer flere synspunkter på heterogene typer data, smed de meget af deres kode ud og begyndte igen. Det er kreativ ødelæggelse, siger Simonyi. Hos Microsoft var det ret svært at gøre det, at smide alt væk. Men man må opgive ting, der er svære at forlænge.

ThoughtWorks, et globalt it-konsulentfirma, er en tidlig Intentional Software-kunde. Men ThoughtWorks' administrerende direktør, Roy Singham, siger, at mange af hans kolleger i virksomheden oprindeligt var skeptiske over for Simonyis nye projekt: Mange mennesker kigger på dette og siger: 'Glimrende koncept – men det kan ikke implementeres.' Så vi spurgte nogle af vores bedste tekniske hjerner til at se, og de kom alle tilbage og sagde, at han er på rette vej. Ja, det er svært. Ja, det kommer til at tage tid - måske mange år. Men intellektuelt har han fået fat i sagen. Det er det rigtige problem at løse.

Jeg har følt en vis frustration over, at vi ikke har fået noget, vi faktisk kan bruge i produktionen endnu, siger Martin Fowler, chefforsker hos ThoughtWorks. Charles ser ikke ud til at have travlt med at sende. Men én ting at huske på er, at han tidligere har afsendt ting – ret dramatiske ting med Office.

Den synlige frugt af Intentionals hidtidige arbejde er et smart værktøj kaldet Domain Workbench, som gemmer et programs vitale information i en intentional-tree-database og derefter tilbyder dig mange forskellige projektioner af denne information. I en demonstration, som Intentional gav ved to konferencer sidste efterår, tog Workbench – ved hjælp af en funktion kaldet Kalejdoskopet – en række kodefragmenter og viste dem i en svimlende række forskellige formater. Det var lige meget, hvordan kodens syntaks var blevet specificeret; du kunne se den og ændre den ved at bruge den notation, du foretrækker. Du kan redigere dit program som traditionel kode med parentes og indrykket, eller skifte til konturform, eller få det til at ligne et skematisk elektrisk ledningsdiagram, eller vælge noget, der kaldes et jernbanediagram, en slags flowchart-notation afledt af gammeldags togkort . Hver visning er en oversættelse af det underliggende træ – som du også kan undersøge og redigere.

Intentional Softwares arbejde fremkalder to hovedlinjer af kritik. Nogle teoretisk indstillede skeptikere siger, at Simonyis mål om at fange computerbrugeres intentioner er usandsynligt. Hvordan repræsenterer du hensigten? spørger datamatiker Jaron Lanier. Så snart vi ved, hvordan hjernen gemmer information, kan vi måske repræsentere hensigten. For mig virker det bare som en fantasi. Et andet argument, der er almindeligt blandt programmører, er mere praktisk. Mange programmører elsker deres tekstbaserede editorer og mistillidsværktøjer, der fjerner dem fra råkode. Hvad angår grafiske programmeringssprog som Visual Basic og de integrerede udviklingsmiljøer (IDE'er), der automatiserer rutineprogrammeringsopgaver, betragter de dem med nedladenhed: sådanne værktøjer, siger de, påtvinger deres egne måder at gøre tingene på, begrænser kreativiteten og holder programmører fra kode, som de før eller siden skal konfrontere. (For at forstå hvorfor programmører er så forsigtige, se The Law of Leaky Abstractions ) Skeptiske programmører ser på Intentional Software og ser udsigten til blot endnu en IDE. For dem, der tror, ​​at rigtige programmører skriver tekst, er bevidst programmering hverken særlig original eller meget ønsket.

Men for det meste er der overraskende lidt diskussion af Intentional Software i internettets myldrende koderfora. Dels skyldes det, at så få har set dens software. Intentional's arbejde er forløbet med en vis hemmelighed.

Da han startede Intentional Software, samarbejdede Simonyi med en professor ved University of British Columbia ved navn Gregor Kiczales. Simonyi beundrede Kiczales' arbejde med aspektorienteret programmering - en måde at organisere og ændre kode på i overensstemmelse med tværgående bekymringer, der ligner tilsigtet programmering. Kiczales, en anden veteran fra PARC, har brugt sin karriere på at arbejde på måder at få koden til at ligne designet. Kiczales så at slutte sig til Simonyi som en chance for at fremme dette mål. Men Kiczales stolede på open source-udvikling, hvor Simonyi ikke gjorde det. Den lukkede butikstilgang i Microsoft-stil føltes simpelthen ikke organisk for Kiczales. Jeg ville have gjort det på Java, siger han. Den første udgivelse ville have været om seks måneder. Uenigheden var venlig, men uforsonlig, siger begge mænd, og inden længe var Kiczales rejst.

For nu, beskyttet af Simonyis rigdom, har Intentional Software ingen måldato eller forsendelsesfrist. Men en af ​​dens to hovedkunder hævder at være tæt på at implementere Intentional-værktøjer. Capgemini – et Paris-baseret internationalt it-service- og konsulentfirma, der betjener store virksomheder, og hvis CTO, Andy Mulholland, er en bekendt af Simonyi – begyndte at arbejde med Intentional i marts sidste år og overvejer at bruge Intentionals system til projekter i den europæiske pensionsvirksomhed. Feltets meget komplekse regler, sammenflettet med kompleks forretningsdomænestruktur, får Simonyis tilgang til at se attraktiv ud, siger Henk Kolk, Capgeminis teknologiansvarlige for finansielle tjenester, som leder firmaets arbejde med Intentional.

Jordkontrol

Simonyis fascination af rummet har været livslang. Som 13-årig vandt han en konkurrence om at blive Ungarns Junior Astronaut og rejste til Moskva for at møde en kosmonaut. Som nyansat hos Microsoft i 1981 overbeviste han medstifter Paul Allen om at spille hooky fra at udvikle IBM PC'ens nye styresystem og flyve til Florida for at se rumfærgens første flyvning.

Simonyis kommende blastoff tilbyder ham et gensyn i hele kredsen med den sovjetiske teknologi, der satte hans livs kurs. Han har trænet i flere måneder på Ruslands Yuri Gagarin Cosmonaut Training Center i Star City, hvor han mestrer detaljerne i rumdragter og rumtoiletter og har lært russisk.

Rumrejsen vil bekræfte Simonyis status som den meget usandsynlige ting: en berømthedsprogrammør. Han har to jetfly og et pilotcertifikat til at flyve dem. Han dukker op i tabloiderne som den hyppige følgesvend af hjemmelavets ypperstepræstinde, Martha Stewart. Han har bygget en 233 fods yacht med et omsluttende dæk med glasvægge. Han har finansieret et professorat i Oxford for sin ven Richard Dawkins, den darwinistiske teoretiker.

Intet af dette vil selvfølgelig gøre nogen forskel i resultatet af Simonyis søgen efter at lindre de kroniske problemer på softwareområdet. Det er ikke nok at være en stor programmør, fortalte Simonyi engang til Michael Hiltzik, forfatter til en historie om PARC. Du skal finde et stort problem. Forsætlig leverer måske aldrig sine store løfter. Men ingen kan anklage Simonyi for at vælge et for beskedent problem.

Hans hjem er i disse dage et palæ ved Lake Washington, nede ved kysten fra Bill Gates' hus, med et kunstgalleri, en glasindkapslet swimmingpool, en heliport, et computerlaboratorium med magnetisk forede vægge og en drejebænk og boremaskine i kælder (for at opfylde disse Erector Set-trang). Huset kostede 10 millioner dollars at bygge: det er skråtstillet i en vinkel på syv grader og ser ud som om et let jordskælv ramte det, med ord fra New York Times forfatter Patricia Leigh Brown, som undrede sig over dens hermetisk lukkede, matematiske præcision og fandt den så stor, at en besøgende kan føle sig som en ensom asteroide, der rasler rundt i solsystemet.

[Kun] Charles ville bygge et 20.000 kvadratmeter stort hjem med et soveværelse, bemærkede Simonyis afhandlingsrådgiver og PARC-kollega Butler Lampson engang. Det enlige soveværelse har et cockpit-lignende kontrolcenter, der lader Simonyi tilpasse alle sine systemer – opvarmning, underholdning, telefon, belysning og vanding – til hans tilfredshed. Som en ubåd, forklarede han Brown. De skal alle være grønne, før du dykker ned. Der er også en drejelig seng, som Simonyi kan bruge til at finjustere sit udsyn – ud over søen; eller over til Seattles skyline, med dens warren af ​​kontorarbejdere, der kæmper med deres dokumenter og regneark; eller op på den stjerneklare nattehimmel, hvor hans seneste rejse snart vil tage ham.

Scott Rosenberg er vicepræsident for særlige projekter hos Salon.com. Han er forfatter til Drømmer i kode.

Forsætlig programmering forklaret
Simonyi og virksomheden er banebrydende med en trykknap-tilgang til programmering.

[ Klik her for et diagram over Simonyis planlagte tilgang]

Shane Clifford, en udvikler hos Intentional Software, fortæller denne fabel.

Engang var der en landsby med fire parker, vedligeholdt af fire konkurrencedygtige kvarterforeninger. Den første forening besluttede at pifte sin park op med en ny bænk. Det indhentede forslag fra tre af verdens førende bænkmagere. Ingen af ​​designs fik flertal af naboernes stemmer, så foreningen valgte det mest populære design. Processen var demokratisk – men i sidste ende var de fleste utilfredse med den nye bænk.

Den anden forening besluttede, at den ville have sin egen bænk, men en som alle kunne lide. Det fandt en producent, der byggede skræddersyede bænke af bland-og-match-dele. Men det træsæde, medlemmerne kunne lide, kom ikke i den rigtige længde, og den dekorative ryg fungerede ikke med de grønne ben, de kunne lide. Så de gik på kompromis med dele, der fungerede sammen. Naboerne var stolte af den færdige bænk, men ingen sad på den ret ofte.

Medlemmerne af den tredje forening så, hvor mange penge de to første havde brugt og besluttede, at de kunne gøre det bedre. Håndværkerne i gruppen bad alle om forslag, og til sidst byggede de en enkel, elegant bænk, som alle var enige om, var den pæneste i landsbyen. Desværre vaklede den farligt.

Den fjerde forening ønskede også en bænk, men den ønskede ikke at gentage de andre gruppers fejl. Naboerne henvendte sig til en lidet kendt bænkmager, som annoncerede for en ny bænkfremstillingsoplevelse. Bænkmageren ankom med en ladvogn fyldt med mærkelige maskiner. Han begyndte at stille spørgsmål som Hvad er denne bænks vigtigste egenskab? Hvad er den næstvigtigste funktion? Hvilke materialer kan du lide? Hvad er din yndlingsform til bænkens fødder?

Efter hvert svar drejede bænkmageren nogle få knapper på sine maskiner, og et nyt billede af den igangværende bænk ville dukke op på en stor skærm. Nogle gange var billedet ikke helt rigtigt, så naboerne trak tilbage og besvarede spørgsmålene anderledes. Efter 50 spørgsmål trykkede bænkmageren på en stor knap. Maskinerne nynnede et stykke tid, for derefter at udsluge en smuk bænk, der matchede det endelige billede på skærmen. Alle var glade for at have fået mulighed for at bidrage, og mange mennesker sad på bænken hver dag.

For at få en bænk, der gør alle glade, skal du bygge en automatisk bænkfremstillingsmaskine; hjælpe kunder med at definere deres præcise håb for deres bænk; oversæt disse forhåbninger til instruktioner, som maskinen forstår; og tryk derefter på knappen Lav. Klienter får tæt kontrol over resultatet, og bænkmagere, befriet fra de gentagne og mekaniske dele af bænkfremstilling, kan bruge mere tid på at bruge deres færdigheder til at fodre deres kunders ønsker ind i maskinen.

Erstat software til bænke, siger Clifford, og du vil forstå tilsigtet programmering - det hedder, fordi programmører er fokuseret på den måde, deres kunder har til hensigt, at et program skal fungere på, og ikke på det rod af kode, der kræves for at implementere disse intentioner.

Intentionel programmering ligner i konceptet, hvad-du-ser-er-hvad-du-får tekstbehandlingsprogrammer, som Charles Simonyi, Cliffords chef, var pioner. Wysiwyg-teksteditorer lader computerbrugere manipulere et dokuments udseende på skærmen uden at tvinge dem til at mestre den underliggende kode. Tilsvarende opfordrer tilsigtet programmering computerbrugere til at udtrykke deres behov på deres eget velkendte sprog og viser dem derefter forståelige synspunkter eller projektioner af det nye design, før den eksekverbare kode samles. Det er ikke den eneste programmeringsfilosofi, der er afhængig af sådanne grafiske repræsentationer; Unified Modeling Language (UML), udviklet i midten af ​​1990'erne hos Rational Software (nu en del af IBM), bruger også grafiske diagrammer til at repræsentere et programs funktion, struktur og adfærd. Men UML-diagrammer kan ikke omdannes til færdig software, hvilket er Simonyis drøm for bevidst programmering.

Hvordan håber Intentional Software at realisere den drøm? Lad os sætte Simonyis plan ind i sit eget diagram (klik her). Softwareopbygningsprocessen begynder naturligvis hos kunden: enhver organisation med en informationsintensiv opgave, der skal automatiseres. Simonyi kalder folk hos disse organisationer for domæneeksperter; de, ikke programmørerne, ved, hvad programmet skal gøre.

Med programmørernes hjælp oplister domæneeksperterne alle de begreber og definitioner, softwaren skal omfatte. Alle disse definitioner går ind i en database, som Simonyi kalder domæneskemaet.

Ligesom bænkmageren, der drejer på sine knapper, inkorporerer programmørerne derefter definitionerne i domæneskemaet i domænekode – en repræsentation på højt niveau af softwarens funktioner, udtrykt i et domænespecifikt sprog eller DSL, der kan skræddersyes til at passe til den pågældende branche. Men selvom DSL'er kan variere, er hver handling, softwaren skal udføre, gemt i et ensartet format, et tilsigtet træ. Intentionelle træer har den fordel, at de er visuelt enkle, men logisk omfattende, hvilket betyder, at de kan manipuleres, revideres og projiceres eller regnevisiones efter behag.

For eksempel beregningen repræsenteret af den simple programsætning

returner a = b / (c +1);

er repræsenteret af følgende tilsigtede træ:

Vend tilbage
(

Tildel
(

til,
Div
(

b,
Mere
(

c,
en

)

)

)

)

Når først den er kodet i træform, kan beregningen projiceres på mange andre måder, som måske er mere velkendte for domæneeksperter, som f.eks.

b
returnere a = ——- ;
c + 1

Som deres første konkrete opgave arbejder Simonyi og hans kolleger hos Intentional Software på at bygge et særligt værktøj, Domain Workbench, designet til at styre disse projektioner. Både domæneeksperterne og programmørerne bruger Domain Workbench til at redigere og genredigere projektionerne, indtil de ser rigtige ud. Derefter føres domænekoden ind i en generator – svarende til bænkproducentens lastbillæs af maskiner – der uddeler målkode på et sprog som C++ eller Java, som andre computere er i stand til at forstå, kompilere og køre.

Når først målkoden er genereret, kan den ikke omdannes til domænekode igen. I den henseende er generatoren som et krypteringsprogram, der irreversibelt omdanner almindelig tekst til chiffertekst.

Men - og dette er måske bevidst programmerings største fordel - det er nemt at skrotte gammel målkode og generere forbedret kode fra bunden. Revider blot domænekoden ved hjælp af Domain Workbenchs Wysiwyg-editor og kør den gennem generatoren igen. I de fleste ældre tilgange kan selv den mindste ændring i de oprindelige antagelser kræve, at programmører skal gennemsøge millioner af linjer kode og opdatere hver forekomst af et koncept, definition eller beregning manuelt.

Generatoren forbliver den største sorte boks i Intentional Softwares proces. I tekniske publikationer vil virksomheden kun sige om denne mystiske komponent, at prototypen er skrevet i Microsofts C# programmeringssprog, og at den får adgang til domæneskemaet og domænekoden ved hjælp af en applikationsprogrammeringsgrænseflade, en måde for to programmer at kommunikere på, der er indbygget i Domain Workbench. Det er klart, at det at skrive selve generatoren eller skræddersy den til en specifik industri eller DSL, vil være en stor del af omkostningerne ved ethvert bevidst programmeringsprojekt.

Wysiwyg bemyndigede millioner af flere brugere til at skrive flotte dokumenter, skriver Simonyi på virksomhedens blog. Det er på tide at gøre det samme for softwarebrugere.

Af Wade Roush

Loven om utætte abstraktioner
Uddrag fra Drømmer i kode: To dusin programmører, tre år, 4.732 fejl og én søgen efter transcendent software , af Scott Rosenberg, udgives af
Crown Books i januar 2007.

Software, vi har set, er en ting med lag, hvor hvert lag oversætter information og processer for lagene over og under. I bunden af ​​denne stak af lag sidder maskinen med sine rene binære enere og nuller. Øverst er menneskene, der bygger og bruger disse lag. Simonyis Intentional Software foreslår i bund og grund blot et lag mere mellem maskinen og os.

Softwarens lag er dets essens, og det er dem, der driver fremskridt på området, men de har en vedvarende svaghed. De lækker. For eksempel er brugere af mange versioner af Microsoft Windows trætte bekendt med fænomenet Blue Screen of Death. Du arbejder væk inde i et softwareprogram som en webbrowser eller Microsoft Word, og pludselig, ud af ingenting, bliver din skærm blå, og du ser noget hvid tekst på den, der lyder sådan her:

En fatal undtagelse 0E er indtruffet kl
0167: BFF9DFFF.

Den nuværende ansøgning vil blive afsluttet.

Når man ser skærmens monokrome udseende og den blokerede skrifttype, kan veteranbrugere fornemme, at de er blevet slynget baglæns i computertiden. Nogle vil måske endda forstå, at beskedens alarmerende henvisning til en fatal undtagelse betyder, at programmet har stødt på en fejl, det ikke kan komme sig fra, og er gået ned, eller at de kryptiske hexadecimale (base 16) tal beskriver den nøjagtige placering i computerens hukommelse, hvor nedbruddet tog sted. Ingen af ​​oplysningerne har nogen værdi for de fleste brugere. Den behagelige, velkendte grænseflade for det program, de brugte, er forsvundet; et dybere lag af abstraktion – i dette tilfælde Windows-skallen eller kontrolprogrammet på lavere niveau – er brudt ud som et skrå lag af grundfjeld, der stikker op gennem nyere geologiske lag og ind i sollys.

(Den Blue Screen of Death er forvirrende, men det repræsenterede faktisk et stort fremskridt i forhold til tidligere versioner af Windows, da det nogle gange giver brugeren mulighed for at lukke det stødende program ned og fortsætte med at arbejde. Før den blå skærm, styrtede et Windows-program næsten altid ned tog hele maskinen og alle dens programmer ned.)

I et essay med titlen The Law of Leaky Abstractions skrev Joel Spolsky: Alle ikke-trivielle abstraktioner er til en vis grad utætte. Abstraktioner mislykkes. Nogle gange lidt, nogle gange meget. Der er lækage. Ting går galt. For brugere betyder dette, at din computer nogle gange opfører sig på bizarre, forvirrende måder, og nogle gange vil du gerne, som Mitch Kapor sagde i sin Software Design Manifest , smid den ud af vinduet. For programmører betyder det, at nye værktøjer og ideer, der samler en smule computerkompleksitet på lavt niveau og pakker det i en ny abstraktion, der er lettere at manipulere, er fantastiske, men kun indtil de går i stykker. Så siver al den skjulte kompleksitet tilbage i deres arbejde. I teorien giver det praktiske nye toplag programmører mulighed for at glemme rodet under det; i praksis skal programmøren stadig forstå det rod, for til sidst kommer han til at lande i det. Spolsky skrev:

Abstraktioner forenkler ikke vores liv så meget, som det var meningen, de skulle. … Loven om utætte abstraktioner betyder, at når nogen kommer med et spøjst nyt kodegenereringsværktøj, der skal gøre os alle så effektive, hører du en masse mennesker sige: Lær at gøre det manuelt først, derefter brug wizzy-værktøjet for at spare tid. Kodegenereringsværktøjer, der foregiver at abstrahere noget, som alle abstraktioner, lækker, og den eneste måde at håndtere lækagen kompetent på er at lære om, hvordan abstraktionerne fungerer, og hvad de abstraherer. Så abstraktionerne sparer os for tid på at arbejde, men de sparer os ikke for tid på at lære. … Og alt dette betyder, at paradoksalt nok, selvom vi har højere og højere niveau programmeringsværktøjer med bedre og bedre abstraktioner, bliver det sværere og sværere at blive en dygtig programmør.

Så selvom de abstraktioner, vi har skabt gennem årene, tillader os at håndtere nye kompleksitetsordener i softwareudvikling, som vi ikke behøvede at håndtere for ti eller femten år siden, og selvom disse værktøjer lader os få meget af arbejde udført utrolig hurtigt, skrev Spolsky, pludselig en dag skal vi finde ud af et problem, hvor abstraktionen lækkede, og det tager to uger.

The Law of Leaky Abstractions forklarer, hvorfor så mange programmører, jeg har talt med, ruller skeptisk med øjnene, når de hører beskrivelser af Intentionel Programmering eller andre lignende ideer til at overskride softwarens kompleksitet. Det er ikke, at de ikke ville glæde sig over at tage endnu et skridt op ad abstraktionsstigen; men de frygter, at uanset hvor højt de klatrer på den stige, så skal de altid løbe op og ned ad den mere, end de gerne vil – og jo højere den bliver, jo længere er turen.

skjule