Mitopoietica del C'hi++

Il settimo giorno, Dio fece il backup

Su di me ci sono due teorie: qualcuno pensa che io sia impazzito cercando di fare il debug dell’Universo, altri pensano invece che io abbia deciso di fare il debug dell’Universo perché sono pazzo.

Anche il Maestro Canaro fu accusato di essere pazzo quando disse di essere stato incaricato da Dio di fare il porting dell’Universo dal COBOL al C++, ma non era pazzo. Ho conservato questi documenti: sono l’ultima pagina del suo diario e le relazioni che furono inviate alla società per cui lui lavorava mentre era distaccato dal “Cliente”. Mettili all’inizio del tuo libro, così tutto ciò che diremo dopo non sarà che una ripetizione.

Ultima pagina del diario del Maestro Canaro (8 Aprile)

Sono in ufficio e sto lavorando quando squilla il telefono. La voce che mi risponde è piuttosto bassa e ha un'eco curiosa. Mi fa:
- Canaro, sono Dio, ho bisogno di te.
- Marco, ho da fare, ci sentiamo dopo.
Riattacco. Un attimo dopo il telefono squilla di nuovo. Stavolta faccio caso al tipo di squillo e deduco che si tratta di una telefonata esterna.
- Canaro, non sono il tuo collega, sono davvero Dio. Devi aiutarmi a fare il porting dell'universo in C++.
Non posso fare a meno di sorridere.
- Carina. E anche il sintetizzatore vocale mi sembra che funzioni piuttosto bene. Senti, finisco questa relazione e ti offro un caffè, ma adesso lasciami lavorare.
Riattacco di nuovo e di nuovo il malefico oggetto fa sentire la sua voce. È un'esterna, non posso rischiare: potrebbe essere un cliente, ma so già che..
- Canaro, ascoltami una buona volta: sono davvero Dio e ho bisogno che tu mi risolva un problema.
Sto per dirgli qualcosa di cui poi mi pentirò, ma la voce continua:
- Se non mi credi, stacca la spina del telefono.
- Ma per favore..
- Staccala!
Più per curiosità che altro, vado a vedere il suo bluff. Stacco la spina.
- Adesso mi credi?
Devo dire che per un attimo il mio scetticismo vacilla. Cerco una possibile spiegazione.
- Hai messo una ricevente nella cornetta.
- Testardo eh? Va bene: scegli un oggetto a caso.
- Per fare cosa?
- Per utilizzarlo come cornetta, uno che il tuo collega non possa aver manomesso.
- Marco, per favore..
- Avanti, cosa ti costa? Visto che sei così sicuro..
- La mia pipa va bene?
- Quello che vuoi: avvicinala all'orecchio.
Vediamo dove vuole andare a parare: tiro fuori la mia pipa dall'astuccio di pelle e avvicino il fornello all'orecchio.
- Fatto, - dico e intanto mi guardo intorno in attesa dello scherzo.
- Lo so, - la voce è nel fornello di radica. - Adesso, se per favore potessimo riprendere la nostra conversazione telefonica.. Non vorrei che entrasse qualcuno e ti vedesse parlare con una pipa.

