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.

Durante una conferenza a Las Vegas, Miguel de Icaza, sul palco assieme a rappresentanti della Microsoft, incalzato da alcune domande di Mike Shcroepfer (di Mozilla) ha prima cercato di spiegare come l’accordo con Microsoft protegga solo chi scarica Moonlight dal sito Novell e non da altri siti, e infine ha ammesso che, se fosse stato per lui, l’accordo con Microsoft non si sarebbe dovuto fare, ma non era in posizione di decidere.

De Icaza, cofondatore del progetto GNOME e della (ormai estinta) Ximian, ora è vice presidente di Novell.

Moonlight, per chi ancora non lo sapesse, è l’implementazione “open source” (tra virgolette perché appesantita dai brevetti Microsoft) di Silverlight, la risposta di MS, appunto, a Flash/Flex/AIR di Adobe. Per come la vedo io, sono entrambe tecnologie chiuse, anche se apparentemente open, quindi da evitare finché possibile.

Di recente Nokia (probabilmente stressata da MS) ha annunciato che avrebbe reso disponibile Silverlight sui suoi cellulari intelligenti (le serie S40 e S60).

Novell aveva già ricevuto pesanti critiche dalla comunità per il suo accordo con “il nemico”, soprattutto dal sito BoycottNovell, che non ha mancato di criticare anche Moonlight. Forse De Icaza si sta accorgendo che nel mondo Linux perdere il supporto della comunità può essere molto rischioso.

Secondo me, semplicemente, Linux non ha bisogno di Mono. Nessuna applicazione (che io sappia) scritta per .Net funziona su Linux, nemmeno le più semplici. E tutte quelle scritte per Linux sfruttano Gtk o meccanismi di Linux, per cui non funzionano con Windows, quindi il motivo principale dell’esistenza di Mono viene a cadere. Ritengo che ci siano già molti strumenti per sviluppare rapidamente su Linux (dall’immensità di librerie disponibili per C e C++ a Python, passando per Gambas, Ruby, e anche Java. E perfino PHP, volendo, anche fuori dal web), e che sarebbe meglio spendere energie per sviluppare progetti più significativi, come Vala e GDC, che hanno una cronica mancanza di sviluppatori, ma nonostante ciò stanno crescendo.

Dopo il post per gli auguri di Natale sicuramente non ve ne aspettavate uno per gli auguri di buon anno, vero?

Voevo postarlo poco dopo mezzanotte, ma la baldoria prima e la stanchezza poi mi hanno fatto desistere. Non credo sareste comunque stati lì a quell’ora a leggerlo, quindi non penso vi cambi molto la vita.

Siccome a capodanno si elencano i buoni propositi per l’anno che sta arrivando, ho pensato di raccogliere qui i miei. Magari qualcuno è d’ispirazione anche per voi. Sono in ordine sparso, man mano che mi vengono in mente.

Studiare il D (e altri linguaggi)

Da quello che leggo in giro, D è un ottimo linguaggio di programmazione, e in realtà ho già dato un’occhiata alle specifiche del linguaggio e agli esempi sul sito ufficiale. Quello che ho visto mi ha favorevolmente impressionato. In pratica è un linguaggio che cerca di prendere le parti migliori di C/C++ e di Python/Ruby. Molto flessibile, dinamico (non del tutto, naturalmente) e soprattutto compilato. Le prestazioni dei programmi scritti in D sono ottime e, a giudicare dagli esempi, è anche semplice scrivere programmi. Mi ricorda vagamente il linguaggio E che esisteva sull’Amiga, anche se in quel caso derivava da Pascal e Oberon, quindi con una sintassi più rigida.

Una delle sorprese più gradite è stato scoprire che ci si potevano fare cose come Torus Trooper e TUMIKI Fighters (non fatevi ingannare dalla grafica, sono molto divertenti ) in modo quasi completamente cross-platform.

Anche Vala sembra interessante. Si tratta di un linguaggio inventato dal team di Gnome, ispirato a C#, e molto orientato a scrivere applicazioni per Gnome (anche se, dagli esempi, sembra adatto un po’ per tutto). Lo stanno già usando per scrivere Scratchpad e anche Mickeyl per riscrivere openmoko-terminal2. Il vantaggio principale rispetto a C# stesso è che è completamente compilato, quindi non ha bisogno di virtual machine o di ambienti di runtime, o anche solo di librerie aggiuntive. A detta degli stessi sviluppatori è ancora acerbo, e molte cose sono in via di sviluppo, ma quello che c’è ha già un bell’aspetto.

Tornare in Giappone

