Intervista a Joe Armstrong ideatore del linguaggio Erlang

Intervista di quasi quindici anni fa a Joe Armstrong ideatore ed inventore del linguaggio di programmazione Erlang.

J. Khaldi: La storia dello sviluppo di Erlang riflette una mentalità molto nordica, cioè, quella di lavorare sui progetti a lungo termine, programmare quasi tutto per avere alla fine i risultati desiderati. Allo stato attuale, Erlang/OTP è considerato un prodotto industriale. Si tratta di un progetto definitivo?
J. Armstrong: Dobbiamo distinguere tra Erlang e OTP. Erlang è un linguaggio di programmazione, mentre OTP è una piattaforma di sviluppo scritta in Erlang, in modo quasi simile al linguaggio C ed il sistema operativo UNIX. Ora ci sono molti sistemi operativi scritti in C, ma il C rimane un unico linguaggio. Posso immaginare molte altre piattaforme simili alla OTP per scrivere applicazioni , ma tutte scritte in Erlang.
Possiamo migliorare Erlang con delle piccole modifiche, ma l'aggiunta di cose nuove dovrebbe indurre all'eliminazione di altre. Diversamente, il linguaggio diventerà troppo complesso, difficile da imparare ed implementare . Il mio obiettivo è stato sempre quello di mantenere il linguaggio piccolo per facilitare il suo apprendimento. Se verrà aggiunta qualche novità, sarà solo per rendere il linguaggio più semplice e più chiaro. Ma nel frattempo, cercheremo sempre di togliere qualcosa.

J. Khaldi: Erlang/OTP è una piattaforma per sviluppare complesse applicazioni di telecomunicazioni ed è stata usata con successo per realizzare lo switch AXD301 (affidabilità al 99,99999%, 30-40 milioni di chiamate la settimana, il sistema di telefonia più grande nel mondo su rete ATM, 1.700.000 linee di codice Erlang). Possiamo dire che, finalmente, la crisi del software engineering, per quanto riguarda lo sviluppo di sistemi complessi, è risolta con l'utilizzo di Erlang/OTP? Sarebbe stato possibile sviluppare un sistema del genere in Java?
J. Armstrong: Io credo che il problema essenziale da risolvere nello sviluppo di qualsiasi software, indipendentemente dalle sue dimensioni, è quello di evitare la propagazione degli errori. Solo in questo modo possiamo sviluppare software sicuro.
Molti sistemi sono stati realizzati prestando più attenzioni all'hardware cercando di renderlo sicuro e ridondante nella speranza di ottenere un sistema più affidabile. Ma un hardware ridondante non aiuta quando il software smette di funzionare. Far girare lo stesso software bacato su due computer manderà in crash entrambi e non risolve il problema. E' da pazzi concentrarsi sull'hardware quando si tratta di sviluppare sistemi affidabili, visto che la maggior parte dei problemi è causata da bug nel software e non dall'hardware.
La filosofia di Erlang non è solo quella di prevedere i bug, ma di convivere con essi. Quando un errore si manifesta in qualche parte del sistema, viene notato e corretto da qualche altra parte dello stesso.
Per realizzare software affidabile dobbiamo creare un "dominio protetto", così, quello che accade in un programma non può propagarsi ad un altro. Molti sistemi operativi (SO) offrono una certa protezione isolando i programmi in processi separati. Purtroppo, i processi fanno parte dei sistemi operativi e non dei linguaggi di programmazione.
In Erlang il discorso è completamente diverso; i processi appartengono al linguaggio e non al sistema operativo. In più, sono molto più efficienti di quelli forniti dal SO e dai thread. I processi Erlang offrono la necessaria protezione dei programmi impedendo la propagazione di un bug.
Linguaggi come Java o il C++ non dispongono di propri processi, ma si appoggiano su quelli del sistema operativo che sono pesanti e difficili da creare in confronto di quelli offerti da Erlang. Creare 100.000 processi in Java è, semplicemente, impossibile.
In Java e C++ è estremamente difficile limitare la propagazione dei bug, perciò, credo che sia molto difficile sviluppare software complesso in questi linguaggi. Sarebbe possibile se avessimo molto tempo e grandi budget a disposizione, ma la cosa non sarebbe ugualmente raccomandabile.