- Premetto che io di queste cose di computer non ci capisco niente, -  mi dice appena ho riattaccato la spina del telefono.
- Mio figlio, invece, i computer li sa usare e mi ha detto che sarebbe meglio fare il porting dell'universo in un linguaggio a oggetti, suggerendomi questo C++. Ora, vedi, io vado forte in scienze naturali, non in informatica, e tutti questi termini tecnici, per me, sono misteriosi: cosa vuol dire fare il porting di qualcosa? e cosa sono i linguaggi orientati agli oggetti?
“Bella domanda”, pensai. Anni prima avevo scritto un manuale di C++ e il paradigma a oggetti era l'argomento del primo capitolo. Se solo lo avesse letto..
- Ho anche dato una scorsa al tuo libro, ma non ci ho capito niente: scrivi di schifo, lasciatelo dire. E poi, mi sono detto, chissà quante cose sono cambiate nel frattempo, così ho deciso di chiamarti.
- Innanzitutto la ringrazio per i complimenti, poi, per venire alla sua domanda, fare il porting di qualcosa vuol dire riscrivere un'applicazione con un linguaggio di programmazione differente da quello in cui era stata scritta inizialmente.
- E questo a quale scopo?
- Di solito per sfruttare le potenzialità del nuovo linguaggio o per poter utilizzare l'applicazione in un sistema per cui il vecchio linguaggio non sia valido.
- Come tradurre i dieci comandamenti dall'Ebraico al Latino?
- Qualcosa di simile.
- E questo "C++"? Cosa vuol dire "linguaggio orientato agli oggetti"?
- Che invece di tipi di dato astratti come numeri e caratteri, permette di utilizzare dei tipi di dato simili a quelli reali.
- Non ho capito.
- I vecchi linguaggi di programmazione costringevano il programmatore a utilizzare solo dei tipi di dato predefiniti: numeri, lettere, date. Questo va bene per un certo tipo di applicazioni, ma rende difficile scrivere applicazioni più complesse dove può essere utile sfruttare un linguaggio che sia capace di gestire anche dei nuovi tipi di dato, definiti dall'utente. In C++, il linguaggio che suo figlio le ha consigliato, questo si ottiene per mezzo delle classi.
- Come in zoologia?
- Una specie. Per classe si intende un tipo di dato non standard, del quale si può definire il comportamento.
- Fammi un esempio, che non capisco. E poi basta con questo lei, passiamo al "tu", che è più semplice.
- Mettiamo che tu abbia due stringhe..
- Non porto scarpe con le stringhe, uso i sandali Birkenstock.
- Intendevo delle sequenze di caratteri. Ora, per come un computer gestisce i dati normalmente, non ha senso addizionare due stringhe, dato che non si tratta di un tipo di dato numerico, ma si può definire una classe "Stringa" che, se sottoposta ad addizione, faccia qualcosa di sensato.
- Del tipo?
- Poniamo che tu abbia una stringa A qualsiasi.
- "Pippo" va bene?
- Originale. E che tu voglia unirla ad un'altra stringa B.
- "Pluto".
- Anche questa bella originale. Comunque, tu scriverai l'istruzione: C = A + B e nella stringa C ci sarà scritto: "PippoPluto".
- Lo terrò a mente la prima volta che mi capiterà di dover scrivere: "PippoPluto".
- Era un esempio.
- Seguito a non capire perché si chiamino "linguaggi orientati agli oggetti".
- Perché non gestiscono dati grezzi, ma oggetti con un loro comportamento ben definito.
- Devo vederlo in pratica. Comunque, quali sarebbero i vantaggi di questa traduzione?
- Nel caso del C++, una maggior facilità di analisi.
- Ma l'analisi dell'applicazione già c'è.
- E una maggiore facilità di debug.
- Prego?
- Di correzione degli errori.
- L'applicazione attuale è in funzione da un'eternità e non ha mai dato nessun problema.
- Aumenta anche le possibilità di riutilizzare il codice in altre applicazioni.
- Questo mi sembra utile quanto la stringa "PippoPluto".
- Il processo produttivo ha una certificazione di qualità?
- Io ho visto che era buono: direi che può bastare.
- Be', allora non vedo che necessità ci sia di riscriverla.
- Esattamente quello che ho detto a mio figlio, ma lui ha cominciato a parlare di questo C++ e di quell'altro, quello col nome di un'isola, come si chiama..
- Java? Non si riferisce a un'isola, ma a un tipo di miscela per il caffè.
- Quello che sia. Il discorso è: che bisogno c'è di riscrivere tutto?
- Per quello che ne posso capire, direi nessuno..
- Bene, ti ringrazio.
Attacca (o quello che è), ma dopo un po' richiama.
- Canaro, ho parlato con mio figlio e lui dice che sono un retrogrado, che l'applicazione attuale è obsoleta, che gli utenti si lamentano e che questo porting è necessario. Io non ci capisco più niente, cosa devo fare?
Sto per rispondere "Lo sa Iddio", ma fortunatamente mi trattengo e ricorro alla risposta standard in questi casi:
- Potremmo fare uno studio di fattibilità e poi decidere..
- Mi sembra una buona idea. Quando puoi cominciare?
- Non lo so, devo chiederlo al mio responsabile.
- D'accordo: chiediglielo e poi fammi sapere.
Riattacca senza dirmi come potrò "farglielo sapere", ma questo è l'ultimo dei miei problemi. Il primo, al momento, è in che modo raccontare questa cosa al mio capo senza farmi prendere per pazzo.

