Intervista a Francesco Cesarini di Erlang Solutions

Francesco: Nel '94, mentre ero studente di informatica presso l'Università di Uppsala, il professore e' entrato in aula e ha detto: "Questo e' il libro, leggetelo! Questi sono gli esercizi, fateli!". Poi ha incominciato a parlarci degli orrori della programmazione parallela: deadlocks, shared memory, critical sections, etc. Il libro in question era la prima edizione di "Concurrent Programming in Erlang" e gli esercizi si basavano su un mondo virtuale fatto di carote, conigli e lupi. Le carote crescevano, e venivano mangiate dai conigli. I lupi mangiavano i conigli. Se i lupi e i conigli mangiavano tanto, si moltiplicavano. Se non mangiavano, morivano. I conigli comunicavano con altri conigli entro un certo raggio ogni qualvolta trovavano carote o avvistavano lupi. I lupi facevano lo stesso con gli altri lupi, avvertendoli della presenza dei conigli. Lo scopo dell'esercizio era quello di bilanciare la simulazione, giocando con i parametri a disposizione. Ho impiegato 40 ore a risolvere il problema. Ogni lupo e coniglio corrispondeva ad un processo e ricordo ancora la meraviglia di quando, avendo fatto un "ps -ef", mi son ritrovato davanti un solo thread, quello della macchina virtuale, e non un thread per ogni animale.

Qualche mese dopo, studiando programmazione OO, mi hanno dato lo stesso problema da risolvere. Questa volta eravamo in due a lavorare insieme usando Eiffel, un linguaggio OO molto interessante. Pur avendo riutilizzato molti degli algoritmi, abbiamo impiegato 60 ore a completate il lavoro, 120 in totale. Il triplo del tempo! E' stato allora che mi sono reso conto di come la scelta di un linguaggio di programmazione adatto al problema che si deve risolvere possa aumentare la produttività di un team di sviluppatori. Ho preso il telefono e chiamato Joe Armstrong - l'inventore di Erlang - chiedendo se c'era la possibilità di un tirocino presso il laboratorio di ricerca software della Ericsson. Da li, sappiamo come e' andata a finire.

R:Ti ringrazio, ma chiamandomi una "figura internazionale riconosciuta in tutto il mondo" mi metti in imbarazzo. Non ho ancora avuto l'opportunità di conoscere Massimo, ma suppongo che, come me, sia una delle tante persone cui piace condividere la propria conoscenza con gli altri, insegnando e scrivendo libri, con passione per il proprio lavoro e per tutto cio' che si fa. Questo e' il profilo in cui mi riconosco e spero possa dare ispirazione ad altri.

La situazione in Italia e' tragica. Il consiglio migliore che posso dare e' quello di imparare una seconda e, se possibile, persino una terza lingua per poter interagire e facilitare i contatti con altri Paesi dove l'economia e piu' attiva ed il sistema meno corrotto. E da li, innovazione, imprenditoria e passione. Lamentarsi o dare la colpa a terzi non crea lavoro. Bisogna cambiare il modo di fare e trovare modi alternativi per  uscire da questo buco.

Come software open source, io direi RabbitMQ, Riak, MongooseIM (riscrittura di Ejabberd) e CouchDB sono i progetti più usati. Prodotti non open source ma più conosciuti includono WhatsApp, Chef e il sistema di fatturazione di Klarna. Erlang e' il motore di GitHub Pages e di software di aziende come OpenX, AdRoll e AdTech (AOL) che ogni giorno servono miliardi di annunci su siti web. O di sistemi SMS. In Inghilterra, la maggior parte delle votazioni televisive passano tramite sistemi Erlang. Il 40% del traffico dati degli smartphones e' controllato da Erlang, visto che nell'infrastruttura Ericsson (che ha il 40% del mercato mondiale) il GGSN, il SGSN ed il MME che controllano sistemi GPRS, 3G ed LTE sono tutti implementati in Erlang.

Non sei il primo a dirlo. Credo che molto dipenda dagli altri linguaggi di programmazione cui uno sviluppatore e' stato esposto ed e abituato ad usare. Quando ho imparato Erlang conoscevo LISP, Prolog, ML e C e non ho avuto alcun problema con la sintassi. La sintassi di un linguaggio e' un modo di "impacchettare" il prodotto. Qualcuno preferisce una confezione semplice, altri la preferiscono colorata, variopinta. C'e' poi chi preferisce una confezione con una foto. Quello che e' importante non e' tanto la confezione di un linguaggio (la sintassi), ma il contenuto (la semantica). Erlang ha come contenuto processi light-weight, assenza di memoria condivisa, passaggio di messaggi asincrono, canali d'errore dedicati ed asincroni, supporto nativo per la distribuzione. Senza la semantica, la sintassi non ha nessuna importanza. Tuttavia, capisco che per molti, la confezione del prodotto sia importante, specialmente se il contenuto e tra i migliori. Facilita la scelta e la transizione. Per questo sono molto contento per cio' che sta succedendo con Elixir, una lingua influenzata da Erlang e Ruby.

