Sempre più spesso si trovano articoli che confrontano i vari linguaggi di programmazione e le varie tecnologie tra di loro.
I tecnici discutono, spesso animatamente, come tifosi se sia meglio un linguaggio o un altro, perché nel criterio di scelta della tecnologia si proietta il nostro modo di scegliere, mettiamo in gioco la nostra capacità di valutare e di scegliere. Una bocciatura alla nostra scelta da parte di un collega, si proietta in una bocciatura a noi stessi, alla nostra capacità e, in definitiva, tale atteggiamento va a toccare le corde della nostra insicurezza.
Col tempo ho imparato a guardare con un certo distacco alle discussioni di questo tipo.
Oggi è più significativo confrontare i framework, piuttosto che i linguaggi. Non è più come negli anni 80 dove si imparavano 15 istruzioni e uno credeva di sapere programmare.
Si programma delegando a componenti esterni i dettagli. Il lavoro del programmatore sembra sempre di più quello del regista di teatro, che dirige degli attori, ma non è egli stesso l'attore.
Esistono ancora realtà dove si programma come un tempo, ma spesso spendono soldi e risorse per farsi in casa lavori già disponibili, solo che non ne conoscono l'esistenza. Ognuno coi suoi soldi è libero di fare come crede.
La prima domanda, che uno sviluppatore o meglio un architetto del software si deve porre, è come il lavoro, che deve realizzare, si interfaccia col mondo esterno, non soltanto sul piano della comunicazione, cioè dei messaggi in ingresso e in uscita, ma anche sul piano dell'ecosistema di strumenti e ambienti nel quale il progetto nasce e si sviluppa, cioè convive.
Ho conosciuto realtà che ogni anno riscrivevano da 0 il progetto, perché non erano più in grado di espanderlo o di modificarlo, perché il programmatore principale del progetto se ne era andato (chissà perché) oppure perché mancava documentazione, ma più spesso perché il progetto era stato analizzato male. Si vedono realtà che danno una enorme importanza alla gestione economica del progetto, ma non hanno la cultura e nemmeno l'abitudine all'analisi. L'atteggiamento di fermarsi a pensare prima di agire non è un'ostacolo all'agilità, anzi è una risorsa che col tempo fa risparmiare in rifacimenti inutili.
Come succede nei giochi di strategia a turni, i primi turni sono i più importanti e determinano spesso l'andamento della partita.
In questo scenario, non è significativo determinare se C# è migliore di Java perché ha Linq o se il C++ è meglio di entrambi, perché può usare meno risorse o se conviene o meno sviluppare in casa un framework per la persistenza o usarne uno standard.
Java è a mio avviso ancora la scelta migliore perché Java non è solo un linguaggio o un framework con un ricco ecosistema: Java è una specifica.
Si possono realizzare virtual machine compatibili, librerie compatibili ma di fondo esiste una regola, che è la specifica. La serietà di chi fa le regole e la fiducia di chi le segue è la forza di Java e in questo è superiore alle altre soluzioni, che sono pilotate spesso da una sola azienda, mentre nell'ecosistema di Java sono sempre convissute più realtà importanti.
La regola, la specifica dettata dall'alto, da un valore aggiunto enorme: la sicurezza dell'investimento.
Questa governance è stata la madre del successo e della diffusione di Java, al di là di alcuni suoi limiti tecnici (l'uso eccessivo di memoria) o di scelte discutibili (Swing che non usa i widget nativi).
La forza di Java è stata la politica di apparire come una regola, più che una tecnica.
Poi ciascuno di noi può proporre una proprio approccio alternativo a quello ufficiale, nel mio piccolo l'ho fatto anche io con EasyDriver ma non si può aspettare che i nomi che contano aderiscano alla sua proposta, se non si trova sotto il cappello del governo delle specifiche di Java.
Sinceramente sono un po' perplesso sulla politica usata ultimamente da Oracle, che vede troppe frizioni, in un ambiente che è diventato forte grazie agli accordi, che rendevano inutili i fork. Prima di tutto viene la specifica, la regola. Litigare con l'impagabile Apache Foundation e con Google non sta aiutando certamente l'immagine della piattaforma, ma il colpo finale sarebbe non potere più contare su una specifica credibile. Questo sarebbe un male per tutta l'industria informatica, cha ha tratto giovamento da questa rivoluzione, chiamata Java, e che farebbe un brutto salto indietro, se dovesse diventare un framework governato come gli altri.
Nessun commento:
Posta un commento