Linguaggi statici e dinamici: paure o problemi?

Da tempo si sente l'esigenza di superare il linguaggio Java per rendere la programmazione più flessibile, agile e, se possibile, vicina al linguaggio naturale. Molti hanno individuato la ragione della rigidità di Java nella sua tipizzazione statica e si sono pertanto rivolti a linguaggi dinamici. Questa scelta presenta comunque alcuni problemi.

In primo luogo la tipizzazione dinamica, se da un lato introduce sicuramente flessibilità, dall'altro apre la porta a possibili errori di codifica, errori che in un linguaggio statico sarebbero facilmente ed automaticamente catturati dal compilatore.
Se la paura di introdurre bachi nei programmi dinamici potrebbe essere solo la "deformazione mentale" di chi da sempre ha utilizzato linguaggi statici, penso sia un dato di fatto, sicuramente più importante, che la tipizzazione a tempo di compilazione costituisca una forma, sempre automatica, di documentazione del codice. Spesso si indica la scrittura di accurati test unitari come la soluzione ai suddetti problemi. Posto che oramai la scrittura di test unitari dovrebbe essere una fase imprescindibile dello sviluppo, personalmente preferisco concentrarmi sui test che risultino più significativi, senza dilungarmi in verifiche banali che anche un compilatore potrebbe svolgere. Sarò antiquato, ma, se uno strumento automatico può fare la parte meno interessante del mio lavoro più efficientemente di me, preferisco usarlo.
Un'altra pecca di molti linguaggi dinamici è costituita dalle prestazioni. Sicuramente con il tempo il miglioramento degli ambienti di esecuzione porterà, e sta portando, in secondo piano questo aspetto, che però, al momento, non può essere trascurato.
In terzo luogo, alcuni dei linguaggi che si propongono come alternative a Java non hanno a loro corredo, al momento, quella enorme quantità di librerie sviluppate negli anni per il linguaggio della Sun. Chi come me, ad esempio, si occupa dello sviluppo di software gestionale sarebbe veramente in difficoltà senza disporre di un supporto per la creazione di stampe di qualità paragonabile all'accoppiata JasperReports + iReport.
Va poi considerato il fatto che Java è attualmente supportato da moltissime piattaforme, dai PC ai sistemi IBM AS400 e Main Frame, cosa non sempre vera per altre soluzioni.
L'enorme diffusione del linguaggio di Sun ha inoltre creato una corposa base di programmatori che hanno dimestichezza con i suoi costrutti ed il suo ambiente di esecuzione. Un linguaggio con una sintassi ed una filosofia di esecuzione troppo differenti da quella di Java potrebbe essere accettato con difficoltà da numerosi sviluppatori.
Ultimo fatto da vagliare è quello che al momento non esistono strumenti di refactoring per i maggiori linguaggi dinamici paragonabili a quelli creati per i linguaggi statici. Questa non sembrerebbe essere una limitazione teorica (i primi strumenti di refactoring sono stati creati per Smalltalk), quanto piuttosto un problema contingente, che però, al momento attuale, non è ancora stato superato.
A tutte queste obiezioni sembrerebbe rispondere, almeno in parte, il linguaggio Scala . Realizzato a partire dal 2001 dal Politecnico di Losanna sotto la guida di Martin Odersky, uno degli sviluppatori del compilatore Java, è stato rilasciato pubblicamente per la prima volta nel 2004 in due versioni, una per la piattaforma Java ed un'altra per .NET, ed ha subito un sostanziale miglioramento nel corso del 2006.
Di questo linguaggio mi occuperò ampiamente nel corso dei prossimi post.

Lascia un commento

You must be logged in to post a comment.