Hai perfettamente ragione, e per quanto riguarda i record mi trovi completamente d'accordo con Damien. I record sono stati aggiunti nel 1995 e, se c'e' qualcosa di orrendo, sono proprio loro. Il problema e' di origine storica. Nel 1995, non potevano aggiungere datatypes nuovi, visto che i bits nella variabile che denotavano il datatypes nella macchina virtuale erano stati tutti usati. L'unica soluzione era di convertire i records in tuple. Quando poi il problema dei bits e' stato risolto, i record non sono mai stati ripuliti. La buona notizia e' che a partite dalla release R17 sono stati aggiunti i records "dinamici", chiamati maps. L'altra cosa orribile, ma incredibilmente potente, sono le match specifications. Per fortuna, sono in pochi ad usarle.

Il problema dello sforzo mentale non e' tanto quello di come uno ragiona in Erlang. Se negli ultimi 10 anni hai lavorato con una metodologia OO, avrai problemi a cambiare il modo in cui ragioni. Io avrei lo stesso problema se domani dovessi incominciare ad usare Java. Studi effettuati dalla Ericsson dimostrano che uno studente appena laureato in informatica che di recente ha usato molti linguaggi diventa produttivo in un mese. Un impiegato che ha circa 10 anni di esperienza ma ha usato un solo linguaggio ci mette tre mesi. Non solo, se ci pensi bene, il modo di ragionare in Erlang e' naturale. Le regole di Joe Armstrong sono le seguenti: Il mondo e parallelo. Le persone nel mondo comunicano mediante messaggi asincroni. Le persone non condividono la memoria. E le cose falliscono. Adesso prova a modellare un linguaggio di programmazione attorno a queste regole. Il risultato e Erlang!

Il secondo problema e' nell'educazione che uno riceve nelle università. Programmazione OO, funzionale, logica, imperativa, parallela e distribuita creano le fondamenta di tutti i linguaggi di programmazione. Se non ti hanno insegnato *tutti* questi modi di architetturare il tuo codice e di ragionare e - ancora più importante - se non ti hanno insegnato a saltare da un modo di ragionare all'altro, non hanno fatto bene il proprio lavoro.

E' considerato un neo da quelli che non usano Erlang o altri linguaggi dinamici. Il type system esiste, ma e' opzionale. Kostis Sagonas e i suoi ricercatori hanno fatto un lavoro stupendo con Dialyzer e Typer. Secondo, una tipizzazione dinamica fornisce vantaggi come il software upgrade in tempo reale (cosa che nessu altro linguaggio di programmazione mainstream offre). I bugs che risultano da una tipizzazione dinamica sono molto rari. Usando approcci TDD e programmando in maniera bottom-up, quando il codice va in produzione, la maggior parte dei bachi sono stati risolti. Studi hanno dimostrato che il numero di bugs con linguaggi con tipizzazzione statica per righe di codice sono piu o meno gli stessi. Sono tipi bugs diversi, ma sono sempre li.

Per chi conosceva C, dicevano che imparare C++ sarebbe stato facile. Per chi conosceva C++, imparare Java sarebbe stato facile. Oggi, dicono che per chi conosce Java, imparare Scala sia facile. Quindi, se conosci Ruby, imparare Elixir e' facile. Non sono d'accordo. Per capire Elixir, devi capire la semantica dei programmi paralleli. Capire come strutturare i processi , gli alberi di supervisione e il recupero dagli errori. Pensare che sia piu facile è un sbagliato, anche se aiuta psicologicamente. Ma sono d'accordo sulla ventata d'aria fresca. Erlang aveva bisogno di essere riconfezionato per attirare una nuova generazione di programmatori. Jose Valim ha fatto un ottimo lavoro... Anche se devo dire che la sintassi e' un po strana :-)

Erlang e' adatto a risolvere problemi concorrenti. Pensiamo per un momento ad un sistema per contare voti televisivi inviati via SMS. Per ogni SMS crei un processo. O ad un sistema di chat tipo quello di Skype o WhatsApp. Per ogni messaggio, crei un processo. Pensiamo ad un web server, dove per ogni richiesta o websocket aperto crei un processo. Questi non sono problemi algoritmici, ma concorrenti. Erlang ti semplifica il modo di ragionare, perché devi pensare solo ad un'istanza del processo. E se il processo fallisce, tutte le altre richieste continuano ad eseguire.

Estendere Elixir (o qualsiasi altro linguaggio) e' una proposizione potente, ma molto pericolosa. Persino Jose Valim consiglia di utilizzare questa funzionalità solo per la creazione di frameworks tipo OTP, ma non messo in mano agli sviluppatori e usato come stile di programmazione. C'e' il rischio che il codice diventi cosi astratto che nemmeno la persona che lo ha scritto riesce a capire cosa stia succedendo. Tutto cio' potrebbe diventare uno dei peggiori incubi di chi mantiene il codice. Ma se usato con attenzione, e' un costruttore molto potente. Con Erlang, non c'e' mai mancato. Nei frameworks, abbiamo risolto questi problemi usando parse transforms e librerie software.