- Se speri di rimediare un periodo di convalescenza per esaurimento nervoso, scordatelo. Hai detto (e soprattutto fatto) cose molto più strane.
- Lo so che è pazzesco, ma è vero: Dio mi ha telefonato e mi ha chiesto di riscrivere l'Universo in C++.
- Canaro, piantala e vai a finire l'analisi, che la dobbiamo portare al cliente nel pomeriggio.
- E se mi richiama, cosa gli devo dire?
- Raccontagli di quanto hai sbagliato le stime dell'ultimo progetto, così si rivolgerà a un altro.
Scornato, me ne torno al mio loculo dove mi preparo in anticipo la seconda pipa della giornata. Mentre armeggio con il tabacco, il telefono squilla per l'ennesima volta, ma non è chi mi aspetto che sia, bensì il mio capo che mi richiama nel suo ufficio. "Chiamata di re, tanto buona non è..", penso, ma quando arrivo nella ben nota stanza dall'inequivocabile odore di sigaro toscano, mi trovo di fronte un uomo d'umore molto diverso da quello che mi ha allontanato poco prima. La voce è pacata, i modi gentili e mostra la massima comprensione e disponibilità nei miei confronti.
- Passa le cose che stai seguendo a Igino e Paolo e dedicati completamente allo studio di fattibilità per il porting dell'Universo. Stupito per il repentino voltafaccia, chiedo la prima cosa che mi passa per la testa.
- Su quale commessa devo scaricare le ore?
- Ancora non lo so, ma non te ne preoccupare. Oh, se ti serve un portatile puoi prendere il mio.
- Va bene, grazie. C'è nient'altro?
- Tieni, - mi porge un foglietto con qualcosa scritto sopra. - ha detto che puoi richiamarlo a questo numero.
Rientro nel mio ufficio, chiudo la porta e compongo il numero: una voce registrata mi avvisa che l'utente è al momento occupato, ma che è stato inviato l'avviso di chiamata. Non passa un attimo che sento la Sua voce dire:
- Sì, pronto?
- Scusami, io ti ho richiamato subito, ma se sei al telefono..
- Non ti preoccupare, stavamo chiudendo. Allora?
- Sono a tua disposizione, ma prima di iniziare c'è una cosa che devo dirti.
- Vuoi sapere come ho fatto a convincere il tuo capo? È stato facile, gli ho detto che a prendere le cose sul serio e ad arrabbiarsi ci si accorcia la vita.
- Questo credo che lo sapesse già..
- Probabile, ma io gli ho detto di quanto.
- Tu sai quando morirà?
- Teoricamente sì, ma chi se lo ricorda.. Ho sparato una data a caso entro la fine dell'anno. Gli ho detto anche che questa era la sua ultima possibilità per far sì che quel doloretto che ha sentito al torace stamattina appena sveglio fosse solo un doloretto. È bastato.
- Almeno così sembra. Comunque non è questo che volevo chiederti.
- Oh! Tu probabilmente vuoi sapere perché ho scelto proprio te, avendo a disposizione i migliori.
- Io avrei detto "fra i migliori", ma comunque..
- Te lo dirò se farai un buon lavoro. Noi ci vediamo domani mattina all'indirizzo che ti ha dato il tuo capo. Cerca di essere puntuale e non passare dal centro perché ci sarà una fila per un tamponamento.
- Me ne ricorderò.

Prima relazione sull'andamento del progetto "U++" (19 Aprile)

