conundrum

Dicevo <a href="http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/">altrove</a> di aver provato <a href="http://live.gnome.org/Vala">Vala</a>, il linguaggio C#-like scritto usando GLib e GObject come base, e che viene "compilato" in C invece di usare una <acronym title="Virtual Machine">VM</acronym> e un linguaggio intermedio¹.

Ho trovato dei difetti nel layer di traduzione, ma sono dovuti essenzialmente alla giovane età del progetto, e il team di sviluppo sta raccogliendo intorno a sé una quantità di collaboratori più o meno saltuari che fa ben sperare. In più, la mera esistenza di Vala sta spingendo a completare il supporto per l’introspezione in GObject².

Quello che più mi interessa, però, è la possibilità di avere un linguaggio a medio/alto ufficialmente sanzionato da GNOME – come Objective-C da Apple. Intendiamoci: la quantità di <em>binding</em> già presenti è enorme, e già oggi se volessi scrivere un’applicazione per GNOME potrei farlo in Perl, come in Java, come in C# e perfino con quel <em>train wreck</em> di Python³. Tuttavia, i bindings sono quello che sono: si portano dietro <em>virtual machine</em>, ambienti di <em>runtime</em>, licenze, implementazioni <em>patent encumbered</em> e altre amenità.

Intendiamoci: non ho nulla contro le <acronym title="Virtual Machine">VM</acronym> – a parte l’obiezione classica: "sto già usando una macchina virtuale su una macchina reale, perché devo usarne un’altra ancora per ogni linguaggio?"; tuttavia, e specie sulle macchine su cui lavoro, <strong>una</strong> <em>virtual machine</em> è già sufficiente – figuriamoci quattro o cinque. Mi piacerebbe che qualcuno prendesse Mono e ci portasse più di tre o quattro linguaggi; mi piacerebbe ancora di più che qualcuno prendesse <a href="http://en.wikipedia.org/wiki/Parrot_virtual_machine">Parrot</a> e lo completasse. Mi piacerebbe, insomma, avere <strong>una</strong> macchina virtuale per tutti i linguaggi ad alto livello. Se non posso averla, allora tanto vale usare Vala.

1. si potrebbe arguire come, in realtà, la VM usata sia il sistema operativo ospite, e che sicuramente esistono più piattaforme con un compilatore C che piattaforme che supportano Java o C# [↩]
2. ovvero la possibilità di avere meta-informazioni a <em>runtime</em> su una libreria, sulle API e sui tipi di dati esportati [↩]
3. che, spero, Python 3.0 affosserà definitivamente con tutte le modifiche arbitrarie alle API senza vere nuove <em>feature</em>; non ci resta, quindi, che sperare in IronPython per una implementazione sana di mente? non voglio pensarci [↩]