.NET e linguaggi di programmazione
Recentemente mi è capitato di leggere alcuni articoli datati (se così si può dire per cose scritte 4 anni fa, ma sappiamo che nel mondo della tecnologia, e dell'informatica soprattutto, 4 anni sono un bel po') che introducevano al grande pubblico il .NET Framework. E' stato curioso leggere le entusiatiche presentazioni di un prodotto all'epoca ancora in beta a distanza di anni dal suo rilacio e confrontare le promesse e le aspettative di Microsoft con quello che poi è stato, in realtà.
Due cose mi hanno colpito, in particolare.
Da un lato la promessa di un'estrema facilità di sviluppo (gestione automatica della memoria, gestione delle eccezioni, FCL, eccetera). E qui niente da dire (beh, qualcosa sì, in realta, chi ha letto la storia di Pino sa a cosa mi riferisco); non si può negare che con una buona conoscenza degli strumenti a disposizione la rapidità di sviluppo è parecchio aumentata. Occhio che rapidità di sviluppo non significa solo metterci poco tempo a completare un progetto, ma anche metterci poco tempo a mantenerlo e ad estenderlo.
Dall'altro l'enfasi che veniva data all'interoperabilità fra linguaggi. Io scrivo un componente in C#, dal quale derivo un componente scritto in VB.NET che uso da MC++, e via dicendo. Vero anche questo, e gran cosa sicuramente. Continuando nella dissertazione, l'autore dell'articolo (scusate, non ho sottomano il link e non ricordo il nome dell'autore, prometto un update quanto prima) scriveva con entusiasmo qualcosa di questo genere: "Pensate, sono già sviluppati o in fase di completamento nmila compilatori che "target-izzano" (non mi viene in italiano, deformazione da libri in inglese) il runtime .NET".
Quest'ultima affermazione è stata sicuramente confermata dai fatti. Non conosco il numero aggiornato di compilatori che producono moduli managed, ma credo che siano veramente tanti.
I motivi sono palesi.
Innanzitutto è decisamente più semplice scrivere un compilatore per .NET. Non sono per niente esperto di compilatori, ma ci vuole poco a capire che, se da un lato la parte di analisi sintattica rimane, credo, della stessa complessità, dall'altro la fase di generazione dell'output è decisamente più affrontabile. Alla fine, se vogliamo guardare il mondo a strati (virtualizzazione, questa sconosciuta ...) la macchina virtuale CLR è a ben più alto livello della macchina virtuale con cui dobbiamo avere a che fare con i compliatori x86. Insomma, senza dilungarmi su questioni che conosco troppo superficialmente, semplicità è la parola chiave.
In secondo luogo credo che la crescente diffusione di .NET abbia portato gli amanti dei più disparati linguaggi di programmazione a cercare di rendere il proprio pupillo .NET-aware. Ed ecco nascere Fortran.NET, Cobol.NET e chi più ne ha più ne metta. Che poi esistano sviluppatori che scrivono per .NET in Cobol, questo è tutto da verificare (non dico che non ce ne sono, questo no, ma è indubbio che la percentuale sia irrisoria rispetto ai "colossi" di mamma Microsoft).
Terzo punto. Didattica ed "esercizio di stile". Non fraintendetemi, non è denigratorio. Tutt'altro. Dall'alto della mia inesperienza credo che portare a termine un progetto di compilatore per .NET sia un'esperienza fantastica e decisamente istruttiva: sia perchè ti costringe ad imparare molto bene le fondamenta della piattaforma che utilizzi (ricado sempre sul discorso "internals", che fissa !), sia perchè credo che ti faccia vedere le cose da un punto di vista un po' differente. Il classico utente (non stiamo parlando di utenti che aprono Word e leggono la posta, ma di programmatori, ovviamente) talvolta identifica la tecnologia che usa con il linguaggio di programmazione con il quale si esprime. Sviluppare un compilatore per .NET, o comunque interessarsi a questi argomenti, credo che aiuti a capire che il linguaggio di programmazione è un semplice strumento di astrazione sintattica che rende le caratteristiche della piattaforma disponibili al programmatore: ne isola il funzionamento reale tramite la definizione di costrutti più vicini a quelli della mente umana, che non è esattamente una abstract stack machine ...
E qui arriva il punto: ma se il linguaggio è solo uno strumento sintattico, la scelta è assolutamente indifferente ? E' solo una questione di gusti ?
Beh, no, in effetti.
Intanto non esiste, che io sappia, un linguaggio ad alto livello che renda disponibili tutte le caratteristiche del runtime: che so, C# non consente metodi globalli, VB.NET non consente overload di operatori, eccetera eccetera, sono solo due esempi. Quindi a volte la scelta del linguaggio può anche essere determinata dal numero di funzionalità sottostanti che questo mette a disposizione.
Secondariamente, costrutti analoghi scritti in linguaggi differenti non è detto che producano codice IL uguale. I compilatori fanno, o non fanno, ottimizzazioni e via dicendo, insomma non producono gli stessi risultati. Quindi anche un discorso di prestazioni può avere la sua influenza, anche se credo che ben pochi considerino questo aspetto.
Infine, e qui la distinzione è fra C#/VB/MC++ e il resto del mondo (faccio un'eccezione per Delphi), il supporto e la documentazione hanno un ruolo importantissimo, e non possiamo negare che la maggioranza di noi, quando ha deciso di sviluppare in .NET, la scelta l'ha fatta tra i prodotti di casa Microsoft. Uno perchè, anche senza conoscerli, li abbiamo ritenuti migliori già in partenza. Due perchè una scelta "standard" ci dovrebbe tenere al riparo da spiacevoli inconvenienti.
Ecco perchè. secondo me, prodotti "esoterici" hanno poca diffusione al di là dell'accademia. Ed è un peccato, perchè magari nascondono fantastiche funzionalità che ignoriamo solo per avere quel minimo di garanzia di supporto. E se, nella produzione "industriale", in effetti è una scelta sensata, chi sviluppa per hobby, o comunque senza fini commerciali, dovrebbe per lo meno ampliare la gamma di scelta.
Quindi, giusto per aggiungerne uno alla gamma, vi segnalo Nemerle. Ho letto giusto due cosette e mi è piaciuto abbastanza. Sappiatemi dire.
cU