Una prima veloce analisi dei due nuovi linguaggi.

Come mi ero ripromesso, in questi 5 mesi ho dato un'occhiata a questi due nuovi linguaggi che sono apparsi sulla scena, e mi sono fatto un'idea sommaria delle loro capacità.

Vediamone velocemente le caratteristiche, i pro e i contro.

D

D è un linguaggio sviluppato dalla digitalmars, cercando di prendere il meglio da C++, Java, C# ed Eiffel. Ne è venuto fuori un linguaggio molto potente, che supporta programmazione ad oggetti, metaprogrammazione, moduli, unit testing integrato nel linguaggio e gestione automatizzata della memoria con garbage collector. Si può inoltre scrivere codice assembly direttamente nei sorgenti D.

Il tutto viene compilato in codice macchina, ed usa solo una libreria compilata staticamente nel software per tutte le funzionalità di base, mentre si avvale di due librerie dinamiche (tango e phobos) per alcune caratteristiche più avanzate.

Il codice sorgente è generalmente abbastanza pulito, e le prestazioni dei programmi generati sono, in alcuni casi, migliori degli equivalenti in C++.

La comunità è già molto vasta, e ha creato (o sta creando) bindings per le più comuni librerie, che comunque richiedono un lavoro di programmazione scarsamente automatizzabile, oltre a software di supporto come IDE o generatori di documentazione direttamente dai sorgenti, oltre a librerie apposite per questo linguaggio.

Tra gli svantaggi più gravi, secondo me, il fatto che il linguaggio viene portato avanti praticamente da una sola persona (Walter Bright) che, per quanto bravo, rallenta lo sviluppo del linguaggio. Ancora peggio, sempre secondo me, il fatto che la licenza con cui viene distribuito il compilatore ufficiale (DMD) non è di tipo open source, e per questo non è possibile inserirlo in alcune distribuzioni, come Debian, che usano solo software open.

In realtà esiste una versione open source del compilatore, GDC, che però è anch'essa sviluppata da una sola persona, per di più spesso latitante, e che usa un frontend coperto da copyright (di DigitalMars), per cui non può essere integrato in GCC, dove avrebbe una comunità di sviluppatori molto più vasta. Inutile dire che Bright non ha alcuna intenzione di cedere il copyright a FSF.

Il linguaggio sembra ottimo come general purpouse, è in gran parte multipiattaforma, ma sotto Linux presenta alcuni problemi che me l'hanno fatto scartare a favore di Vala. Per esempio il fatto che molti software devono essere adattati a livello sorgente per poter essere compilati con GDC (che è presente in Debian), ed altri che proprio non funzionano con GDC. Tra questi ci sono anche i binding per le librerie Gtk+, chiamati GtkD. Questo costringe ad usare il compilatore closed source dmd per scrivere programmi gtk, e quindi li esclude automaticamente da un'eventuale inclusione in Debian (infatti non esiste il pacchetto deb per GtkD).

Anche la libreria che dovrebbe essere standard di D (Tango) non esiste in formato opensource, mentre si trova solo Phobos, che sembra sia deprecata. In generale la situazione intorno a D è spesso molto confusionaria, anche se si stanno sviluppando progetti particolarmente interessanti.

Questo non ha impedito a Kenta Cho di sviluppare degli ottimi giochi per Linux che sfruttano SDL sotto Linux (li trovate sotto “Windows”, ma molti possono essere compilati quasi senza modifiche per Linux, e sono presenti in Debian).

I programmi compilati con D possono non richiedere alcuna libreria, il che lo rende buono/ottimo per scrivere software di sistema come driver, daemon e simili. Purtroppo, per ora, si portano dietro una libreria compilata staticamente che porta la dimensione minima di un eseguibile oltre i 350 KB anche per un semplice Hallo World.

Vala

Tutt'altro percorso ha portato allo sviluppo di Vala, che nasce come wrapper intorno a GObject, uno dei componenti di GLib da cui ereditano anche tutti gli oggetti di Gtk+.

Il linguaggio si ispira molto a C# per la sintassi, ed è puramente ad oggetti. In effetti ogni oggetto definito in Vala dovrebbe essere dichiarato come figlio di GObject per garantire il corretto funzionamento del software con tutte le caratteristiche previste.

Questa stretta dipendenza porta, per esempio, ad avere supporto diretto per tutti i tipi supportati dalle GLib (quindi interi da 8 a 64 bit, numeri floating point a vari livelli di precisione, ma anche array, hashtable, liste, ecc.), ed al sistema di gestione dei segnali di questa libreria, che permette di definire con una sintassi semplicissima l'associazione tra un segnale emesso da un oggetto (come un click su un pulsante) e la callback corrispondente (la funzione che gestisce il segnale).

