L'ingresso nel mondo dei computer

A volte mi chiedo quando sia cominciato, in realtà, il mio cammino nella ricerca. Non esiste un momento preciso, un giorno che abbia significato una scelta consapevole e definitiva. È stata piuttosto una corrente lenta, spinta dal bisogno di capire, di strutturare e di portare ordine in un dominio che, all'inizio, mi sembrava più tecnico che intellettuale.

Sono arrivato alla Facoltà di Energetica per una scelta in gran parte pragmatica. Dopo il primo anno fui selezionato per la nuova sezione di Automatica, fondata nel 1962, e questo cambiamento fu, guardando indietro, una di quelle svolte del destino che cambiano discretamente un'intera vita. Negli ultimi anni di studi seguii corsi di calcolatori analogici e digitali, e la mia tesi, coordinata da Ivan Sipoș, aveva come tema la progettazione di un calcolatore numerico da tavolo.

Nella Romania degli anni '60, in un panorama tecnologico modesto e rigido, i computer avevano per me il fascino di mondi artificiali, ordinati secondo regole più chiare della realtà immediata. Il progetto di tesi mi avvicinò all'hardware, ma non sarebbe stato l'hardware a definire il mio cammino. Dopo l'assegnazione alla Fabbrica di Elementi di Automazione e l'esperienza del distacco all'Electromagnetica, cominciai a cercare una via verso un dominio più vicino alle mie preoccupazioni intellettuali.

Il legame con Ivan Sipoș fu decisivo. Egli parlò con il professor Cornel Penescu e io finii per sostenere un concorso per un posto da assistente. In quel momento il Politecnico attraversava trasformazioni importanti: la sezione di Automatica era diventata la Facoltà di Automatica e poi, nel contesto della crescente importanza dell'informatica, si profilava la Facoltà di Automatica e Informatica, con una nuova Cattedra di Informatica.

La Cattedra di Informatica e il cambiamento di direzione

Entrai alla Cattedra di Informatica nel 1970, poco dopo la sua fondazione, sotto la guida del docente Mircea Petrescu. All'inizio il mio futuro sembrava legato alla progettazione di calcolatori, in continuità con la tesi di laurea. Ma parallelamente seguivo i corsi della Facoltà di Matematica, specializzazione Macchine di calcolo, e lì l'accento cadeva sempre più su programmazione, linguaggi e fondamenti.

Questa seconda formazione fu decisiva. Mi mostrò che il software non è solo un'appendice della macchina, ma un dominio a sé, con i propri concetti, modelli e problemi. Quando alla Cattedra di Informatica si pose il problema di avviare progetti software, aderì con entusiasmo e abbandonai senza rimpianti la direzione iniziale della progettazione hardware.

Da qui comincia, in realtà, il mio primo filo coerente di ricerca: il tentativo di capire come il programma possa essere liberato dalla dipendenza eccessiva dalla macchina concreta e come possano essere costruiti strumenti che rendano la programmazione più rigorosa, più portabile e più accessibile.

La liberazione del software

Guardando indietro, la mia prima grande battaglia nell'informatica fu la battaglia per la liberazione del software dalla dipendenza dall'hardware. Negli anni '70, il mondo dei calcolatori era diviso in fortezze isolate: ogni sistema di calcolo aveva i propri linguaggi, convenzioni, rappresentazioni e limiti. Un programma scritto per una macchina era, nella maggior parte dei casi, prigioniero di quella macchina.

I linguaggi di alto livello — FORTRAN, COBOL, LISP, ALGOL 60 e altri — avevano già aperto un ponte su questa frammentazione. Permettevano di formulare algoritmi in una forma più vicina al pensiero umano e meno dipendente dal codice assembly. Ma la portabilità reale era ancora lontana. La ricompilazione, le differenze di sistema operativo, le rappresentazioni interne e la mancanza di standard stabili mantenevano il programma legato alla piattaforma per cui era nato.

Per me, il problema della portabilità non era solo tecnico. Aveva una valenza metodologica: se un programma esprime un'idea, allora quell'idea dovrebbe poter attraversare le macchine, le generazioni tecnologiche e le circostanze concrete dell'implementazione. Questa intuizione tornerà sempre nella mia attività successiva.

Una passione per i sistemi formali

Alla Facoltà di Matematica dell'Università di Bucarest, i corsi di linguaggi di programmazione e il contatto con la teoria dei linguaggi formali mi attrassero in modo decisivo. ALGOL 60, BNF, le grammatiche di Chomsky e la semantica dei linguaggi cambiarono il modo in cui guardavo alla programmazione. Non si trattava più solo di scrivere programmi che funzionano, ma di capire i linguaggi come oggetti formali e come strumenti di costruzione intellettuale.