Le cose vanno meglio di quello che sperassi: malgrado i suoi impegni, il Cliente trova sempre del tempo da dedicarmi e il mio lavoro procede spedito. Inoltre, a dispetto di una malcelata ritrosia iniziale, credo che finalmente si sia convinto dell'utilità di una revisione del codice e adesso è Lui stesso, e non più il Figlio, a spingere per una rapida conclusione. Due sono state finora le scoperte di maggior rilievo: la prima è che l'applicazione attuale è scritta in COBOL (il Cliente mi ha spiegato che l'ipotesi iniziale di utilizzare il FORTRAN era stata abbandonata dopo un primo tentativo e che in quel linguaggio è stato scritto solo il cervello degli ingegneri); la seconda è che Mandelbrot aveva ragione: l'Universo ha una struttura frattale (scelta, questa, che semplifica di molto la gestione di situazioni complesse tipo l'interazione fra gli agenti atmosferici, il rumore dei pedalò e gli incontri casuali con ex amanti nei grandi magazzini). Una mia proposta che ha incontrato l'approvazione del Cliente è di procedere per gradi, stendendo un'analisi generale completa, ma riscrivendo l'applicazione poco per volta, in modo da produrre il minimo disturbo possibile agli utenti e semplificando il lavoro di affinamento delle procedure. Ho scritto una relazione preliminare (che allego) e l'ho consegnata al Cliente: domani mi farà avere una sua opinione al riguardo.

Seconda relazione sul progetto "U++" (20 Aprile)

Nella mattinata odierna ho discusso la mia relazione preliminare con il Cliente, che nel complesso mi è sembrato soddisfatto dell'impostazione prescelta. Dopo qualche tentennamento, si è anche convinto che non è possibile fare dei paragoni fra i tempi di sviluppo dell'applicazione precedente e di quella nuova, sia per l'impossibilità di paragonare analisi strutturata e analisi orientata agli oggetti, sia per la difficoltà di comparare la misurazione attuale, in giorni/uomo, con quella precedente, in giorni/Dio. Al momento ho solo una preoccupazione, ovvero che qualcuno, da dietro le quinte, piloti gli umori del Cliente con fini non chiari. Dico ciò, perché tutti i dubbi e le perplessità da lui espresse finora sono largamente al disopra delle sue conoscenze tecniche. Se inizialmente pensavo che dietro a tutto questo ci fosse quel Figlio di cui ho già fatto menzione nella memoria inviatavi prima della mia partenza (il che mi avrebbe posto in una situazione oltremodo delicata in quanto, come tutti ben sappiamo, la mia stessa presenza qui è dovuta proprio ad un suo suggerimento e metterne in discussione la competenza sarebbe controproducente), ora sono ragionevolmente certo che si tratti di qualcun altro, anche se non so proprio né chi possa essere né quali possano essere i suoi scopi.

Terza relazione sul progetto "U++" (28 Aprile)

Mi scuso per il prolungato silenzio, ma le riunioni degli ultimi giorni sono state letteralmente massacranti e non ho avuto il tempo di mantenervi aggiornati sui più recenti sviluppi della situazione. Di contro, va detto che finalmente comincio ad avere un'idea un po' più chiara delle diverse esigenze funzionali e dei ruoli coinvolti nel progetto, il che è sicuramente un bene, specie perché il terreno, qui, comincia a scottarmi sotto i piedi. E non faccio per dire. Come certo ricorderete, nella mia precedente comunicazione avevo paventato l'esistenza di ingerenze occulte e, comunque, un dubbio che avevo avuto sin dall'inizio era: dato che il Cliente ha più volte affermato di non possedere grosse cognizioni tecniche in campo informatico, chi ha scritto a suo tempo la prima applicazione? Non certo il Figlio (il quale altro non è che uno smanettone con quattro conoscenze d'accatto mutuate dalle riviste del settore), né tanto meno il terzo membro del consiglio di amministrazione, che è quasi sempre in viaggio. Quindi, chi? Bene: adesso ho una risposta ad entrambi i quesiti e buone ragioni per sospettare che le due figure (quelle del manovratore occulto e dell'autore del codice) coincidano, ma non so se esserne contento o spaventato. Comunque è meglio raccontarvi tutto dall'inizio. Il Cliente decide di realizzare un'applicazione per la gestione dell'Universo (che sarebbe quella attualmente in produzione), così si mette a tavolino, butta giù l'analisi funzionale, aggiunge alcune regole di business (tipo: l'acqua va sempre in basso, di mamma ce n'è una sola, i negri hanno la musica nel sangue e via dicendo), poi passa all'implementazione. Parte con qualcosa di piccolo e di facile, ma il risultato che ottiene non lo soddisfa; inoltre, come molti creativi, non è particolarmente attratto dalla realizzazione pratica di quello che ha elaborato concettualmente, perciò decide di subappaltare il lavoro a terze parti e le crea contestualmente. I nuovi arrivati studiano l'analisi, definiscono il disegno della base dati, stabiliscono alcuni criteri di implementazione (si passa dal FORTRAN al COBOL) e finalmente cominciano a scrivere il codice. L'analisi, va da sé, è estremamente precisa e tutto andrebbe nel migliore dei modi se a un certo punto uno dei programmatori non cominciasse a inserire delle backdoor nel programma. Inizia quasi per scherzo (modifica il codice in modo da garantirsi l'imbattibilità a briscola e il possesso di Viale dei Giardini e Parco della Vittoria a Monopoli), ma poi ci prende gusto e comincia ad aggiungere modifiche sempre più sostanziali, coinvolgendo nell'operazione di inquinamento anche alcuni suoi colleghi. Alla fine, i suoi privilegi sono di poco inferiori a quelli dell'Amministratore del sistema. Reso spavaldo dall'impunità di cui ha goduto fino ad allora, si mette alla testa del suo gruppo di cialtroni e tenta di esautorare il Cliente con un colpo di mano, ma senza successo: il suo piano è subito scoperto e sia lui che i suoi seguaci sono trasferiti per punizione in una sede secondaria, un open space senza aria condizionata, dove d'estate fa un caldo assurdo. Li salva da un destino peggiore (la presenza, nell'ufficio, di colleghe di sesso femminile) una curiosa circostanza: c'è bisogno di loro per la manutenzione del programma. Infatti, anche se la congiura è sventata, i danni al codice rimangono e non c'è né il tempo di ricontrollare tutto né chi, a parte loro, lo passa fare. Si decide perciò di mettere in produzione l'applicazione così com'è e di procedere all'eliminazione delle anomalie a mano a mano che verranno alla luce: una scelta tanto rischiosa quanto necessaria, che porta ben presto ad una situazione paradossale in cui i congiurati diventano il punto di riferimento del Cliente per la correzione degli errori che loro stessi hanno generato e che seguitano a generare (un po' per vendetta, un po' per accrescere il proprio potere contrattuale) sfruttando i privilegi illegali che si sono garantiti. É facile capire con quanta poca gioia questi personaggi abbiano salutato il mio arrivo: anche se apparentemente masochista, la scelta del Cliente di riscrivere tutta l'applicazione si rivela adesso l'unica possibilità rimasta di eliminare il Male dal Creato. Ecco spiegate le ingerenze esterne, ecco spiegato il motivo. Fatemi gli auguri.

Quarta relazione sul progetto "U++" (1 Maggio)

Credete a me: i clienti buoni esistono solo per i commerciali; per i tecnici esistono solo clienti che non hanno (ancora) creato problemi. Ero così eccitato dall'idea di essere lo Strumento Divino che avrebbe eliminato il Male dall'universo ed invece eccomi qui, sprofondato nella più tetra depressione per colpa del Cliente e delle sue assurde fissazioni. Io pensavo, anzi, ero certo che nella nuova versione dell'applicazione la parola d'ordine sarebbe stata "Bene": con quale sorpresa ho scoperto invece che, anche in questa versione, l'esistenza sarà un'altalena fra le colline della moderata contentezza e gli abissi oceanici della malinconia. Stamattina ne ho parlato con il Cliente, ho cercato di farlo ragionare. Addirittura, visto che erano qui e che non avevano niente da fare, mi sono perfino fatto dare una mano da Schopenhauer e Bergson, ma invano. Mi ha risposto, seccato, di fare il mio lavoro e di non impicciarmi di questioni che vanno oltre la mia comprensione (per poi blandirmi perché lo aiutassi con i backup dopo che aveva cancellato per sbaglio due galassie). Nel pomeriggio sono tornato alla carica, convinto com'ero che le cospicue quantità di vin santo ingurgitate nel post-prandiale avessero favorevolmente influito sulla sua disponibilità, ma mi sbagliavo: mi ha ripetuto quanto aveva già detto nella mattina e, in più, mi ha attaccato un pistolotto di sapore vagamente taoista, il cui fine dichiarato era quello di illuminarmi sulla soggettività dei concetti di bene e di male. In un ultimo, disperato tentativo, ho ribattuto che la presenza del Male nel Creato è uno degli argomenti preferiti di coloro che tentano di dimostrare che Dio non esiste, ma è equivalso a darsi la zappa sui piedi: mi ha confessato di essere stato proprio lui a infondere simili pensieri nella mente dei suoi detrattori nella speranza, frustrata, che la gente si trovasse qualcun' altro da bestemmiare. Una volta di più, mi trovo a dover fronteggiare l'annosa dicotomia fra ciò che il cliente desidera e quello di cui realmente ha bisogno e, una volta di più, sarà ingrato compito dell'uomo informatico quello di venire apparentemente meno ai propri doveri al fine di produrre qualcosa di consono alle reali esigenze del committente.

Fax del Cliente (19 Maggio)

La presente per informarvi della nostra decisione di interrompere l'opera di porting del nostro sistema gestionale in linguaggio C++; una decisione sofferta, ma irrevocabile, cui siamo giunti avendo constatato che i principali difetti dell'applicazione precedente non avevano trovato una cura in questa nuova versione. Stando così le cose, abbiamo deciso di focalizzare i nostri sforzi piuttosto che su una rischiosa operazione di revisione, su un programma organico di formazione degli utenti, nella speranza che una maggiore consapevolezza delle problematiche di fondo del contesto di utilizzo possa correggere quelle che, a questo punto, consideriamo delle idiosincrasie congenite del sistema. Quale ricompensa dell'impegno da Voi profuso in questo progetto abbiamo pensato di risparmiare l'edificio in cui ha sede la Vostra società dal terremoto del 24 luglio p.v., ma siamo aperti a qualsiasi soluzione di Vostro gradimento, a patto che non contravvenga alle nostre politiche aziendali. Sfortunatamente, il Vostro personale distaccato presso di noi, è rimasto vittima dell'annosa dicotomia fra ciò che gli utenti di un sistema desiderano e ciò di cui realmente hanno bisogno e siamo certi che non avrete nulla in contrario se lo utilizzeremo come cavia per il nostro programma di rieducazione. Attualmente, comunque, gode di ottima salute e sembra non avere difficoltà ad integrarsi con il nuovo gruppo di lavoro cui è stato assegnato, nella sede distaccata del nostro CED.

Finito il corso di riqualificazione, il maestro Canaro non fu più lo stesso. Tornò alla sua società, ma vi rimase solo il tempo di dare le dimissioni. Fondò il nostro Ordine e cominciò a predicare la mistica della programmazione, ottenendo subito un grosso seguito.
I tempi erano maturi per il cambiamento: c’era stata la crescita prodigiosa di fine millennio e c’era stata la rovinosa caduta dell’11 marzo 2000. La vecchia guardia era stanca di dover dipendere dalle bizze della borsa e del marketing; i giovani volevano la Terra Promessa per cui avevano abbandonato gli studi classici; gli utenti volevano che la posta elettronica funzionasse.
La dottrina del maestro Canaro era semplice: riportare l’informatica in una torre d’avorio, accettarne la componente imponderabile ed elevarla da attività produttiva ad attività mistica. Basta con l’improvvisazione, basta con il time to market, basta con i prodotti inaffidabili: chi voleva scrivere codice doveva entrare in un Ordine monastico e seguire un lungo percorso di iniziazione, prima di poter cominciare a lavorare.
Furono in molti a vedere nel maestro Canaro “il vento che spazzerà via il fango”: la vecchia guardia fu ben felice di veder nuovamente riconosciuto il suo status di casta eletta; i giovani, che cercavano un riparo, lo trovarono all’interno dei monasteri; gli utenti seppero che le loro posta elettronica avrebbe funzionato e furono felici.
Ci fu anche una componente politica, a favorire il successo della dottrina predicata dal maestro Canaro. La società dipendeva ormai totalmente dai computer e i computer dipendevano dagli informatici. Se un giorno avessero deciso di coalizzarsi e di scioperare, avrebbero messo il Paese, se non il Mondo intero, in ginocchio.
Le psicopatologie tipiche degli informatici, la loro incapacità di gestire, se non addirittura di concepire una vita sociale, rendevano questa ipotesi molto poco probabile, ma era comunque un rischio troppo grosso per essere ignorato. Al contrario, l’indottrinamento degli informatici, la loro segregazione in una casta con forti componenti mistico-religiose, li avrebbero tenuti lontani dalle lusinghe dei sindacati e avrebbero reso l’ipotesi di uno sciopero improbabile quanto l’ipotesi di uno sciopero dei sacerdoti.


Gli insegnamenti del maestro Canaro non uscirono mai dall’ambito del software. Non nominò mai l’hardware, in nessuno dei suoi scritti; diceva che se un uomo configura un firewall è un informatico, se attacca due cavi è un elettricista. Una volta chiesi al maestro Canaro perché non avesse mai dato delle indicazioni sull’affidabilità fisica dei server.
“Se è per questo,” mi rispose “non nemmeno prodotto tabelle per il calcolo del cemento armato.” Solo anni dopo capii cosa intendesse dire.
Malgrado il suo disinteresse per ciò che lui chiamava: “le cose reali”, la rivoluzione culturale provocata dal maestro Canaro ebbe delle conseguenze anche per i produttori di computer. La maggior parte di loro fu lenta a percepire i cambiamenti in atto e pagò duramente la sua disattenzione, gli altri prosperarono.
Anche se il Maestro Canaro non prese mai una posizione definita nella disputa che contrappose i sostenitori della dottrina del Grande Veicolo (i mainframe) e quelli che erano invece favorevoli al Piccolo Veicolo (i PC casalinghi), alcuni alti prelati si dichiararono favorevoli al monoteismo dei mainframe e, alla fine, i sostenitori del politeismo furono sconfitti.
Negli uffici e nelle case, i PC vennero sostituiti da terminali e gli edifici ebbero tutti, oltre al garage e al locale caldaie, un’area CED. Il territorio fu suddiviso in diocesi, e ciascuna diocesi fu affidata a un diacono che aveva il compito di sovrintendere al corretto funzionamento dei diversi sistemi.
Sebbene noi, che gli eravamo vicini fin dall’inizio della sua predicazione, sapessimo che era il C++ il suo linguaggio di programmazione preferito, il maestro Canaro lasciò che fosse Java a diventare il linguaggio ufficiale della comunità, subendo senza replicare gli attacchi di coloro che lo accusavano di essersi venduto alla Sun. Le procedure esistenti furono tutte riscritte; gli ordini monastici che insegnavano il C++ divennero sempre di meno e alla fine non ce ne furono più.
Fu solo allora che il maestro Canaro mi parlò per la prima volta del C’hi++.


Le nuvole che oscuravano il cielo questa mattina sono scomparse, il cielo della notte trabocca di stelle. Sono cose che si notano, a mano a mano che si invecchia. Io le noto da quando ero bambino.

Quello che ti insegnerò non è illegale, ma è come se lo fosse.