Anche per Vala la gestione della memoria è automatizzata, in questo caso dai meccanismi già collaudati di GLib. Le variabili vengono liberate automaticamente quando non servono più, e le liste e le hash table si estendono automaticamente quando serve più spazio.

Il codice Vala viene “compilato” in codice puro in C, che viene quindi passato a GCC per la compilazione definitiva. Questo doppio passaggio, al di là di una (piccola) perdita di prestazioni in fase di compilazione, garantisce invece ottime prestazioni in fase di esecuzione (anche qui, in alcuni casi migliori dell'equivalente scritto in C++), ed una compatibilità perfetta con altri software.

Si può quindi scrivere in Vala una libreria che poi si potrà usare in C o in qualsiasi altro linguaggio, così come si può usare in Vala una qualsiasi libreria per Linux tramite la scrittura di un file di definizione (VAPI) per le sue funzioni. In alcuni casi questo file può essere generato in modo quasi automatico da alcuni tool, e in pochi mesi sono nati decine di binding a librerie più o meno conosciute, a partire, naturalmente, dalle Gtk, passando per molte librerie di Gnome (tra cui GStreamer, Canvas, GIO, Glade, ecc.), per finire con Gecko e Webkit, SDL, Hildon, JSON, Curses, SOUP, USB, ecc.

Il linguaggio è quindi ottimo per scrivere software con interfaccia grafica, principalmente Gtk, e rimane ottimo anche per software di base come i daemon o i plugin per Gnome, in quanto l'unica libreria essenziale per il funzionamento è appunto la GLib. Non è adatto a scrivere driver per il kernel, anche se, con un po' di attenzione, forse ci si può riuscire.

Tra i difetti del linguaggi, sicuramente, la sua giovane età, che implica che lo sviluppo sia a volte vorticoso al punto da rendere incompilabile un software scritto per una versione sulla versione successiva. Nella maggior parte dei casi, comunque, si tratta di correggere pochi punti del codice per adeguarsi alle nuove caratteristiche.

Ci sono ancora alcuni bug aperti su cui gli sviluppatori non hanno ancora messo le mani, ma in generale per quelli più gravi la velocità di risposta e di correzione è molto alta, nonostante il numero esiguo di programmatori, in pratica solo uno fisso, Juerg Billeter, con il contributo di Raffaele Sandrini e, sporadicamente, di una decina di altri che seguono la mailing list e propongono patch.

Stando alla Roadmap, verso la fine dell'anno è prevista la versione 1.0, e finora i rilasci sono stati abbastanza ben rispettati.

Forse il difetto più grosso che ho riscontrato, ad oggi, è la documentazione molto carente. Fortunatamente gli esempi che si trovano in giro e il supporto della mailing list del progetto spesso aiutano a portare avanti il lavoro, anche se un po' a braccio.

La scelta

Immagino che dal mio entusiasmo nella descrizione si sia già capito cosa ho scelto. :)

“Purtroppo” la gran parte del software che scrivo ha a che fare con le interfacce e coi database (e tutto è per il web o per Linux), quindi per me è fondamentale che siano ben supportate le librerie Gtk (non mi piacciono le Qt...), e D era troppo limitato da questo punto di vista, oltre ad essere molto più complicato compilare i vari moduli-binding per le altre librerie come SQLite, MySQL, ecc.

Non è un brutto linguaggio, tutt'altro, e mi riprometto di studiarlo meglio in futuro, sperando che nel frattempo il supporto del compilatore GDC e, soprattutto, dei binding per le varie librerie vengano migliorati. Purtroppo in questi 5 mesi non ho visto molto fermento nella comunità, mentre lo sviluppo di Vala procede con una velocità che non avevo mai visto prima, nonostante il numero molto più ridotto di partecipanti.

Nel giro di un weekend ho quasi completamente finito di scrivere in Vala un editor (molto semplice) a tab in Gtk, in meno di 400 righe di codice, che compila in un eseguibile di circa 35 KB (in memoria occupa di più, circa 12 MB, ma in gran parte sono librerie condivise come gtk, pango, ecc., quindi l'occupazione reale è inferiore ai 4 MB).

Appena riuscirò a trovare il tempo di renderlo compilabile (e magari avrò ripulito un po' il codice) lo metterò scaricabile da qui. L'ho sviluppato con la versione 0.3.1 del compilatore ma, in seguito a una mia segnalazione di bug sui binding per GLib Module, Juerg ha separato, nella versione 0.3.2, il vapi di GModule da quello di GLib, quindi devo rivedere le inclusioni. Credo sia questione di 15 minuti sistemarlo, ma voglio vedere bene cosa ha combinato.