Nel 1972 cominciai a frequentare i corsi serali di Teoria degli automi tenuti dal professor Grigore Moisil. Conservo il ricordo delle camminate dopo il corso, quando lo accompagnavo lentamente sul viale discutendo di mille argomenti. Era uno di quegli incontri rari in cui le idee non rimangono nell'aula ma continuano per strada, in cammino, in conversazione.

Moisil mi incoraggiò a scrivere il mio primo articolo, partendo dalla mia tesi di laurea in Matematica, dedicata alla semantica dei linguaggi di programmazione attraverso il Metodo Vienna. L'articolo non arrivò alla pubblicazione. Una critica matematica dura, legata a una definizione circolare, mi scoraggiò allora. Guardando indietro, capisco che quel fallimento fu anch'esso formativo: mi insegnò che l'intuizione non è sufficiente, che la forma deve essere condotta fino in fondo, e il rigore non perdona l'entusiasmo incompleto.

Il programma UNDP–UNESCO e l'infrastruttura di calcolo

Tra il 1969 e il 1973, la nostra cattedra beneficiò di un programma UNDP–UNESCO destinato alla specializzazione del personale docente nel campo dell'elaborazione dati. Il supporto dell'Università Tecnica di Darmstadt fu essenziale. Ricevemmo calcolatori IBM 1130 e IBM 1401, nonché un minicalcolatore HP 2116 B. Per noi non erano semplici attrezzature, ma ingressi concreti in un mondo tecnologico che la Romania stava appena costruendo.

In parallelo, il Centro di Calcolo dell'Università di Bucarest, creato attorno al professor Moisil e dotato di un IBM 360/30, era diventato un focolaio di cultura informatica. Lì si formarono molti di quelli che avrebbero contato nei primi decenni dell'informatica romena. Al Politecnico, la ricezione del calcolatore FELIX C-256 permise il passaggio a un'attività didattica e pratica più consistente.

Nel 1973, insieme a Petre Dimo e con il supporto di altri colleghi, cominciammo a insegnare la Programmazione dei calcolatori in FORTRAN. Il numero di programmi inviati al Centro di Calcolo crebbe rapidamente, e il ciclo schede perforate – esecuzione – errore – correzione diventava laborioso. Da questa necessità pratica nacque il progetto SISIF.

SISIF e la programmazione conversazionale

SISIF fu concepito come un sistema conversazionale orientato FORTRAN, ad accesso multiplo, destinato alla verifica e correzione dei programmi prima della loro perforazione su schede. Invece di scoprire gli errori solo dopo un lungo ciclo di elaborazione, l'idea era che il programma venisse inserito e verificato in modo interattivo, riga per riga, dalla console.

Nel quadro del progetto, mi occupai insieme a Florica Moldoveanu dell'analizzatore sintattico FORTRAN. Purtroppo, la mancanza di una descrizione formale della sintassi FORTRAN mi impedì di usare pienamente gli strumenti della teoria dei linguaggi formali, proprio quelli che mi attraevano di più. Fu il mio primo confronto concreto con la distanza tra l'eleganza formale e la realtà tecnica di un linguaggio effettivamente usato.

SISIF fu importante non solo come progetto didattico, ma anche come apertura verso problemi di time-sharing, processi paralleli, sincronizzazione e interazione uomo-calcolatore. Da un bisogno molto pratico — risparmiare schede e ridurre i cicli di correzione — nasceva un campo di domande teoriche.

L'ingresso al dottorato

Nel 1973 entrai al dottorato sotto la guida di Mircea Petrescu. Il titolo stabilito per la tesi fu "Implementazione di un linguaggio per un sistema interattivo di elaborazione dei dati". L'ispirazione veniva dalle preoccupazioni del professor Louis Bolliet dell'Università di Grenoble, esperto nell'ambito del programma UNDP, e dall'interesse per l'interazione uomo-calcolatore.

Considerata la mia formazione matematica, la direzione della ricerca sembrava naturale: teoria dei linguaggi formali, compilatori, sintassi, semantica e sistemi interattivi. In realtà la tesi fu spesso messa in secondo piano da corsi, contratti, progetti e obblighi istituzionali. Ma proprio questa pressione della realtà fece sì che il tema maturasse a contatto con problemi concreti.

ALGOL 60 e l'idea del compilatore conversazionale