Questo probabilmente è un proposito che non riuscirò a portare a termine entro il 2008, ma ci spero comunque. Mi mancano l’ordine e la cortesia dei giapponesi, mi manca Akihabara, mi manca il cibo giapponese. Insomma, non vedo l’ora di tornarci.

Mi sono messo come limite la primavera del 2009. Ce la posso fare! Ganbatte!

Finire i programmi e i siti che ho in corso

Questa forse è la parte più difficile di questi buoni propositi. Purtroppo la parte che mi “prende” di più di un progetto è la preparazione, le prime fasi di stesura del codice, l’organizzazione dei moduli, mentre odio totalmente e profondamente la fase di debug. Di solito il dover debuggare un software è motivo sufficiente per abbandonarlo a sé stesso. Probabilmente aspetterò l’uscita della quarta edizione di D&D per rimettere mano (e riscrivere per la terza volta) il mio Mastertools, software (in Python+Gtk+SQLite) di gestione delle campagne, con annesso database di magie (già funzionante), talenti e oggetti magici (non ancora funzionanti).

Spero di riuscire nei prossimi giorni a buttare giù almeno le basi di due siti che ho in testa da almeno un paio di mesi e di un altro paio di programmini che sto progettando da altrettanto tempo. Ma non voglio rivelare niente, anche per scaramanzia.

Comprare l’Asus Eee

In realtà sto aspettando la versione con schermo a 8, 9 o 10 pollici. Mi andrebbero bene anche i 7″ della versione attuale, ma con risoluzione almeno 1024×600. Meglio ancora 1280×768. Una bella formattata alla flash, una bella Debian con Gnome al posto della Xandros, una SDHC da 16-32 Gb montata come /home e via!

Se non sarà l’Eee sarà sicuramente un altro subnotebook di caratteristiche analoghe: 1 Kg di peso, dimensioni molto ridotte. Gradirei molto anche una durata maggiore della batteria.

Mi sono accorto che il notebook che ho ora (Dell Inspiron 8600) non lo uso mai (praticamente solo per masterizzare partite di D&D): troppo pesante (3.5 Kg), troppo ingombrante (schermo 15,4″, quindi notebook di oltre 17″), e relativamente fragile, avendo un HD al posto di una flash. E la tastiera è comunque ridotta rispetto al fisso, quindi difficile da usare. In proporzione uso di più lo Zaurus, sia per leggere e-book sia per scrivere.

Migliorare la conoscenza di PHP, Javascript e Python

Programmando in PHP per lavoro, la prima parte di questo proposito è abbastanza semplice da portare a termine, basterà continuare a lavorare . Ci sono comunque diversi argomenti che mi piacerebbe approfondire. Per esempio ho l’impressione di star usando poco e male lo Zend Framework, e che abbia ancora molte qualità nascoste da esplorare. Per di più, sta uscendo la nuova versione 1.5 con supporto per View estese e Layout!

Javascript è ridiventato molto interessante (per me, naturalmente) di recente, grazie all’arrivo di librerie e framework come jQuery che nascondono abbastanza bene le differenze più ostiche tra i browser e permettono di concentrarsi meglio sul lavoro da svolgere, più che sulle incompatibilità tra le varie versioni. Spero di poterlo approfondire maggiormente.

Purtroppo ho un po’ lasciato in disparte Python per motivi di tempo, e comunque non ero un esperto nemmeno prima. Devo impormi di riprenderlo in mano e di studiarmi bene le caratteristiche della nuova 2.5 (decoratori e compagnia cantante).

Lo nascondo qui ma non fateci caso: mi piacerebbe anche studiare un po’ Ruby. Tra l’altro è appena uscita la 1.9 che sembra abbia prestazioni molto superiori alla precedente. Tutti ne parlano, ma ora che l’hype iniziale dato da Rails si sta esaurendo, forse è il momento giusto per vedere cosa offre di veramente vantaggioso rispetto agli altri (rails a parte).

Postare più frequentemente sul blog

Questo non sarà proprio facilissimo. A volte un argomento mi pare troppo scontato o trito per parlarne qui, e voglio evitare di parlare di politica o cose del genere (che sono una flame-bait non da poco). Per scrivere post tecnici preferisco informarmi bene ed evitare di scrivere porcherie non verificate, anche se a volte devo fidarmi di quello che trovo in giro, non avendo la possibilità di provarlo direttamente.

Ciononostante, cercherò di trovare qualche argomento di cui parlare. Magari portare avanti i propositi di cui sopra mi darà anche qualche spunto interessante.

Dulcis in fundo…

Ah, naturalmente riportare la pace nel mondo! (Ecco il link diretto al sito. O una variante, se la preferite, in fondo i gusti sono gusti).