J. Khaldi: Il modello parallelo di Erlang è quello di basarsi su processi creati dal linguaggio (efficienti ed illimitati). Il modello di Java è basato sui thread. E' questo il motivo principale che permette di sviluppare software parallelo più efficiente in Erlang e non in Java?
J. Armstrong: Assolutamente. Erlang appartiene alla classe dei linguaggi che comunicano con "puri messaggi". Non ci sono semafori, né parti critiche, né puntatori, né metodi sincroni, né mutex, né dati condivisi, ma tutto avviene tramite il passaggio di messaggi. Visto che nulla è condiviso, tutto viene copiato con molti vantaggi:

A questo punto sembra che copiare i dati da una parte all'altra dovrebbe rallentare il sistema, ma i fatti dicono che è vero il contrario. I programmi sviluppati in Erlang sono molto più efficienti dei relativi scritti in altri linguaggi appena si raggiunge un numero elevato di processi.

J. Khaldi: Java è fallito clamorosamente sul lato client, ma la situazione attuale lo dà per vincitore sul lato server e nello sviluppo di applicazioni distribuite. Comunque, ha già molti competitori ed Erlang potrebbe essere il prossimo rivale di Java e degli altri. Come vedi il futuro di Java se Erlang diventa più popolare?
J. Armstrong? Questa faccenda mi sorprende. Tempo fa, ho avuto una discussione riguardante i linguaggi di programmazione dove qualcuno ribadiva "ogni linguaggio di successo deve essere buono a fare qualcosa". Così, il Visual Basic è buono per la programmazione visuale... Ho pensato subito che Java fosse unicamente buono per scrivere agenti software lato client per l'esecuzione di codice remoto. Questo è l'unico campo dove Java potrebbe avere successo. Proporlo come linguaggio di sviluppo di applicazioni server è completamente fuori luogo.
Per loro natura, le applicazioni server controllano un gran numero di attività parallele, qualcosa che Java non è assolutamente in grado di fare, mentre Erlang eccelle in cose del genere.

J. Khaldi: Erlang è stato realizzato per sviluppare, prevalentemente, applicazioni di telecomunicazioni, in modo particolare per telefonia. Parallelismo, estrema affidabilità, possibilità di sostituzione del codice a caldo (aggiornare un software senza fermare la sua esecuzione)... Credo che pochi programmatori siano interessati allo sviluppo di applicazioni per telefonia. E' possibile usare Erlang per sviluppare un altro genere di applicazioni?
J. Armstrong: Assolutamente sì. Erlang è stato usato per sviluppare molte applicazioni che non hanno nulla a che vedere con la telefonia.
Qualche anno fa eravamo del parere che il software di un web server è molto simile a quello di un switch per telefonia. Entrambi servono un gran numero di utenti simultaneamente, debbono essere tolleranti verso gli errori, debbono funzionare per 24 ore al giorno 365 giorni l'anno... La similitudine è sorprendente.
Il software degli switch in telefonia è talmente affidabile che si scriverebbero articoli sui giornali nel caso di un suo crash. L'AXD301, per esempio, uno switch ATM scritto in Erlang dalla Ericsson è affidabile al 99,9999999% (sono nove nove!). L'affidabilità con la possibilità di sostituire il codice a caldo, mentre il sistema gira, è molto comune nelle applicazioni di telecomunicazioni, ma poco comune nelle applicazioni web.
Abbiamo fatto delle prove confrontando YAWS (Yet Another Web Server) con Apache e abbiamo costatato che a basso carico entrambi i web server hanno un comportamento simile. Ma quando il carico diventa pesante, Apache va in crash mentre YAWS continua a funzionare senza problemi.
Così, io penso che la morale sia quella di portare l'esperienza dell'alta affidabilità dello sviluppo delle applicazioni di telecomunicazioni nel mondo Internet.