ALGOL 60 era un linguaggio apparso prima del suo tempo. I blocchi, gli scope, la ricorsività, le funzioni annidate e la definizione della sintassi tramite BNF lo avevano trasformato in un riferimento teorico maggiore. Non era un linguaggio comodo per le applicazioni commerciali dell'epoca, ma era un linguaggio attraverso cui l'informatica imparava a pensare se stessa.

Un compilatore conversazionale per ALGOL 60 richiedeva la destrutturazione del classico processo di compilazione. L'analizzatore sintattico doveva poter lavorare in modo incrementale, memorizzare il contesto di ogni sessione, gestire più utenti e offrire messaggi di errore sufficientemente precisi per la correzione online dei programmi. Per una sola persona era un progetto troppo ambizioso.

Anche se non arrivai all'implementazione completa di un tale compilatore, il tema fu fecondo. Mi obbligò a pensare alla relazione tra linguaggio, ambiente di programmazione, utente e processo di sviluppo. In questa tensione tra ideale e realizzabile si formarono molte delle domande che torneranno più tardi nelle mie ricerche di ingegneria del software.

La portabilità dei programmi

Sullo sfondo delle esperienze con SISIF si costruì il primo filo coerente della mia ricerca: la portabilità dei programmi. In un contesto dominato da incompatibilità tra macchine, la portabilità era il tentativo di conferire al software uno statuto più libero, capace di migrare da un'architettura all'altra senza riscrittura integrale.

Attorno a questa idea si formò gradualmente un piccolo gruppo di colleghi e studenti. I problemi di laboratorio, apparentemente concreti e limitati, cominciarono a trasformarsi in articoli. Cercammo di definire cosa significa portabilità, quali ostacoli tecnici la limitano e quali metodi possono essere usati per ottenerla: codice intermedio, macchine astratte, interpreti, bootstrap, macroelaborazione.

BCPL, INTCODE e la prima scuola di portabilità

BCPL, il linguaggio creato da Martin Richards a Cambridge, fu per noi una rivelazione. Concepito come linguaggio procedurale, strutturato e facile da implementare, BCPL aveva un'importanza che andava oltre il suo utilizzo immediato: anticipava, per semplicità e per i meccanismi di implementazione, un'intera cultura della portabilità. Da esso nascerà, attraverso il linguaggio B, il linguaggio C.

Nel 1974, Mariana Necula portò dall'Inghilterra, su nastro perforato, il sorgente del compilatore BCPL in una forma destinata al porting. L'idea centrale era l'uso di un codice intermedio — INTCODE — e di un piccolo interprete scritto per la macchina target. Attraverso questa procedura di half-bootstrap, il compilatore poteva essere portato rapidamente su una nuova piattaforma, prima dell'esistenza di un generatore di codice nativo.

Per il calcolatore FELIX bisognò implementare l'interprete INTCODE. Questo compito, apparentemente modesto, ebbe per me un'importanza concettuale maggiore: un programma scritto in un linguaggio astratto poteva prendere vita in un ambiente tecnico completamente diverso, se esisteva lo strato minimo capace di interpretare la sua forma intermedia. La portabilità non era più uno slogan, ma una tecnica effettiva.

Attorno a BCPL si formò un piccolo laboratorio. Studenti e colleghi parteciparono all'implementazione, al testing, ai confronti tra compilatori e alla redazione di articoli. Da questa esperienza nacque una cultura di laboratorio in cui la costruzione di software, l'analisi formale e la pubblicazione dei risultati si alimentavano reciprocamente.

Guardando indietro, BCPL e INTCODE rappresentarono il mio primo incontro serio con l'idea di macchina astratta come strumento di liberazione del programma dalla macchina fisica. Quest'idea tornerà, in una forma molto più matura, nei miei lavori successivi sulla progettazione sistematica dei prodotti software.

STAGE-2 e la macroelaborazione

Nello stesso periodo entrai in contatto con STAGE-2, il macroprocessore universale sviluppato da W. Waite. Se BCPL e INTCODE rappresentavano la direzione del codice intermedio e della macchina astratta, STAGE-2 portava in primo piano la macroelaborazione come strumento generale di trasformazione dei testi e di costruzione di strumenti software.

Un macroprocessore copia un flusso di ingresso e produce un flusso di uscita, applicando regole di sostituzione, riscrittura e generazione. STAGE-2 portava questa idea a un livello notevole di generalità. Era indipendente dal linguaggio sorgente e, in larga misura, dalla piattaforma. Poteva essere usato per estensioni di linguaggio, generazione di codice, configurazione di programmi e costruzione di traduttori.

