211service.com
Qualunque cosa tu possa fare, io posso fare meta
Il 9 aprile, su una remota piattaforma di lancio nelle pianure del Kazakistan, un controllore di terra terminerà il suo conto alla rovescia; un razzo Soyuz sparerà; e Charles Simonyi, ex capo architetto di Microsoft, genio tutelare delle sue applicazioni più famose, inventore del metodo di scrittura del codice utilizzato da 25 anni dai programmatori dell'azienda e ora fautore di un ambizioso progetto di riprogrammazione del software, inizierà la sua ascesa nello spazio.
Charles Simonyi presidente e CEO di Intentional Software.
Avvolto in una tuta spaziale russa, sentendo quattro G che lo spingono verso il basso in un rivestimento sagomato del sedile, il miliardario 58enne diventerà il quinto turista spaziale a visitare la Stazione Spaziale Internazionale. Il viaggio, che costerà a Simonyi circa 20 milioni di dollari, realizzerà il suo sogno di diventare un nerd nello spazio (per prendere in prestito un nome che ha scelto per il sito web che documenta la sua avventura extraterrestre: www.nerdinspace.com ). Gli darà anche l'opportunità di vedere il nostro pianeta dall'alto e oltre.
Questo è sempre stato il vantaggio preferito di Simonyi. In una carriera durata quattro decenni, ogni volta che ha affrontato un problema intrattabile nel software o nella vita, ha cercato di risolverlo uscendogli o superandolo. Ha anche un nome per la sua mossa preferita: la chiama andando meta. Nella sua giovinezza, nell'Ungheria degli anni '60, ha imparato le basi dell'informatica su un antiquato mainframe sovietico alimentato da tubi a vuoto, quindi ha progettato la sua fuga in Occidente. Negli anni '70, presso il leggendario Palo Alto Research Center (PARC) di Xerox, come parte del team che ha inventato il personal computer, Simonyi ha scritto la prima applicazione moderna: un elaboratore di testi che bandiva i codici complessi utilizzati poi per taggare il testo e visualizzava un documento come sembrerebbe sulla carta. Sia nella sua tesi di dottorato della Stanford University su un approccio di meta-programmazione per aumentare la produttività dei programmatori, la sua carriera in Microsoft che organizza legioni di sviluppatori di software e insegnando loro come strutturare il loro codice, o il suo viaggio pianificato nell'orbita terrestre questa primavera, andando oltre i modi stabiliti di fare le cose è sempre stato il metodo di Simonyi. Ora sta pianificando quella che spera sarà la sua meta-mossa più esplosiva di tutte. Simonyi crede di poter risolvere una serie di problemi ostinati che hanno sempre afflitto i computer offrendo a tutti coloro che li utilizzano e ai programmatori che li programmano una visione di livello superiore del software.
Bill Gates definisce Simonyi uno dei più grandi programmatori di tutti i tempi. In effetti, Simonyi è probabilmente il più programmatore di successo nel mondo, misurato in termini di ricompensa finanziaria e numero di persone che utilizzano le sue creazioni. (Altri celebri miliardari programmatori, come Larry Ellison e lo stesso Bill Gates, hanno guadagnato denaro e nomi fondando e gestendo iniziative tecnologiche.) Simonyi poteva facilmente scegliere di trascorrere il resto della sua vita finanziando iniziative filantropiche, pilotando aerei o navigando nel suo yacht. Invece, dice, sta programmando probabilmente più difficile che mai. È ossessionato da un progetto che ha perseguito per un decennio e mezzo e che quattro anni fa lo ha portato fuori dalle porte di Microsoft. È orgoglioso della sua professione. Ma è anche ossessionato dal pensiero di ciò con cui i programmatori devono fare i conti ogni volta che si dedicano al codice. Si chiede, perché è così difficile creare un buon software?
Multimedia
Altre foto di Simonyi
Codice Napoleonico
La nostra civiltà funziona con il software, afferma Bjarne Stroustrup, l'inventore del linguaggio di programmazione C++ (vedi Il problema con la programmazione) . Ma il software stesso non funziona molto bene. Ovunque si guardi, il software è fuori budget, in ritardo sulla pianificazione, insicuro, inaffidabile e difficile da usare. Ogni volta che un'organizzazione tenta di introdurre un nuovo sistema o di aggiornarne uno vecchio, corre un rischio colossale; oggi, i grandi progetti di tecnologia dell'informazione sono pozzi di catrame tecnologico che immobilizzano le istituzioni. Gli studi riportano regolarmente che due terzi di tali progetti subiscono gravi ritardi, significativi sforamenti dei costi o entrambi. Il governo degli Stati Uniti ha trovato quasi impossibile introdurre o aggiornare sistemi software su larga scala: gli sforzi decennali della Federal Aviation Administration e dell'FBI sono crollati nel caos. Le imprese non sono andate meglio. Per fare un solo esempio, i dirigenti di McDonald's sognavano un sistema di gestione basato sul Web che chiamavano Innovate che tracciasse il flusso in tempo reale di hamburger, patatine fritte e crocchette di pollo in ognuno dei loro ristoranti in tutto il mondo. Quando si sono arresi e hanno annullato il progetto, hanno dovuto cancellare $ 170 milioni del suo costo totale stimato di $ 1 miliardo.
Tali fallimenti si sommano. Ogni anno, secondo uno studio del 2002 del National Institute of Standards and Technology, i guasti del software costano 59,5 miliardi di dollari. Ma il prezzo del software scadente può essere misurato anche in termini di miseria umana e persino di vite perse. Durante la Guerra del Golfo del 1991, una batteria di missili Patriot non ha sparato contro uno Scud in arrivo a causa di un software difettoso; il colpo diretto su una caserma ha ucciso 28 soldati statunitensi.
L'ultimo mezzo secolo di informatica ha visto progressi meravigliosi. I programmatori hanno abbandonato schede perforate e telescriventi. Ci hanno fornito un computer su ogni desktop, strumenti per il lavoro, giocattoli per il gioco e una rete che collega case e aziende per formare un brulicante pool globale di informazioni e intrattenimento. Questo progresso è stato alimentato dalla curva esponenziale della Legge di Moore, la previsione del fondatore di Intel Gordon Moore secondo cui la potenza dei microchip raddoppierebbe (o il loro costo si dimezzava) ogni uno o due anni. Ma anche se la legge di Moore ha reso i nuovi computer di ogni anno più veloci ed economici, la flessibilità e l'utilità dei nostri sistemi informatici sono state limitate dall'evoluzione più lenta e irregolare del software. Una formulazione di questo problema è nota come legge di Wirth, dopo l'esperto di programmazione Niklaus Wirth: il software diventa più lento più velocemente dell'hardware diventa più veloce.
Simonyi condivide gran parte della comune insoddisfazione per il software. Il software come lo conosciamo è il collo di bottiglia del corno dell'abbondanza digitale, dice. Richiede enormi risorse in termini di talento e tempo. È deludente e difficile da cambiare. Blocca l'innovazione in molte organizzazioni.
L'ambizione di Simonyi è quella di sbloccare quel collo di bottiglia del software, caratteristicamente, andando in meta. Ha sviluppato un approccio che chiama programmazione intenzionale (o, più recentemente, software intenzionale), che spera possa ribaltare la programmazione. Se Simonyi farà a modo suo, i programmatori smetteranno di cercare di gestire le esigenze dei loro clienti. Invece, per ogni problema che gli viene chiesto di affrontare, che si tratti di monitoraggio dell'inventario o guida missilistica, creeranno strumenti generici che gli stessi utenti del computer possono modificare per guidare l'evoluzione futura del software.
In un grigio pomeriggio dello scorso ottobre, mi sono seduto con Simonyi a Bellevue, WA, davanti a due schermi adiacenti nel suo ufficio presso Intentional Software, la società che ha fondato dopo aver lasciato Microsoft nel 2002 per sviluppare e commercializzare la sua grande idea. Simonyi mi stava guidando attraverso una presentazione che stava preparando per una conferenza imminente; ha utilizzato le diapositive di Microsoft Office PowerPoint per delineare la sua visione del grande balzo in avanti proposto nella programmazione. Stava spostando una diapositiva quando l'applicazione ha smesso di rispondere.
Nell'angolo dello schermo di sinistra, è spuntata una graffetta con gli occhi stralunati: l'assistente di Office ampiamente disprezzato che Microsoft ha introdotto nel 1997. Simonyi ha cercato di ignorare l'agitazione dell'assistente dei cartoni animati, ma è stato ostacolato. Non funziona niente, sospirò. Questo perché Clippy mi sta dando un po' di aiuto.
ero perplesso. Vuoi dire che non hai disattivato Clippy? Molto tempo fa, avevo cercato tra i menu di Office e avevo controllato qualsiasi casella fosse necessaria per soffocare il fastidioso antropomorfo una volta per tutte.
Non so come, ammise Simonyi, con una risatina che sembrava dire: Sì, lo so, non è ironico?
Era. Simonyi ha trascorso anni alla guida dei team applicativi di Microsoft, gli sviluppatori di Word ed Excel, i cui prodotti vengono utilizzati ogni giorno da decine di milioni di persone. È ampiamente considerato il padre di Microsoft Word. (Naturalmente sto usando Word per scrivere queste frasi.) Charles Simonyi avrebbe potuto incontrare la sua corrispondenza in Clippy?
Simonyi fissò il suo avversario, come se fosse impegnato in un combattimento telepatico. Poi si voltò verso di me, con gli occhi azzurri che brillavano. Ho bisogno di un aiutante: un Super-Clippy che mi mostri dove spegnerlo! Simonyi desiderava ardentemente un meta-Clippy.
Nel 2004, Simonyi ha proposto la sua legge: tutto ciò che può essere fatto potrebbe essere fatto 'meta'. Nei suoi giorni più giovani - quando aveva grandiosamente chiamato un progetto Infinitely Glorious Network di Simonyi - probabilmente sarebbe stato più arrogante: tutto ciò che puoi fare, posso fare meta! Ma come molti prodigi che hanno fatto bene e sono invecchiati bene, Simonyi ha imparato a tagliare la sua sfrontatezza con tocchi di umiltà e grazia. Dieci anni fa, si descriveva come un ragazzo dall'aspetto arruffato con un accento straniero. Predilige dolcevita neri e blazer doppiopetto. Con la sua postura eretta e il viso quadrato, una ciocca di capelli scuri pettinati in avanti sulla fronte, si dice spesso che assomigli a un Napoleone dalle ossa più grandi.
Il software intenzionale è un grande schema in un campo in cui i grandi schemi hanno raramente funzionato. Ogni precedente innovazione introdotta come soluzione completa ai problemi del software ha finito per fornire solo miglioramenti modesti e incrementali. Ma Simonyi trabocca della sicurezza di un immigrato che si è fatto da sé che ha sempre avuto una salda presa sui propri stivali. In una foto appesa sopra la sua scrivania, è in piedi alla Casa Bianca sotto un ritratto di Ronald Reagan. Il suo largo sorriso rispecchia quello del presidente. La didascalia recita I due ottimisti.
Gli uffici della nuova azienda di Simonyi occupano una suite in un elegante grattacielo di vetro, e se ti sporgi alla finestra e guardi in basso puoi vedere il tetto del tozzo, anonimo edificio bianco che ospitava il suo primo ufficio alla Microsoft, nel 1981. ( Ora è una banca.) Da allora, Microsoft è cresciuta oltre ogni riconoscimento. L'industria del software ha trasformato il mondo. Allora perché Simonyi ha deciso di riscrivere tutte le sue regole? Il problema è così grande che sembra parte dell'ordine stabilito delle cose. La soluzione proposta da Simonyi potrebbe richiedere decenni per essere completata e i suoi critici sono molto scettici. Nessuno gli sta chiedendo di lasciarsi alle spalle le note routine di programmazione e partire per un nuovo mondo. Ma tali migrazioni hanno pagato per lui in passato.
Il linguaggio della macchina
Simonyi è nato a Budapest nel 1948. Figlio di un professore di fisica, si è innamorato a 15 anni del suo primo computer, un gigantesco Ural II russo nell'ufficio statistico centrale ungherese. Negli anni '60, l'Ural, che riceveva istruzioni tramite chiavi in stile registratore di cassa e disponeva di una stanza piena di tubi a vuoto per eseguire calcoli, sarebbe già stato una reliquia in qualsiasi altra parte del mondo. Ma i leader comunisti ungheresi stavano cercando di utilizzare il rifiuto sovietico per ottimizzare gli orari di treni e autotrasporti. L'Ural non era all'altezza del compito: non c'era modo di inserire dati in tempo reale sulle spedizioni. Era completamente senza speranza, ricorda Simonyi. Avrebbe potuto essere fatto molto facilmente dalla domanda e dall'offerta. Sfortunatamente, questo era politicamente scorretto.
Ma a Simonyi non importava. Amavo quel computer, dice, anche se era inutile. Da bambino aveva costruito un'auto Erector Set con un cambio a quattro velocità, non tanto perché voleva giocarci, quanto semplicemente per capire come funzionava. Un ex studente di suo padre trovò a Simonyi un lavoro come infermiera notturna degli Urali. Poiché la macchina faceva esplodere un tubo ogni volta che veniva spenta e riaccesa, l'Ufficio di statistica ha preferito lasciarla funzionare tutta la notte. Così, dal tramonto all'alba, il mainframe era tutto di Simonyi; aveva un personal computer prima che esistessero cose del genere. Ha imparato a programmarlo scrivendo routine intelligenti ma inutili per generare quadrati magici, matrici numeriche in cui le somme delle righe, delle colonne e delle diagonali corrispondono.
I programmatori di altre parti del mondo avevano già inventato una Babele di linguaggi di programmazione – Fortran, Cobol, Lisp (un linguaggio favoloso: vedi Ancient Text, p. 20), e così via – per facilitare il loro lavoro, che allora come oggi consisteva nello scrivere faticosamente elaborati set di istruzioni per l'esecuzione da parte dei computer. In quelle lingue, le istruzioni assumevano la forma di righe di testo che venivano immesse su tastiere e archiviate frequentemente su schede perforate. Questo codice sorgente è stato quindi compilato o tradotto in codice macchina: il uno sabbia 0 s che un computer digitale potrebbe capire. Il metodo rimane in gran parte invariato oggi, anche se la maggior parte dei programmatori ora utilizza strumenti di programmazione in esecuzione su normali PC. Ma sugli Urali, Simonyi imparò a programmare a un livello più primitivo, inserendo laboriosamente i codici operativi del linguaggio macchina, specificando, istruzione per istruzione, le sequenze di acquisizioni di memoria, aggiunte, depositi di memoria e salti che il processore del computer doveva seguire per eseguire anche l'operazione più banale. Era (come disse Simonyi all'autore Steve Lohr nel libro del 2001 Vai a ) Programmazione dell'età della pietra. Simonyi ricorda ancora i codici. Ventidue è JUMP, dice oggi. È masterizzato nella mia ROM.
L'Ungheria degli anni '60, ancora riluttante alla repressione sovietica della sua rivolta del 1956, non era un posto per un giovane ambizioso con un gusto per la risoluzione dei problemi. A 17 anni, Simonyi ha ottenuto uno stage presso un'azienda informatica danese mostrando ad alcuni dei suoi programmatori campioni dei suoi programmi Ural codificati a mano. Le autorità ungheresi si aspettavano il ritorno di Simonyi; aveva già vinto un ambito posto universitario. Invece, con l'incoraggiamento di suo padre, fuggì negli Stati Uniti.
Una lettera di raccomandazione dell'esperto di programmazione danese Peter Naur lo ha aiutato a vincere l'ingresso all'Università della California, a Berkeley. Ha pagato le bollette con un lavoro al centro informatico di Berkeley, dove ha attirato l'attenzione di un membro della facoltà di nome Butler Lampson. Lampson era uno dei leader del Project Genie dell'Agenzia per i progetti di ricerca avanzata della difesa degli Stati Uniti, un esperimento sui sistemi informatici a condivisione di tempo, in cui più utenti seduti ai terminali potevano condividere il tempo cerebrale di un singolo computer. Quando i creatori del Project Genie avviarono una società, chiamata Berkeley Computer Corporation (BCC), il cui scopo era quello di costruire una macchina che avrebbe commercializzato il loro lavoro, Lampson reclutò Simonyi.
Alla BCC, Simonyi eseguiva il debug del prototipo ribelle dell'azienda durante la notte, lavorando con il progettista di sistema Chuck Thacker. Una notte, Simonyi si è presentato con un vestito nero trasparente, una specie di cosa hippie da uno dei negozi di Telegraph Avenue, dice. Oggi, non riesce a ricordare esattamente il motivo—proveniente da una festa, forse? Il debug è andato particolarmente bene quella notte, e l'abito è diventato un portafortuna: la tuta di debug di Simonyi.
BCC è fallito dopo solo pochi anni, ma Lampson, Thacker e gran parte del team BCC sono migrati allo Xerox PARC. Simonyi, allora solo uno studente universitario ungherese senza una carta verde, come dice ora, si unì a loro nel 1972, lavorando alla Xerox e contemporaneamente perseguendo il suo dottorato a Stanford. Bob Taylor, che ha supervisionato il Computer Science Lab del PARC durante una parte di quell'era leggendaria, afferma che la creatività di Simonyi si è distinta anche nella famosa folla del laboratorio: poteva solo immaginare modi di esprimere codice e idee che lo mettessero fuori scala.
È stato un periodo inebriante. Il team di ingegneri visionari stava creando una serie di innovazioni che avrebbero plasmato il prossimo quarto di secolo dell'era dei PC: l'interfaccia utente grafica, il networking (Ethernet), la stampante laser, la programmazione orientata agli oggetti (Smalltalk), il computer portatile (il Dynabook) e altro ancora. Queste scoperte confluirono tutte in un prototipo di personal computer chiamato Alto.
L'Alto è stata un'invenzione straordinaria, ma non era chiaro cosa ci si potesse fare fino a quando Simonyi e i suoi colleghi non hanno creato la sua applicazione più nota: un elaboratore di testi chiamato Bravo, il cui tipo di visualizzazione sullo schermo corrispondeva a quello che il sistema avrebbe prodotto alla nuova stampante laser. I word processor esistenti disponevano di elaborati sistemi di codici per la formattazione del testo sullo schermo (chiunque abbia utilizzato WordPerfect su un PC negli anni '80 ne ricorderà i codici incorporati); Bravo ti consente di dimenticare i codici, manipolare direttamente il design di un documento e assistere immediatamente ai cambiamenti. Un dirigente di Citibank in visita ha guardato una demo e ha citato una frase caratteristica del personaggio impertinente del comico Flip Wilson, Geraldine: Quello che vedi è quello che ottieni! Il nome (ridotto all'acronimo Wysiwyg e pronunciato wizzywig ) bloccato. Improvvisamente, Bravo ha avuto utenti: parenti e amici dei ricercatori del PARC hanno iniziato a chiedere di usarlo per stampare newsletter scolastiche e formattare documenti accademici. La moglie di Lampson ha stampato la sua tesi usando il sistema, e quando è arrivato il momento per Simonyi di stampare la sua, lui ha fatto lo stesso.
Livelli di astrazione
Wysiwyg è un esempio di livello di astrazione, uno strumento di livello superiore che consente agli utenti di computer di ignorare alcune complessità di livello inferiore. I programmatori usano sempre le astrazioni. Il codice di testo scritto in un linguaggio di programmazione è un'astrazione del codice macchina che un computer comprende effettivamente. Un nome di dominio Web è un'astrazione dell'indirizzo numerico del protocollo Internet di un server.
Ma la maggior parte degli strati di astrazione nei sistemi informatici sono meno visibili e più arcani di Wysiwyg. Da quando i programmatori hanno smesso di memorizzare gli opcode che Simonyi usava in gioventù, hanno stratificato nuove astrazioni su vecchie astrazioni. Ogni generazione di programmatori utilizza i linguaggi di programmazione e gli strumenti della propria epoca per creare i programmi della generazione successiva. Strati di astrazione si sono accumulati come strati geologici. I messaggi salgono costantemente dalla base binaria della tua macchina e scendono di nuovo, consentendo a un clic del mouse di svolgere la sua funzione. Il clic del mouse attiva un codice nel sistema operativo, che invia un messaggio al programma di elaborazione testi, che indica al sistema operativo di salvare il file su un disco rigido. Ma questo processo apparentemente semplice è possibile solo grazie a molti, molti strati di astrazione.
La storia del software è la storia di questi livelli, ognuno dei quali allontana i programmatori dal binario, lasciandoli maggiormente in grado di convincere i computer a svolgere compiti utili. Costantemente, i programmatori hanno guadagnato più potere. Ma stavano anche affrontando problemi sempre più ambiziosi. I programmi aumentarono di volume e i programmatori iniziarono a perdersi in grovigli di quello che chiamavano codice spaghetti, che si rivelò impossibile da sbrogliare e riparare. Pertanto, i grandi progetti software sono diventati epici di frustrazione e ritardo. I responsabili dei programmi hanno affrontato problemi aziendali come: come si pianifica realisticamente un progetto? Come si migliora la produttività individuale? Come coordinare un lavoro complesso in un team numeroso? Ognuna di queste domande si è rivelata sorprendentemente difficile da rispondere.
La difficoltà di coordinare il lavoro di un team ha ispirato il detto più famoso dell'ingegneria del software, noto come legge di Brooks: l'aggiunta di manodopera a un progetto software in ritardo lo fa dopo. Frederick P. Brooks Jr. ha raggiunto questa triste conclusione dopo aver guidato il travagliato sforzo di IBM per scrivere software per i suoi 360 mainframe negli anni '60. Nel suo libro del 1975, Il mitico mese dell'uomo , Brooks ha osservato che il lavoro procede più lentamente nei team più grandi a causa dei costi di coordinamento: il tempo che i programmatori perdono tenendosi al corrente del loro lavoro.
Questo è stato lo sfondo per la tesi di laurea di Simonyi del 1977, Meta-Programming: A Software Production Method. Simonyi ha proposto un nuovo approccio all'ottimizzazione della produttività, in cui un programmatore capo, o meta-programmatore, ha progettato un prodotto e ne ha definito tutti i termini, quindi ha consegnato un progetto ai tecnici, programmatori ape operaia che avrebbero eseguito l'implementazione. Simonyi mirava a sfuggire alla legge di Brooks vietando ai tecnici di parlare tra loro: tutta la comunicazione doveva passare attraverso il meta-programmatore. Per la sua tesi, ha testato l'idea usando due gruppi su due progetti, A e B. Il suo approccio dispotico alla programmazione non ha mai preso piede, ma questo non lo ha affatto turbato. L'obiettivo principale di Simonyi nella ricerca della sua tesi non era dimostrare il valore delle sue idee, ma far scrivere più velocemente Bravo, il nuovo word processor Wysiwyg. Non riusciva a convincere i vertici del PARC ad assumere altri programmatori, quindi ha usato la sua tesi come un sotterfugio per portare un po' di aiuto. Bravo stesso era il progetto B.
Con il passare degli anni '70, Simonyi divenne impaziente di fronte all'incapacità di Xerox di trasformare la ricerca pionieristica del PARC in prodotti di successo. Un giorno un amico gli ha mostrato VisiCalc, il nuovo programma di fogli di calcolo per l'Apple II. Simonyi ha entusiasmato. C'era un'altra applicazione, come Bravo, che poteva cambiare la vita delle persone, ma a differenza di Bravo, funzionava su un computer del mercato di massa che le persone potevano permettersi di acquistare. Il lavoro del PARC, si rese conto, non avrebbe mai visto la luce del giorno. Chiese al suo ex collega del PARC Bob Metcalfe, che aveva lasciato il laboratorio nel 1979 per avviare 3Com, di consigliare potenziali capi nel nascente settore dei PC. In testa alla lista c'era Bill Gates.
Nel 1981, Simonyi si trasferì a Seattle per avviare il gruppo di nuove applicazioni presso Microsoft, che fino ad allora aveva venduto linguaggi di programmazione e sistemi operativi. Aveva 33 anni, ma questo lo ha reso un adulto tra i giovani di Microsoft (Gates aveva allora 26 anni, Steve Ballmer 25).
Durante tutti gli anni in cui Simonyi ha supervisionato i prodotti che alla fine si sono uniti nella suite di programmi nota come Microsoft Office, ha continuato a cercare nuove efficienze in nuovi tipi di astrazioni di programmazione. In particolare, ha istruito generazioni di programmatori Microsoft nella disciplina di tenere traccia della miriade di nomi di variabili utilizzati nei grandi programmi. Nella programmazione per computer, le variabili rappresentano informazioni che possono cambiare durante l'esecuzione di un programma. Ad esempio, il programma del carrello degli acquisti di un negozio online avrà variabili che rappresentano il numero di articoli di ogni tipo da acquistare, il prezzo di ciascun articolo e le spese di spedizione e le tasse. Usando queste variabili, un programmatore può scrivere una semplice riga di codice che moltiplica la quantità per il prezzo, aggiunge le spese di spedizione e le tasse e calcola il costo totale, che diventa il valore di un'altra variabile.
Un programma di grandi dimensioni può avere migliaia di variabili diverse che un team di programmazione deve tenere in ordine. Nominarli con attenzione diventa cruciale. Oggi, la maggior parte del codice presenta nomi di variabili progettati per trasmettere un significato ai programmatori che lo leggeranno, nomi come NumberOfItems o ShoppingCartTotal. Nello schema di denominazione di Simonyi, che aveva inventato per uso personale anni prima, ogni nome di variabile viene fornito con un prefisso che fornisce informazioni utili su di esso, come il suo tipo (intero, diciamo, o frazione decimale o stringa di lettere). Alcuni sistemi limitano la lunghezza dei nomi delle variabili a otto caratteri; Simonyi ha semplicemente omesso le vocali.
Il codice risultante era denso e difficile da leggere. Secondo il pioniere della programmazione Andy Hertzfeld, il sistema di Simonyi divenne noto come notazione ungherese, sia in omaggio al luogo di nascita del suo creatore, sia perché faceva sembrare i programmi scritti in una lingua straniera imperscrutabile. L'ungherese è ampiamente maledetto dai suoi detrattori. L'esperto canadese di Java Roedy Green l'ha scherzosamente definita l'arma nucleare tattica delle tecniche di offuscamento del codice sorgente. Il programmatore Mozilla Alec Flett ha scritto questa parodia:
prepBut nI vrbLike adjHungarian! qCos'è l'arteThe adjBig nProblem?
Hertzfeld, scrivendo di un incontro alla Apple con un codice ungherese scritto da un collega che aveva lavorato con Simonyi al PARC, ha detto che i nomi sembravano essere stati scelti dal nemico di Superman della quinta dimensione, Mr. Mxyzptlk.
Ma mentre i critici ritengono che l'ungherese renda illeggibile il codice, Simonyi ne rimane orgoglioso e lo utilizza ancora oggi.
Meta-Euforia
All'inizio degli anni '90, il successo di Microsoft aveva fatto la fortuna di Simonyi. (Per molti anni, Forbes ha stimato che fosse di $ 1 miliardo.) Ma sentiva ancora lo strattone di affari incompiuti. La confusione del software aveva reso la creazione di Office snervante per Microsoft. Ma ora, con computer più potenti dell'Alto su ogni scrivania e Internet che li collegava, la crisi del software era la crisi di tutti. Simonyi iniziò a pensare che fosse ora di tornare in meta.
Charles ha sempre cercato di costruire i suoi sistemi in modo da aumentare il livello di astrazione, in modo da poter gestire la complessità del sistema. Perché la complessità è morte, dice Chuck Thacker, vecchio collega di Simonyi della BCC e del PARC, che sta conducendo un progetto di ricerca sull'architettura dei computer presso Microsoft. E sfortunatamente, in questi giorni, fornire le strutture che le persone desiderano effettivamente si traduce in un sistema complesso. Stiamo resistendo con la punta delle dita in questo momento.
Passando a una posizione presso Microsoft Research, Simonyi iniziò a definire il concetto di programmazione intenzionale, o IP in breve. La programmazione intenzionale aggiungerebbe un livello di astrazione completamente nuovo alla pratica di scrivere software. Consentirebbe ai programmatori di esprimere le proprie intenzioni senza sprofondare nel pantano dei cosiddetti dettagli implementativi che hanno sempre minacciato di inghiottirli. Come i meta-programmatori della tesi di Simonyi, che passavano le istruzioni ai programmatori delle api operaie, il programmatore intenzionale avrebbe passato il lavoro di scut, ma non a un collega più giovane. Invece, la programmazione intenzionale richiedeva una sorta di fabbrica di codice chiamata generatore, un programma che accetta una serie di comandi di livello relativamente alto e sputa un codice funzionante più dettagliato. L'obiettivo non era tanto quello di facilitare il lavoro di programmazione quanto di lasciare che i programmatori pulissero il loro cervello dalle banalità in modo che potessero effettivamente essere creativi.
Dalla sua iniziazione alla programmazione come un adolescente che inseriva codici operativi negli Urali, Simonyi aveva scalato la scala dell'astrazione. Ma sentiva di non essere abbastanza in alto. Per molti versi la programmazione sembrava ancora primitiva. Perché i programmatori erano ancora gravati da sintassi del linguaggio di programmazione incompatibili? Perché è stato così difficile estendere le loro lingue preferite in nuove aree? Perché i programmatori lavoravano ancora con il testo normale, disponendo un piccolo numero di caratteri in stringhe lineari come facevano in passato con le schede perforate? Il lavoro Wysiwyg di Simonyi aveva permesso agli impiegati di creare e modificare documenti complessi. Ingegneri e designer utilizzavano strumenti CAD/CAM avanzati per progettare e modificare progetti per grattacieli e aeroplani. Perché i programmatori, i maghi che avevano reso possibile tutto questo, continuavano a beccare il loro codice un carattere alla volta?
Il suo team di Microsoft Research si mise al lavoro e nel marzo 1995 aveva creato un sistema funzionante per la creazione di programmi utilizzando l'approccio della programmazione intenzionale. Simonyi ha affermato che l'IP ha raggiunto la completa autosufficienza: in altre parole, tutto il lavoro futuro sull'IP sarebbe stato svolto utilizzando l'IP stesso. Ha premiato la sua squadra con magliette decorate con una delle sue foto preferite dell'infanzia: l'immagine del barone Munchausen che solleva se stesso e il suo cavallo da una palude tirandosi i capelli. Simonyi annunciò al mondo la programmazione intenzionale in un articolo del settembre 1995 intitolato The Death of Computer Languages. Era ora, come disse in seguito, che i figli del ciabattino prendessero delle scarpe.
Negli anni '90 e nel nuovo millennio, mentre Microsoft combatteva le sue guerre con Netscape e il Dipartimento di Giustizia degli Stati Uniti e superava la bolla e il fallimento delle dot-com, Simonyi e il suo team lavoravano e imparavano.
Nel frattempo, a partire dal 2001, Microsoft stava spingendo gli eserciti di sviluppatori che scrivevano software per Windows ad adottare un nuovo sistema di programmazione chiamato .Net Framework. A differenza della programmazione intenzionale, .Net era finito e richiedeva una rottura meno radicale dalle tecniche di programmazione esistenti. Simonyi non vedeva l'ora di portare la sua idea fuori dal laboratorio e di presentarla ai clienti, ma era imbarazzante date le circostanze. Spiega: Non era pratico, quando Microsoft stava facendo passi da gigante con .Net nel breve termine, inviare in qualche modo qualcuno dalla stessa organizzazione che dicesse: Non è così che dovresti fare le cose, e se facessi cose in quest'altra , modo più dirompente?
Simonyi era un uomo d'affari da più di 20 anni. Ma nel 2002 ha lasciato Microsoft e ha lanciato una società indipendente. È uscito con un accordo di licenza incrociata di brevetto che gli ha permesso di usare i concetti e le idee della sua ricerca sulla programmazione intenzionale, ma non gli ha permesso di portare con sé nessuno del suo vecchio codice. Avrebbe dovuto iniziare a scrivere una nuova base di codice da zero.
Sotto la bandiera della sua nuova azienda, Simonyi ha abbandonato la parola programmazione e ha rinominato il suo progetto come software intenzionale. L'idea di base non era cambiata, ma ora iniziò a sottolineare il valore dell'approccio per i non programmatori. Il discorso di Simonyi è stato più o meno questo: oggi solo il programmatore è in grado di avere un effetto diretto sul software. Gli esperti in materia o gli esperti di dominio, ovvero le persone che comprendono effettivamente cosa deve fare il software, che si tratti di tenuta di cartelle cliniche, contabilità aziendale o modellazione del clima, non possono apportare modifiche ai loro strumenti; sono costretti a sottoporre al programmatore una sorta di umile richiesta. Il software intenzionale venderebbe strumenti di sviluppo software non solo ai programmatori, ma anche agli esperti di dominio che conoscevano davvero i loro campi.
La strategia di Intentional Software prende in prestito da una tendenza nella programmazione nota come linguaggi specifici del dominio o DSL, piccoli dialetti di programmazione sintonizzati sulle esigenze di discipline specifiche. Simonyi loda i DSL ma dice che non vanno abbastanza lontano. Sono difficili da creare e quindi costosi; finisci per aver bisogno di più di uno (per un sistema di fatturazione medica, avresti bisogno almeno di un linguaggio medico e finanziario); e sono incompatibili tra loro. Il sistema di Intentional Software è come una fabbrica per più DSL che possono comunicare tra loro.
Ecco come potrebbe funzionare: supponiamo che una banca internazionale voglia sviluppare un nuovo sistema per la gestione delle transazioni in più valute. In primo luogo, gli esperti di dominio della banca definirebbero la funzionalità del sistema, utilizzando i loro termini e simboli abituali e identificando le variabili più importanti (tempo o valore o dimensione dell'operazione) e le procedure più comuni (conversione di posizioni da una valuta a un'altra o acquisto di copertura contro la caduta di valore). Quindi i programmatori prenderebbero quell'informazione e costruirebbero un generatore di programma specifico per il dominio che incorpora quell'informazione. Uno strumento software separato consentirebbe agli esperti di dominio di sperimentare diversi set di dati e modi per visualizzare tali dati con la stessa facilità con cui oggi gli uomini d'affari riorganizzano i fogli di calcolo.
Il programmatore non avrebbe dovuto essere convocato ogni volta che qualche nuovo sviluppo nel mondo delle banche internazionali, o qualsiasi altro dominio, richiedeva una nuova funzionalità del software. Il cliente non si sentirebbe costretto a usare un linguaggio di programmazione. Tutti sarebbero felici.
Simonyi sostiene che il suo approccio risolve molti dei problemi più persistenti dell'ingegneria del software. I programmatori oggi, dice spesso, sono crittografi inconsapevoli: raccolgono requisiti e conoscenze dai loro clienti e poi, letteralmente, nascondono quelle preziose informazioni in una montagna di dettagli di implementazione, ovvero di codice. Il problema è che, una volta scritto il codice, i programmatori devono apportare eventuali aggiunte o modifiche modificando il codice stesso . Quel lavoro è doloroso, lento e soggetto a errori. Non dovremmo assolutamente toccare il codice, dice Simonyi. Dovremmo essere in grado di progettare funzioni e strutture dati, che la programmazione intenzionale rappresenta come alberi intenzionali, e lasciare che il generatore modifichi il codice di conseguenza. (Per una descrizione più completa della programmazione intenzionale, vedere Spiegazione della programmazione intenzionale)
Nel 2002 Simonyi ha riunito un nuovo team di sviluppo; oggi comprende una dozzina di programmatori, divisi tra Bellevue e Ungheria. Hanno iniziato a ricreare da zero il codice di programmazione intenzionale di Simonyi e a lavorare con una manciata di clienti per testare le loro ipotesi e ottenere feedback. Un anno fa, ispirati da una nuova intuizione su come presentare più visualizzazioni di tipi di dati eterogenei, hanno buttato giù molto del loro codice e hanno ricominciato. È distruzione creativa, dice Simonyi. In Microsoft, era abbastanza difficile farlo, buttare via tutto. Ma devi abbandonare le cose che sono difficili da estendere.
ThoughtWorks, una società di consulenza IT globale, è uno dei primi clienti di Intentional Software. Ma il CEO di ThoughtWorks, Roy Singham, afferma che molti dei suoi colleghi dell'azienda erano inizialmente scettici sul nuovo progetto di Simonyi: Molte persone lo guardano e dicono: 'Concetto geniale, ma non è attuabile'. Così abbiamo chiesto ad alcuni dei nostri i migliori cervelli tecnici per andare a cercare, e tutti sono tornati e hanno detto che è sulla strada giusta. Sì, è difficile. Sì, ci vorrà tempo, forse molti anni. Ma intellettualmente, ha la cosa inchiodata. È il problema giusto da risolvere.
Ho provato una certa frustrazione per il fatto che non abbiamo ancora qualcosa che possiamo effettivamente utilizzare nella produzione, afferma Martin Fowler, capo scienziato di ThoughtWorks. Charles non sembra avere una gran fretta di spedire. Ma una cosa da tenere a mente è che ha spedito cose in passato, cose piuttosto drammatiche, con Office.
Il frutto visibile del lavoro di Intentional fino ad oggi è uno strumento elegante chiamato Domain Workbench, che memorizza le informazioni vitali di un programma in un database ad albero intenzionale e quindi offre molte proiezioni diverse di tali informazioni. In una dimostrazione data da Intentional in due conferenze lo scorso autunno, il Workbench, utilizzando una funzione chiamata Kaleidoscope, ha preso una serie di frammenti di codice e li ha visualizzati in una vertiginosa varietà di formati. Non importava come fosse stata specificata la sintassi del codice; potevi visualizzarlo e modificarlo, usando la notazione che preferisci. Puoi modificare il tuo programma come codice tradizionale tra parentesi quadre e rientrate, o passare alla forma di contorno, o farlo sembrare uno schema elettrico schematico, o scegliere qualcosa chiamato diagramma ferroviario, una sorta di notazione del diagramma di flusso derivata dalle mappe dei treni vecchio stile . Ogni vista è una traduzione dell'albero sottostante, che puoi anche esaminare e modificare.
Il lavoro di Intentional Software provoca due principali linee di critica. Alcuni scettici dalla mentalità teorica affermano che l'obiettivo di Simonyi di catturare le intenzioni degli utenti di computer non è plausibile. Come rappresenti l'intento? chiede l'informatico Jaron Lanier. Non appena sappiamo come il cervello immagazzina le informazioni, forse possiamo rappresentare l'intento. A me sembra solo una fantasia. Un altro argomento, comune tra i programmatori, è più pratico. Molti programmatori adorano i loro editor basati su testo e diffidano degli strumenti che li allontanano dal codice grezzo. Per quanto riguarda i linguaggi di programmazione grafica come Visual Basic e gli ambienti di sviluppo integrato (IDE) che automatizzano le attività di programmazione di routine, li considerano con condiscendenza: tali strumenti, dicono, impongono i propri modi di fare le cose, limitano la creatività e impediscono ai programmatori di codice che, prima o poi, dovranno confrontarsi. (Per capire perché i programmatori sono così cauti, vedere The Law of Leaky Abstractions ) I programmatori scettici guardano al software intenzionale e vedono la prospettiva di un altro IDE. Per coloro che pensano che i veri programmatori scrivono il testo, la programmazione intenzionale non è né molto originale né tanto desiderata.
Ma soprattutto, c'è sorprendentemente poca discussione sul software intenzionale nei brulicanti forum di codificatori di Internet. In parte, è perché così pochi hanno visto il suo software. Il lavoro di Intentional si è svolto con una certa segretezza.
Quando ha avviato Intentional Software, Simonyi ha collaborato con un professore della University of British Columbia di nome Gregor Kiczales. Simonyi ha ammirato il lavoro di Kiczales sulla programmazione orientata agli aspetti, un modo di organizzare e modificare il codice in base a preoccupazioni trasversali che assomiglia alla programmazione intenzionale. Kiczales, un altro veterano del PARC, ha trascorso la sua carriera lavorando su come rendere il codice simile al design. Kiczales ha visto unirsi a Simonyi come un'opportunità per raggiungere questo obiettivo. Ma Kiczales si fidava dello sviluppo open source, mentre Simonyi no. L'approccio del negozio chiuso in stile Microsoft semplicemente non sembrava organico a Kiczales. L'avrei fatto in Java, dice. La prima uscita sarebbe avvenuta tra sei mesi. Il disaccordo era amichevole ma inconciliabile, dicono entrambi gli uomini, e in poco tempo Kiczales se ne era andato.
Per ora, protetto dalla ricchezza di Simonyi, Intentional Software non ha una data obiettivo o una scadenza di spedizione. Ma uno dei suoi due principali clienti afferma di essere vicino alla distribuzione di strumenti intenzionali. Capgemini, una società internazionale di consulenza e servizi IT con sede a Parigi che serve grandi imprese e il cui CTO, Andy Mulholland, è un conoscente di Simonyi, ha iniziato a lavorare con Intentional lo scorso marzo e sta valutando l'utilizzo del sistema di Intentional per progetti nel settore delle pensioni europee. Le regole molto complesse del settore, intrecciate con la complessa struttura del dominio aziendale, rendono l'approccio di Simonyi attraente, afferma Henk Kolk, responsabile della tecnologia dei servizi finanziari di Capgemini, che guida il lavoro dell'azienda con Intentional.
Controllo a terra
Il fascino di Simonyi per lo spazio è durato tutta la vita. All'età di 13 anni, ha vinto un concorso per diventare il giovane astronauta ungherese e si è recato a Mosca per incontrare un cosmonauta. Come nuovo assunto in Microsoft nel 1981, convinse il cofondatore Paul Allen a giocare con lo sviluppo del nuovo sistema operativo del PC IBM e a volare in Florida per assistere al primo volo dello space shuttle.
L'imminente esplosione di Simonyi gli offre una riunione a tutto tondo con la tecnologia dell'era sovietica che ha segnato il corso della sua vita. Si è allenato per mesi presso il Centro di addestramento dei cosmonauti Yuri Gagarin in Russia a Star City, padroneggiando i dettagli di tute spaziali e servizi igienici spaziali e imparando il russo.
Il viaggio nello spazio confermerà lo status di Simonyi come quella cosa altamente improbabile: un programmatore di celebrità. Ha due jet e una licenza di pilota per pilotarli. Si presenta sui tabloid come il compagno frequente dell'alta sacerdotessa dei lavori domestici, Martha Stewart. Ha costruito uno yacht di 233 piedi con un avvolgente ponte con pareti di vetro. Ha finanziato una cattedra a Oxford per il suo amico Richard Dawkins, il teorico darwiniano.
Niente di tutto questo, ovviamente, farà alcuna differenza nell'esito della ricerca di Simonyi per alleviare i problemi cronici del campo del software. Non basta essere un grande programmatore, disse una volta Simonyi a Michael Hiltzik, autore di una storia del PARC. Devi trovare un grande problema. Intenzionale potrebbe non mantenere mai le sue grandi promesse. Ma nessuno può accusare Simonyi di aver scelto un problema troppo modesto.
La sua casa in questi giorni è una villa sul lago Washington, lungo la riva della casa di Bill Gates, con una galleria d'arte, una piscina con pareti di vetro, un eliporto, un laboratorio informatico con pareti rivestite magneticamente, un tornio e un trapano a colonna nel seminterrato (per soddisfare quelle voglie di Erector Set). La casa è costata 10 milioni di dollari per la costruzione: è inclinata di sette gradi e sembra che sia stata colpita da un leggero terremoto, nelle parole di New York Times la scrittrice Patricia Leigh Brown, che si è meravigliata della sua precisione matematica ermeticamente sigillata e l'ha trovata così vasta che un visitatore può sentirsi come un solitario asteroide che sferraglia intorno al sistema solare.
[Solo] Charles avrebbe costruito una casa di 20.000 piedi quadrati con una camera da letto, ha osservato una volta Butler Lampson, relatore della tesi di Simonyi e collega del PARC. L'unica camera da letto vanta un centro di controllo simile a una cabina di pilotaggio che consente a Simonyi di modificare tutti i suoi sistemi: riscaldamento, intrattenimento, telefono, illuminazione e irrigazione, in modo soddisfacente. Come un sottomarino, spiegò a Brown. Devono essere tutti verdi prima di immergerti. C'è anche un letto girevole, che Simonyi può usare per mettere a punto la sua visuale sul lago; o oltre allo skyline di Seattle, con i suoi reparti di impiegati che lottano con i loro documenti e fogli di calcolo; o su nel cielo notturno stellato, dove presto lo porterà il suo ultimo viaggio.
Scott Rosenberg è vicepresidente dei progetti speciali di Salon.com. È l'autore di Sognare in codice
Spiegazione della programmazione intenzionale
Simonyi e la società stanno sperimentando un approccio alla programmazione a pulsante.
[ Clicca qui per un diagramma dell'approccio pianificato di Simonyi]
Shane Clifford, uno sviluppatore di Intentional Software, racconta questa favola.
C'era una volta un villaggio con quattro parchi, gestito da quattro associazioni di quartiere competitive. La prima associazione ha deciso di abbellire il proprio parco con una nuova panchina. Ha sollecitato proposte da tre dei principali produttori di panche del mondo. Nessuno dei design ha vinto la maggioranza dei voti dei vicini, quindi l'associazione ha scelto il design più popolare. Il processo è stato democratico, ma alla fine la maggior parte non era contenta della nuova panchina.
La seconda associazione ha deciso di volere una panchina tutta sua, ma che piacesse a tutti. Ha trovato un produttore che ha costruito panche personalizzate da parti combinabili. Ma il sedile in legno che piaceva ai membri non era della lunghezza giusta e lo schienale decorativo non funzionava con le gambe verdi che piacevano loro. Quindi hanno raggiunto un compromesso su parti che funzionavano insieme. I vicini erano orgogliosi della panchina finita, ma nessuno ci si sedeva molto spesso.
I membri della terza associazione hanno visto quanti soldi avevano speso i primi due e hanno deciso che potevano fare di meglio. Gli artigiani del gruppo hanno chiesto suggerimenti a tutti e alla fine hanno costruito una panchina semplice ed elegante che tutti hanno ritenuto la più bella del paese. Sfortunatamente, ha oscillato pericolosamente.
Anche la quarta federazione voleva una panchina, ma non voleva ripetere gli errori degli altri gironi. I vicini si sono rivolti a un produttore di panche poco conosciuto che ha pubblicizzato una nuova esperienza di panca. Il fabbricante di banchi è arrivato con un camion a pianale pieno di macchine dall'aspetto strano. Ha iniziato a fare domande come Qual è la caratteristica più importante di questa panchina? Qual è la prossima caratteristica più importante? Quali materiali ti piacciono? Qual è la tua forma preferita per i piedi della panca?
Dopo ogni risposta, il bench maker girava alcune manopole sulle sue macchine e una nuova immagine del bench in progress sarebbe apparsa su un grande schermo. A volte l'immagine non era del tutto corretta, quindi i vicini tornavano indietro e rispondevano alle domande in modo diverso. Dopo 50 domande, il banchiere premette un grosso pulsante. Le macchine ronzarono per un po', poi scaricarono una bella panca che corrispondeva all'immagine finale sullo schermo. Tutti erano contenti di aver avuto la possibilità di contribuire e molte persone si sono sedute in panchina ogni giorno.
Per ottenere un banco che renda tutti felici, devi costruire una macchina automatica per fare il banco; aiutare i clienti a definire le loro precise speranze per il loro banco; tradurre quelle speranze in istruzioni che la macchina da banco comprende; e quindi premere il pulsante Crea. I clienti ottengono uno stretto controllo sul risultato e i produttori di banchi, liberati dalle parti ripetitive e meccaniche della creazione di banchi, possono dedicare più tempo a utilizzare le proprie competenze per alimentare i desideri dei propri clienti nella macchina.
Sostituisci il software ai banchi, sta dicendo Clifford, e capirai la programmazione intenzionale, così chiamata perché i programmatori si concentrano sul modo in cui i loro clienti intendono che un programma funzioni, e non sul disordine di codice necessario per implementare tali intenzioni.
La programmazione intenzionale è concettualmente simile ai programmi di elaborazione testi 'ciò che vedi è ciò che ottieni', di cui Charles Simonyi, il capo di Clifford, è stato il pioniere. Gli editor di testo Wysiwyg consentono agli utenti di computer di manipolare l'aspetto di un documento sullo schermo senza costringerli a padroneggiare il codice sottostante. Allo stesso modo, la programmazione intenzionale incoraggia gli utenti di computer a esprimere i propri bisogni nel proprio linguaggio familiare, quindi mostra loro visioni comprensibili o proiezioni del progetto emergente prima che il codice eseguibile venga assemblato. Non è l'unica filosofia di programmazione che si basa su tali rappresentazioni grafiche; anche l'Unified Modeling Language (UML), sviluppato a metà degli anni '90 presso Rational Software (ora parte di IBM), utilizza diagrammi grafici per rappresentare la funzione, la struttura e il comportamento di un programma. Ma i diagrammi UML non possono essere trasformati in software finito, che è il sogno di Simonyi per la programmazione intenzionale.
In che modo Intentional Software spera di realizzare quel sogno? Mettiamo il piano di Simonyi nel suo diagramma (clicca qui). Il processo di creazione del software inizia, naturalmente, con il cliente: qualsiasi organizzazione con un'attività ad alta intensità di informazioni che necessita di automazione. Simonyi chiama le persone di queste organizzazioni esperti di dominio; loro, non i programmatori, sanno cosa dovrebbe fare il programma.
Con l'aiuto dei programmatori, gli esperti del dominio elencano tutti i concetti e le definizioni che il software dovrà comprendere. Tutte queste definizioni entrano in un database che Simonyi chiama schema di dominio.
Come il bench maker che gira le sue manopole, i programmatori incorporano quindi le definizioni nello schema del dominio nel codice del dominio, una rappresentazione di alto livello delle funzioni del software, espressa in un linguaggio specifico del dominio, o DSL, che può essere adattato per adattarsi al settore in questione. Ma mentre i DSL possono variare, ogni azione che il software deve eseguire viene memorizzata in un formato uniforme, un albero intenzionale. Gli alberi intenzionali hanno il vantaggio di essere visivamente semplici ma logicamente comprensivi, il che significa che possono essere manipolati, rivisti e proiettati o reinventati a piacimento.
Ad esempio, il calcolo rappresentato dalla semplice istruzione del programma
restituisce a = b / (c +1) ;
è rappresentato dal seguente albero intenzionale:
Ritorno
(
Assegnare
(
a,
Divi
(
B,
Di più
(
C,
uno
)
)
)
)
Una volta codificato in forma di albero, il calcolo può essere proiettato in molti altri modi che potrebbero essere più familiari agli esperti di dominio, come
B
restituire un = ——- ;
c + 1
Come primo compito concreto, Simonyi e i suoi colleghi di Intentional Software stanno lavorando alla creazione di uno strumento speciale, Domain Workbench, progettato per gestire queste proiezioni. Sia gli esperti di dominio che i programmatori utilizzano Domain Workbench per modificare e modificare nuovamente le proiezioni finché non sembrano corrette. Successivamente, il codice del dominio viene immesso in un generatore, l'equivalente del carico di macchine del produttore di banchi, che sforna il codice di destinazione in un linguaggio come C++ o Java che altri computer sono in grado di comprendere, compilare ed eseguire.
Una volta che il codice di destinazione è stato generato, non può essere ritrasformato in codice di dominio. A questo proposito, il generatore è come un programma di crittografia che trasforma irreversibilmente il testo in chiaro in testo cifrato.
Tuttavia, e questo è forse il più grande vantaggio della programmazione intenzionale, è facile eliminare il vecchio codice di destinazione e generare codice migliorato da zero. È sufficiente rivedere il codice del dominio utilizzando l'editor Wysiwyg di Domain Workbench ed eseguirlo nuovamente attraverso il generatore. Nella maggior parte degli approcci precedenti, anche il minimo cambiamento nelle ipotesi originali potrebbe richiedere ai programmatori di vagliare milioni di righe di codice, aggiornando manualmente ogni istanza di un concetto, definizione o calcolo.
Il generatore rimane la più grande scatola nera nel processo di Intentional Software. Nelle pubblicazioni tecniche, tutto ciò che l'azienda dirà su questo misterioso componente è che il prototipo viene scritto nel linguaggio di programmazione C# di Microsoft e che accede allo schema del dominio e al codice del dominio utilizzando un'interfaccia di programmazione dell'applicazione, un modo per comunicare tra due programmi, integrato nel Domain Workbench. Chiaramente, però, scrivere il generatore stesso, o personalizzarlo per un settore specifico o DSL, sarà una parte importante del costo di qualsiasi progetto di programmazione intenzionale.
Wysiwyg ha consentito a milioni di altri utenti di creare documenti di bell'aspetto, scrive Simonyi sul blog dell'azienda. È tempo di fare lo stesso per gli utenti del software.
di Wade Roush
La legge delle astrazioni che perdono
Tratto da Sognando nel codice: due dozzine di programmatori, tre anni, 4.732 bug e una ricerca per il software trascendente , di Scott Rosenberg, in corso di pubblicazione da
Crown Books nel gennaio 2007.
Il software, abbiamo visto, è una questione di livelli, con ogni livello che traduce informazioni e processi per i livelli sopra e sotto. In fondo a questa pila di strati si trova la macchina con i suoi uni e zeri binari puri. In alto ci sono gli esseri umani, che costruiscono e usano questi strati. Il software intenzionale di Simonyi, in sostanza, propone semplicemente uno strato in più tra la macchina e noi.
I livelli del software sono la sua essenza e sono ciò che guida il progresso nel campo, ma hanno una debolezza persistente. Perdono. Ad esempio, gli utenti di molte versioni di Microsoft Windows hanno una certa familiarità con il fenomeno del Blue Screen of Death. Stai lavorando all'interno di un'applicazione software come un browser Web o Microsoft Word e improvvisamente, dal nulla, lo schermo diventa blu e vedi del testo bianco su di esso che recita qualcosa del genere:
Si è verificata un'eccezione fatale 0E a
0167: BFF9DFFF.
L'applicazione corrente verrà chiusa.
Osservando l'aspetto monocromatico dello schermo e il carattere tipografico squadrato, gli utenti veterani potrebbero percepire di essere stati proiettati indietro nel tempo del computer. Alcuni potrebbero persino capire che il riferimento allarmante del messaggio a un'eccezione irreversibile significa che il programma ha riscontrato un bug da cui non può recuperare e si è bloccato, o che i numeri esadecimali criptici (base 16) descrivono l'esatta posizione nella memoria del computer in cui si è verificato l'arresto anomalo ha avuto luogo. Nessuna delle informazioni è di alcun valore per la maggior parte degli utenti. L'interfaccia comoda e familiare dell'applicazione che stavano usando è svanita; uno strato più profondo di astrazione – in questo caso, la shell di Windows o il programma di controllo di livello inferiore – è eruttato come uno strato inclinato di roccia che spunta attraverso strati geologici più recenti e alla luce del sole.
(Per quanto sconcertante sia la schermata blu della morte, in realtà rappresentava un grande progresso rispetto alle versioni precedenti di Windows poiché a volte consente all'utente di chiudere il programma offensivo e continuare a lavorare. Prima della schermata blu, il crash di un programma Windows quasi sempre smontato l'intera macchina e tutti i suoi programmi.)
In un saggio intitolato The Law of Leaky Abstractions, Joel Spolsky ha scritto: Tutte le astrazioni non banali, in una certa misura, sono leaky. Le astrazioni falliscono. A volte poco, a volte molto. Ci sono perdite. Le cose vanno male. Per gli utenti questo significa che a volte il tuo computer si comporta in modi bizzarri e sconcertanti, a volte lo vorrai, come ha detto Mitch Kapor nel suo Software Design Manifesto , buttalo fuori dalla finestra. Per i programmatori significa che nuovi strumenti e idee che raccolgono un po' di complessità di elaborazione di basso livello e lo impacchettano in una nuova astrazione più facile da manipolare sono fantastici, ma solo fino a quando non si rompono. Quindi tutta quella complessità nascosta torna nel loro lavoro. In teoria, il pratico nuovo livello superiore consente ai programmatori di dimenticare il disordine sottostante; in pratica, il programmatore ha ancora bisogno di capire quel pasticcio, perché alla fine ci finirà dentro. Spolsky ha scritto:
Le astrazioni in realtà non semplificano le nostre vite tanto quanto avrebbero dovuto. ... La legge delle astrazioni che perdono significa che ogni volta che qualcuno esce con un nuovo strumento di generazione di codice geniale che dovrebbe renderci tutti così efficienti, senti un sacco di persone che dicono: prima impara a farlo manualmente, poi usa lo strumento wizzy per risparmiare tempo. Gli strumenti di generazione del codice che fingono di astrarre qualcosa, come tutte le astrazioni, falliscono e l'unico modo per affrontare le perdite con competenza è imparare come funzionano le astrazioni e cosa stanno astraendo. Quindi le astrazioni ci fanno risparmiare tempo lavorando, ma non ci fanno risparmiare tempo nell'apprendimento. … E tutto questo significa che paradossalmente, anche se abbiamo strumenti di programmazione di livello sempre più alto con astrazioni sempre migliori, diventare un programmatore esperto sta diventando sempre più difficile.
Quindi, anche se le astrazioni che abbiamo creato nel corso degli anni ci permettono di affrontare nuovi ordini di complessità nello sviluppo del software che non abbiamo dovuto affrontare dieci o quindici anni fa, e anche se questi strumenti ci hanno permesso di ottenere molto di lavoro svolto in modo incredibilmente rapido, ha scritto Spolsky, improvvisamente un giorno abbiamo bisogno di capire un problema in cui l'astrazione è trapelata, e ci vogliono due settimane.
The Law of Leaky Abstractions spiega perché così tanti programmatori con cui ho parlato alzano gli occhi al cielo quando sentono descrizioni di Intentional Programming o altre idee simili per trascendere la complessità del software. Non è che non gradirebbero fare un altro passo avanti nella scala dell'astrazione; ma temono che non importa quanto in alto salgano su quella scala, dovranno sempre percorrerla su e giù più di quanto vorrebbero, e più diventa alta, più lungo è il viaggio.