J. Khaldi: Oggigiorno, gli strumenti comunemente utilizzati nello sviluppo di applicazioni web consistono in un RDBMS (Relational Database Management System) unitamente ad un linguaggio di scripting come estensione ad un web server, ai quali aggiungere estensioni sviluppate in C per far comunicare il linguaggio di scripting col database server. Erlang, Mnesia e YAWS risolvono elegantemente questo problema con una soluzione omogenea basata su un unico linguaggio: Erlang. Che ne pensi di un frame con plug-ins per lo sviluppo di applicazioni web strettamente basato su questo trinomio, a la Zope?
J. Armstrong: Credo che sia una grande idea. Nelle nostre prove, il web server Apache comincia a comportarsi in modo strano appena si raggiungono 4.000 connessioni simultanee; YAWS continua a funzionare senza grossi problemi con 10.000 connessioni.
Poi, appena si inizia a scrivere script CGI le cose penderanno ancora di più a favore di Erlang. Qui la protezione tra i processi è la chiave dietro le performance. Dobbiamo creare velocemente molti processi protetti. Le script CGI sono poco sicure e ciascuna gira come processo isolato creato dal sistema operativo. Questo è l'unico modo di proteggerle ed è estremamente inefficiente.
Meravigliosamente, i contenuti dinamici che YAWS genera sono più veloci da servire di quelli statici. Il segreto sta nel fatto che è più veloce creare una pagina web che leggerla da disco.

J. Khaldi: Erlang è eccellente per lo sviluppo lato server e per scrivere applicazioni "invisibili", ma quando arriviamo al desktop è quasi inutilizzabile; GS (Graphics System) è lento ed incompleto. Avete qualche piano per migliorare gli strumenti di sviluppo di applicazioni desktop?
J. Armstrong: Ci sono diversi strumenti per migliorare l'aspetto grafico. Ci sono sistemi grafici basati su GTK, SDL con qualche lavoro già fatto per un collegamento allo stesso protocollo X (sistema server X Window di UNIX) . Il problema è che nessuno di questi collegamenti fa parte della distribuzione ufficiale di Erlang.
Un meraviglioso sistema scritto in Erlang è Wings3D. Si tratta di un programma di modellazione solida open source e che si appoggia su SDL e OpenGL. Si tratta veramente di qualcosa di molto interessante.

J. Khaldi: Erlang/OTP è enorme, sembra un sistema operativo. Perché non separare l'interprete dagli altri componenti, così da ottenere un sistema run-time dell'ordine del megabyte da distribuire insieme alle applicazioni desktop/client?
J. Armstrong: Di nuovo, questo è stato già fatto, ma non fa parte, finora, della distribuzione ufficiale.
Mi sembra che in futuro ci saranno implementazioni di Erlang che saranno distribuite separatamente.
Se pensiamo a Linux, abbiamo uno stesso kernel con diverse distribuzioni e ciascuna utilizza un suo particolare insieme di strumenti. Credo che questo sarà un buon modello per Erlang, cioè dividerlo in diverse distribuzioni specializzate e ciascuna con i propri tool.

J. Khaldi: Credo che uno dei migliori componenti della OTP sia Mnesia. Un DBMS maturo, completo, distribuito e molto ben realizzato. E' stato scritto per intero in Erlang con quasi solo 20.000 linee di codice. Tutti sappiamo che il mercato dei DBMS è enorme, dinamico e lucroso. Avete qualche piano per migliorare ulteriormente Mnesia in modo da farlo diventare un'alternativa ad Oracle, BD2, Sybase e MS SQL Server?
J. Armstrong: Che io sappia non c'è nessun piano a proposito. Mnesia è piuttosto diverso dai DBMS citati. Il suo design originale fu quello di un database residente in memoria e distribuito per servire applicazioni real-time.

J. Khaldi: Nel documento di Erlang si legge: "Erlang è un linguaggio di programmazione con caratteristiche tipiche di un sistema operativo: processi paralleli, scheduling, gestione della memoria, networking...". Quanto siamo lontani da un Erlang/OS?
J. Armstrong: Non credo che il mondo oggi sia interessato ad un nuovo sistema operativo. Sarei piuttosto interessato a far funzionare meglio quello che c'è e non di creare un nuovo SO. Comunque non sarebbe stato complicato scrivere uno nuovo, abbiamo già la maggior parte dei componenti necessari.