Ricevetti da Waite una versione universale e la documentazione necessaria, e insieme a studenti molto capaci realizzammo sul FELIX la procedura di half-bootstrap. Ancora una volta, la portabilità appariva non come proprietà passiva, ma come processo attivo: un nucleo minimo generava, attraverso trasformazioni controllate, una versione completa dello strumento.

STAGE-2 fu per me un ponte tra portabilità e le future preoccupazioni di ingegneria del software. L'idea di trasformare sistematicamente descrizioni, forme intermedie e frammenti di programma anticipava, in modo ancora non formulato, il mio interesse successivo per il processo di progettazione come successione di trasformazioni controllate.

Janus e l'idea del linguaggio intermedio

Un'ulteriore esperienza con la portabilità mi fu offerta da Janus, un altro strumento proposto da Waite. Janus era pensato come linguaggio simbolico per le informazioni trasmesse dalla fase di analisi di un compilatore ai generatori di codice. Mentre STAGE-2 era un macroprocessore generale, Janus si avvicinava all'idea di un linguaggio intermedio indipendente dal linguaggio sorgente e dall'architettura target.

Il tema dell'implementazione di Janus lo proposi a Dan Mânduțianu per la tesi di laurea. L'implementazione fu portata a termine, ma la ricerca non continuò con il potenziale che meritava, perché altri progetti diventarono urgenti. Anche così, Janus consolidò nella mia mente l'importanza delle forme intermedie e delle infrastrutture capaci di trasportare il senso di un programma da un contesto tecnico a un altro.

LPTR e la maturazione tecnica

Nella seconda parte del decennio, le preoccupazioni per la portabilità e per la tesi furono parzialmente interrotte dal contratto con ICI per la realizzazione del compilatore LPTR — Linguaggio Per Tempo Reale — per il minicalcolatore romeno Independent, compatibile con la famiglia DEC PDP-11. LPTR era una variante semplificata del linguaggio RTL/2, destinato alle applicazioni in tempo reale.

Il contratto prevedeva la realizzazione di un compilatore che doveva essere incluso nella Biblioteca Nazionale di Programmi. Il collettivo del Politecnico, guidato da me, progettò e implementò il compilatore. Dopo modifiche alla sintassi, portai il linguaggio a una grammatica LL(1), che permise l'analisi sintattica discendente. La grammatica fu attribuita per l'analisi semantica, e la generazione di codice fu effettuata in MACRO, il linguaggio assembly del minicalcolatore Independent. Il compilatore fu scritto in C.

Per me, LPTR significò una maturazione tecnica e manageriale. Non si trattava più solo di un esperimento di laboratorio o di uno strumento didattico, ma della conduzione di un team, di un prodotto che doveva essere validato, consegnato e integrato in un circuito istituzionale. Questa esperienza mi preparò, forse senza che me ne rendessi conto, alle preoccupazioni successive sulla metodologia dello sviluppo software e sul management dei progetti.

Il bilancio degli anni '70

Gli anni '70 furono fondamentali per la mia identità di ricercatore e professore. Passai dal fascino iniziale per i calcolatori alla comprensione del software come dominio autonomo, poi alla portabilità, ai linguaggi formali, ai compilatori, ai macroprocessori, ai sistemi conversazionali e ai progetti tecnici con finalità concrete.

Visti separatamente, SISIF, BCPL, STAGE-2, Janus e LPTR sembrano progetti diversi. Visti insieme, costituiscono un'unica direzione: la ricerca di forme attraverso cui il programma possa diventare più libero, più esplicito, meglio strutturato e meno dipendente dalle circostanze hardware del momento. Questo fu il nucleo della mia prima fase di ricerca.

Allo stesso tempo, questi anni mi mostrarono i limiti del lavoro individuale. I progetti importanti si fanno con le persone: colleghi, studenti, mentori, tecnici, partner istituzionali. Cominciai a capire che la ricerca non è solo un'avventura intellettuale, ma anche una forma di costruzione collettiva.

Negli anni '80, questa esperienza si trasformerà gradualmente in una preoccupazione più ampia per la progettazione sistematica dei prodotti software, per i metodi di sviluppo, l'interforma, la macchina astratta e l'integrazione degli strumenti. Ma la radice di queste preoccupazioni è qui, negli anni '70: nella lotta con le schede perforate, con i calcolatori incompatibili, con i linguaggi difficili da formalizzare e con il desiderio di dare al software una libertà maggiore di quella che la tecnologia del momento permetteva.