Premettendo che non sono un esperto dell'altro lato del mondo, vorrei comunque segnalare questa iniziativa, ben introdotta da questo articolo su InfoQ.
Al di là del contenuto, ne ho trovato interessante lo scopo: creare un substrato di funzionalità comuni e utilizzabili dagli implementatori di *diversi* linguaggi basati su JVM.
In fondo un ambiente di esecuzione virtuale, discorso valido per JVM come per CLR, trova la sua massima espressione quando:
- consente l'utilizzo e l'interazione di più linguaggi (il "sopra")
- è adattabile all'hosting su più piattaforme (il "sotto")
Interessante notare come, a livello di marketing almeno, per CLI (.NET) abbiano sempre sottolineato il primo aspetto. Per JVM, dall'altro lato, il "multipiattaforma" è in fondo sempre stato *il* cavallo di battaglia.
Due facce della stessa medaglia, no ?
Me lo segno questo link perchè è una soluzione ad uno degli annosi problemi legati all'utilizzo dei device USB su macchine virtuali VPC ... cioè che VPC non li supporta :-)
La soluzione, appunto, è l'utilizzo di emulatori / device virtuali.
Ne aveva parlato Lorenzo un po' di tempo fa, me lo ha riportato alla mente questo post di Mick Badran, peraltro giusto giusto per l'uso che ne devo fare io !
Sa di uovo di Colombo, ma ho provato il software (USB@niwhere) questo pomeriggio e funziona a meraviglia, che è quello che conta in attesa di un supporto diretto senza workaround.
Ancora una volta mi viene da scrivere di linguaggi di programmazione.
Di nuovo !! Sarà mica un altro discorsetto sui linguaggi statici vs dinamici, imperativi vs funzionali, IfThenElseEndIf vs {}, ... ?
Sì e no :-)
La motivazione di questo post sta nella lettura di alcune interessati considerazioni sull'utilizzo di differenti linguaggi di programmazione, in termini di opportunità, facilità, espressività, convenienza in generale.
Mi riferisco a:
- questo post di Wilco Bauwer (è di un paio di mesi fa, purtroppo rimasto nella mia todo list fin troppo, lo rileggo ora con vero piacere).
- questo post di Martin Fowler (piaccia o non piaccia, non vi è dubbio che sia una voce da ascoltare con attenzione).
- questo post di Neal Ford, linkato dal precedente (non conoscevo l'autore, aarghh, un feed in più per il mio aggregator).
Alcuni mesi fa sono partito con il proposito di imparare Haskell. Non è stato un "prendi la biglia dal cesto e vedi quello che capita", bensì una scelta motivata dalla necessità (didattica, ma necessità rimane) di comprendere almeno l'ottica che sta dietro la programmazione funzionale. Non sono diventato un programmatore Haskell. Un "gusto" però devo dire che mi è rimasto.
Più di recente, dopo l'annuncio della disponibilità pubblica (alpha) del Dynamic Language Runtime ... chi può resistere ??!! Bisogna iniziare almeno a leggere 2 articoli su Python (IronPython ==> Python). Sinceramente ... insomma ... non riesce a piacermi. Per tante ragioni che spero saranno occasione di un altro post o di 2 chiacchiere. Intanto però almeno ho una lontana idea delle cose di cui si parla. E poi Ruby (in attesa che IronRuby facesse capolino, attesa puntualmente terminata alcuni giorni fa). Ruby ha incontrato i miei gusti un pochino di più del cugino. E comunque, considerazioni personali a parte, ho iniziato a valutare con maggiore attenzione le problematiche che stanno dietro ai linguaggi a tipizzazione dinamica.
VB.NET, per tornare su terreni più noti, l'ho dovuto imparare per lavoro. Con molti meno scogli da superare (in fondo è un linguaggio imperativo e statico a-la C#).
Tutto questo per dire ?
Beh ... che il mio percorso di appredimento si è un po' ramificato :-)
Quello che trovo interessante non è tanto il fatto, quanto il tempo.
Sì perchè i linguaggi funzionali esistono dall'era paleozoica. Quelli dinamici dal mesozoico. VB, se consideriamo solo la parte B, pure lui ha le sue belle ere linguaggiologiche dietro (GWBASIC anyone ?).
Innegabile, almeno per quel che mi riguarda, la ragione dell'interesse: sono entrati nella sfera .NET.
.NET evolve.
O, più correttamente parlando, evolve il supporto e l'integrazione di ambienti, addirittura di concetti prima del tutto estranei. Potenziali, se volete, ma estranei.
L'effetto immediato è che l'interesse verso queste diversità cresce. E di pari passo le informazioni, la documentazione, le idee ...
Oggi la scelta del linguaggio non è (non deve essere) aprioristica, passatemi il brutto termine.
La coesione tra linguaggio e framework è molto meno stretta che in passato. E il disaccoppiamento consente di ampliare le possibilità di scelta del linguaggio, pur partendo da requisiti ferrei a livello di framework.
Ok ... Fowler l'ha detto meglio:
[...]
We will see multiple languages used in projects with people choosing a language for what it can do in the same way that people choose frameworks now.
[...]
E' quello che sta avvenendo ora. Magari ancora a livello embrionale, ma caspita !
I side-effect non sono banali. E non parlo solo di tecnologia in senso stretto. Perchè alla fine il mercato ha i suoi tempi, e da tutti questi discorsi sono rimaste fuori considerazioni non del tutto marginali. Per esempio, che un'azienda che fa software oggi investe su un framework ma mantiene costante il linguaggio per uniformità e facilità di gestione.
Ma anche questo è un discorso troppo complicato per essere affrontato in questo post, anche perchè il senso qui è un altro.
Il senso è che abbiamo (avremo) di fronte un'estrema flessibilità. Che bisogna essere bravi a sfruttare in maniera corretta, senza forzature ed utilizzando, appunto, the right tool for the right job.
La conclusione la lascio a questa splendida considerazione di Bauwer:
[...]
It's a different lifestyle
[...]
Try a different lifestyle. Understand what it feels like. Understand the good parts and the bad parts. Many of them may very well be applicable to your own lifestyle. You just came from a different background, so you never realized it.
Oh, and learning a new language like Ruby doesn't have to mean you have to throw away everything you invested in. This is one of the points of the CLR and the DLR. Allow people with different lifestyles to live and work together. Yes, I personally wouldn't write all my .NET libraries in Ruby. But yes, I think I could benefit a lot if I would use it to write my Silverlight or ASP.NET applications.
[...]