J. Khaldi: Nel tuo famoso e divertente articolo "Perché la OO (programmazione ad oggetti) non funziona", hai dato alcuni convincenti esempi per sostenere la tua tesi. Perché la FP (programmazione funzionale) non è così diffusa tra i programmatori e dove non funziona?
J. Armstrong: Ci sono due modi di vedere la FP. a) un bella maniera di programmare, oppure, b) una branca della pura matematica. Ora, molti libri che parlano della FP la presentano come nel punto b) e così fanno allontanare le persone. Ci sono comunque molti libri che la trattano come in a).
I programmi funzionali, o almeno una parte di essi, hanno la proprietà di poter essere utilizzati per dimostrare alcune cose anche quando queste richiedono molta matematica. Questa caratteristica che normalmente dovrebbe essere un punto di forza è resa meno popolare e poco utilizzata. E' una bizzarra concezione. Trovo piuttosto strano che qualcuno cerchi di imparare il C++ o il Perl, che nella mia opinione non sono così semplici come Erlang o Scheme.
Molto del materiale disponibile sui linguaggi funzionali è rivolto ai programmatori o agli studenti di informatica. Difficilmente si trovano libri semplici che introducano in modo non accademico ai linguaggi funzionali.

J. Khaldi: La Ericsson è il leader mondiale nella tecnologia degli switch ATM con uno share dell'11% (ho preso questo dato da una tua conferenza al MIT). Credo che questo successo sia in buona parte da attribuire ad Erlang. Perché la Ericsson ha dato gratuitamente la sua magica arma alla concorrenza?
J. Armstrong: La Ericsson diede Erlang nella speranza che si diffondesse e diventasse popolare. Questo ha a che fare con l'intero business. La Ericsson costruisce hardware e sistemi di telecomunicazioni, non è una software house. Si è cercato di diffondere Erlang per non isolarlo e rimanere gli unici utenti di questi strumenti.

J. Khaldi: Alla fine dove volete arrivare? Ossia, con Erlang siamo all'inizio
J. Armstrong: In poche parole, l'obiettivo è quello di isolare i componenti che comunicano tramite canali. Personalmente credo che il problema più importante da risolvere oggi sia quello di "far funzionare le cose insieme". Per fare questo abbiamo bisogno di soddisfare una grande esigenza: l'isolamento. Due programmi che girano sulla stessa macchina debbono essere isolati, così, un errore nell'uno non può propagarsi all'altro.
Vado ancora oltre e dico che debbono essere isolati come se girassero su due computer separati su due continenti diversi.
Se si cerca di far funzionare due programmi sulla stessa macchina, bisogna farli girare in due processi separati e lasciarli comunicare tramiti canali non-blocking di I/O. Questa architettura funziona bene in un sistema distribuito, così il design di un programma per un singolo processore o un intero network diventa lo stesso.
Se ora parliamo di sistemi e non di singoli programmi, dobbiamo realizzare che non esiste un unico linguaggio che possa dominare il mondo. Ciascuno ha il suo linguaggio preferito e non possiamo aspettarci che cambi facilmente linguaggio. Così, componenti diversi verranno scritti in linguaggi diversi.
Quello che vogliamo vedere in futuro è un insieme di componenti scritti in differenti linguaggi di programmazione che comunichino scambiandosi semplici messaggi. La sequenza di questi messaggi che passa da un componente all'altro dovrebbe essere soggetta ad un "contratto". Questi contratti sono controllabili in modo indipendente e fuori dal funzionamento del mio componente.
I componenti stessi dovrebbero essere visti come "scatole nere" che rispettino i contratti e rimane del tutto irrilevante come sono stati programmati.
I messaggi tra i componenti, nonché l'ordine nel quale sono inviati, dovrebbero essere stabiliti a priori e questo verrebbe realizzato in un linguaggio neutrale. Questi obiettivi sono del tutto simili a quelli proposti da XML, XML-schemas, SOAP e WSDL. Vorrei vedere qualcosa di più semplice, ma soprattutto molto più semplice da programmare.
Un'alternativa (che ho chiamato UBF) prevede una tale infrastruttura per creare un'architettura basata su componenti.
Questa è la direzione che mi piace prendere. Usare Erlang per sviluppare componenti, ma bisogna assicurarsi che i componenti possano collaborare dopo aver stabilito le modalità d'interazione.
In questo modo si possono scrivere componenti nel linguaggio desiderato, specificarli in UBF e, di conseguenza, farlo sapere solo di seguito agli altri.