Scala Italy 2015: chi ben comincia…
Non poteva esserci inizio migliore per la prima edizione di Scala Italy che avere il principale autore ed ispiratore del linguaggio, Martin Odersky, ad aprire la giornata con un keynote dedicato allo stato ed ai prossimi sviluppi di Scala.
Odersky ha iniziato la sua presentazione ripercorrendo la propria storia professionale, dal dottorato a Zurigo lavorando sui linguaggi Modula-2 e Oberon con Nicklaus Wirth, agli studi sui linguaggi funzionali e la partecipazione al progetto Haskell nei primi anni ’90, e all’interesse per Java e soprattutto la piattaforma JVM negli anni successivi. Fa bene ricordare, infatti, che la JVM è da sempre poliglotta, in quanto al suo rilascio era già dotata di features particolarmente innovative, ed è stata fin da subito un banco di prova di grande interesse accademico per lo studio dei linguaggi ad oggetti e dei diversi modelli di gestione dei tipi. In questi ambiti Odersky collabora al compilatore di Borland JBuilder e sviluppa diversi linguaggi sperimentali che avranno poi un’influenza su Scala.
Scala, passato e presente
Scala nasce come risultato di questi sforzi, cercando una sintesi dei paradigmi funzionale e ad oggetti, fortemente influenzato da OCaml anche se con alcune sostanziali differenze filosofiche. A parte l’errore ormai riconosciuto del supporto a XML, i due pilastri del linguaggio, cioè la “scalabilità” concettuale (ovvero mirare alla giusta astrazione nel linguaggio, e lasciar fare alle librerie la maggior parte delle features) e l’attenzione alla facilità d’uso del sistema dei tipi, hanno retto finora molto bene.
Scala è ad oggi alla base di un ecosistema molto vivo che copre tutte le aree più innovative: Big Data, distribuzione, concorrenza spinta. Ora che ufficialmente abbraccia più della JVM, con la dichiarazione di stabilità di ScalaJS, aggiunge Javascript (e quindi il browser) come piattaforma di esecuzione. Odersky ha particolarmente elogiato gli sviluppatori di questo progetto, che hanno un ruolo importante nella futura struttura del linguaggio.
Gli strumenti di sviluppo continuano ad evolvere ed aumentare di potenzialità: Martin ha ammesso di essere passato da Emacs ad Eclipse con ScalaIDE circa 2 anni fa, ma ha avuto parole di apprezzamento per il lavoro di IdeaLabs, anche se il loro compilatore non può dirsi “ufficiale”. Infine, i corsi online su Coursera raggiungono numeri di partecipazione e soprattutto di successo molto superiori alla media di altri argomenti.
Verso il futuro
Il futuro di Scala si presenta particolarmente interessante: con la recente apparizione di alcuni “standard” di elaborazione ed esecuzione, come i Future, i Reactive Streams e le Spores, si sta delineando una piattaforma alternativa alla JEE fatta di specifiche condivise da più implementazioni, caratterizzate da differenze anche importanti in architettura ed approccio. Si tratta di un evento particolarmente significativo per la piattaforma Java, che mette direttamente in discussione l’autorità della stewardship Oracle già oggetto di forti critiche per la lentezza nell’innovare la JVM.
Odersky è passato poi a parlare del problema della “binary incompatibility” che ha da sempre afflitto le major release di Scala; si tratta tuttavia di un problema tecnologicamente insormontabile, in quanto molte delle feature di Scala devono essere codificate come informazioni aggiuntive nei classfiles emessi dal compilatore. Quando il formato di questi dati deve cambiare per ineludibili necessità tecniche, non può più essere letto dalla versione precedente. Typesafe ed il resto della comunità hanno affrontato questo problema in vari modi mitigandolo, ma si tratta di qualcosa di intimamente legato alla struttura della piattaforma.
Nel futuro (non prossimo, ma vicino), la questo problema sarà affidata al formato TASTY – Serialized Typed Abstract Syntax Trees. Si tratta di un formato intermedio fra la compilazione e la generazione del codice eseguibile, accuratamente documentato e particolarmente generale, che servirà anche da supporto per molte delle prossime innovazioni del linguaggio. Questo consentirà di andare verso una piattaforma più indipendente dai backend di esecuzione, puntando ad avere un compilatore (ed una toolchain di supporto) che lavorano su TASTY e una serie di passaggi finali in grado di generare da questa rappresentazione classfiles per qualsiasi JDK presente o futuro, o per altre piattaforme, prima fra tutte JavaScript. Alla base di questi sforzi c’è l’iniziativa “DOT – A calculus for Dependent Object Types”, un’attività accademica di ricerca e dimostrazione automatica1 per ottenere un modello molto più flessibile ed espressivo dell’attuale.
Il compilatore dotc che implementa le idee di questa iniziativa, supporterà la pulizia di alcune caratteristiche di Scala non più desiderate (XML, “procedure syntax”, inizializzatori immediati e tipi esistenziali), ma soprattutto di un nuovo modo per esprimere i tipi contenitore, ovvero gli “uninstantiated type members”. Quest’ultima novità in particolare porterà a risolvere alcuni dei casi peggiori e delle complicazioni del package delle collezioni, fino a mettere a disposizione la possibilità di unione ed intersezione di tipi, risultato che può avere enormi ricadute pratiche e semplificare l’accesso a strutture che ora sono dominio esclusivo di ScalaZ o di linguaggi particolarmente avanzati.
La visione di fondo che Odersky sta portando avanti riguardo alla filosofia del sistema dei tipi è che forse le monadi non siano realmente il modo più efficace per gestire gli effetti esterni. Un loro difetto per esempio è il mancare di commutatività, cosa che invece sarebbe alla portata del nuovo modello di tipi. L’alternativa su cui il suo team sta lavorando è ragionare, invece che per effetti, per Capabilities codificate in tipi ed argomenti; si otterrebbe così una sintassi simile alle monadi, ma con struttura più semplice da usare. Martin ha fatto notare, non senza soddisfazione, come al momento del primo rilascio di Scala i linguaggi staticamente tipizzati (come Java, C# e C++) fossero considerati ormai superati dai linguaggi “dinamici” come Ruby; ora invece l’interesse per i sistemi di tipi verificati alla compilazione si trova al suo massimo storico: Scala ha contribuito non poco a questo ribaltamento di fronte, evidenziando come una migliore sofisticazione del compilatore (per quanto costosa in termini di performance) ed una sintassi più semplice sono realmente di aiuto nello scrivere codice migliore e che necessita di meno test, perché i tipi forniscono già molte garanzie.
In conclusione
Il passato di Scala, con i suoi errori, ci ha dato delle basi solide su cui poggiare gli sviluppi futuri: il principale messaggio di Odersky è che Scala è un linguaggio estremamente vivo, che suscita grande interesse da parte di tutta l’industria (e del resto, il sold-out istantaneo dello Scala Italy lo testimonia), ed al tempo stesso ha un retroterra accademico che lo alimenta di innovazione non astratta, ma concreta ed utilizzabile per scrivere codice sempre più espressivo e corretto.
1Tuttora in corso; Odersky ha spiegato come ormai sia considerato stato dell’arte disporre di prove meccaniche di sistemi di assiomi generate con COQ (http://en.wikipedia.org/wiki/Coq) o simili sistemi per dimostrare la validità di un sistema di tipi. In pratica, vengono formalizzate le proprietà che si vogliono ottenere in un linguaggio apposito, ed algoritmi di ragionamento automatico le verificano e le dimostrano. Questo dà una base incredibilmente solida alle parti più astratte e basilari di un linguaggio.
