Articolo di Roberto Mazzola – Datatex IT Chief Technology Officer
Quando si parla di linguaggi di programmazione si ha a che fare con due fazioni: chi considera sensato utilizzare oggi soltanto linguaggi come Java, e chi difende la “solidità” dei vecchi linguaggi considerando le tendenze attuali alla stregua di “mode” senza particolari giustificazioni tecniche.
Il problema così è mal posto da entrambe le parti. È sicuramente vero che la qualità di un linguaggio di programmazione non dipende da quanto questo linguaggio è recente, ma d’altro canto è indubbio che i linguaggi più recenti siano correttamente orientati verso alcuni “nuovi” mondi (web, Intelligenza Artificiale, Machine Learning, ecc.), e siano quindi più adatti per affrontare tutta una serie di nuove questioni e problemi, il che non significa considerarli in assoluto e in ogni contesto “superiori” ai linguaggi precedenti.
Il punto è che la scelta di un linguaggio di programmazione è legata al contesto, agli scopi e agli obiettivi che ci si pone. Non si contano i linguaggi esistenti: qual è il migliore? Non esiste. Se devo affrontare un progetto di Machine Learning, per fare un esempio, i vecchi e cari COBOL o RPG non sono di certo gli strumenti adatti. Ma se pensiamo per esempio a quello che tutti noi facciamo ogni giorno prelevando dal bancomat o pagando con carta di credito, scopriamo che alla fine del “percorso” si arriva ai sistemi informativi della banca e che questi vengono spesso elaborati ancora oggi tramite COBOL, il che – in questo preciso contesto – è ancora oggi perfettamente sensato.
D’altro canto anche noi di Datatex abbiamo ancora in uso presso molti clienti (pienamente soddisfatti) delle applicazioni sviluppate quarant’anni fa in RPG (parlo del nostro storico gestionale TIM). In questi casi il core dell’applicazione rimane lo stesso, al limite oggi affiancato da una user interface più moderna via browser (anche se, a dire il vero, molti utenti rimpiangono i vecchi schermi verdi!).
A un certo punto però in Datatex abbiamo fatto una scelta molto chiara, che è quella di sviluppare in linguaggio Java J2EE, e oggi il nostro prodotto di punta è NOW ERP, che è un software al 100% web based, che vanta già installazioni in 46 nazioni e che è diventato in pochi anni l’Erp verticale per il settore tessile più venduto nel mondo.
Perché abbiamo fatto la scelta di sviluppare in Java e perché il mercato sta premiando questa scelta? I nostalgici dei vecchi linguaggi potrebbero parlare di una scelta (e di un successo) legati al cavalcare l’onda di una moda, quella dei nuovi linguaggi, che sarebbe una questione più di nuove tendenze marketing che di sostanza. Non è assolutamente così, anzi in un certo senso è vero il contrario: la scelta di Java da parte di Datatex è legata innanzitutto alla necessità – in prospettiva futura e guardando avanti sul lungo termine – di conferire la massima longevità alle nostre soluzioni, al di là di mode e tendenze passeggere. Peraltro, dato che in Datatex la decisione di sviluppare un ERP web based risale ai primissimi anni Duemila, e che si trattava ai tempi di una scommessa dall’esito non scontato, possiamo dire che Datatex ha fatto una scelta vincente, in un certo senso anticipando l’evoluzione del mondo ERP.
Dobbiamo considerare che Datatex non sviluppa piccole soluzioni ad-hoc e con un uso limitato nel tempo, ma ha creato un ERP completo che richiede importanti investimenti da parte dei clienti, e che deve quindi garantire piena affidabilità e totale supporto per decenni. Come è possibile oggi garantire questa tenuta sul lungo termine? C’è solo un modo: programmando in un linguaggio web multipiattaforma, del tutto indipendente dalla piattaforma e dalle macchine utilizzate (quindi appunto “java” per il “core”, coadiuvato poi da altri linguaggi adatti, come JavaScript per il front end, ecc.). I responsabili IT delle aziende che si sentono ancora legati ai vecchi linguaggi sottovalutano spesso che cosa potrebbe accadere se si trovassero costretti a cambiare piattaforma, cosa che può sempre accadere per vari possibili motivi (nuova proprietà in azienda e nuove scelte da parte dei nuovi proprietari, oppure nuove valutazioni di mercato da parte della multinazionale che controlla la piattaforma, ecc.). Se succede una cosa del genere, chi lavora sui vecchi linguaggi si trova di fronte a una transizione complessa e costosa, mentre chi lavora con un prodotto multipiattaforma e al 100% web based come NOW ERP by Datatex non va mai incontro a nessun particolare problema.
D’altronde quello della portabilità delle soluzioni su ogni piattaforma (secondo lo slogan “write once, run anywhere/everywhere”) è stato fin dall’inizio l’obiettivo di Java. Ed era anche l’obiettivo di IBM, che nella seconda metà degli Anni Novanta cercò – purtroppo decidendo poi di accantonare il progetto – di promuovere una nuova soluzione “java based” (il cosiddetto framework IBM San Francisco).
Programmare in linguaggio web multipiattaforma non significa oggi seguire una “moda”, ma – al contrario – significa per noi poter realizzare – per usare una metafora – un capo alla Re Giorgio (Armani), qualcosa che non dico non abbia tempo ma che di certo è sempre elegante ed usabile nel corso degli anni.
La scelta di Java (JakartaEE), peraltro, garantisce continuità per il futuro (anche Microsoft oggi sta investendo in Java…). Gartner nel 2016 aveva prodotto un report in cui ipotizzava che la piattaforma JavaEE non sarebbe riuscita a tenere il passo dell’evoluzione nel mondo IT, ma si trattava di una predizione totalmente sbagliata: dopo un periodo di riorganizzazione le specifiche JakartaEE 9 e 9.1 sono state rilasciate e si sta già lavorando sulla versione 10, che assegna un ruolo sempre più importante al Cloud.
Peraltro il solo “Java” non è sufficiente, è solo un’ottima base. Se si vogliono poi implementare dei “Linguaggi” (o meglio: degli strumenti) per agevolare lo sviluppo applicativo, diventa importante poter avere a disposizioni una serie di “servizi” che consentano di non distrarre il programmatore da aspetti molto tecnici, dandogli la possibilità di focalizzarsi sulla soluzione applicativa.
Dobbiamo quindi distinguere tra “linguaggio” di programmazione ed eventuali framework costruite su quel linguaggio per semplificare ulteriormente le fasi di sviluppo. Per fare un esempio: JavaScript è un linguaggio, ma ci sono numerose framework on top come Node.js, Angular e React.js. Noi abbiamo deciso di sfruttare ExtJs per il front end di NOW (su cui poi abbiamo lavorato molto per vestirlo su misura rispetto alle nostre esigenze), ma usiamo anche Node.js e React Native per lo sviluppo di App cross-platform.
Alla fine l’obiettivo è rendere la vita del programmatore più semplice: più veloce nella realizzazione ma anche più veloce nell’adattare il software alle esigenze del cliente, in modo semplice e affidabile. Per soddisfare pienamente l’utente finale, e considerando la soluzione User Centric, per rendere la percezione di semplicità e usabilità del prodotto veramente alta il solo “Java” non è sufficiente. Ad esempio, per tutta la parte front end, l’alleato ideale è la combinazione HTML/CSS/ JavaScript con la miriade di framework on top (nel nostro caso ExtJS di Sencha ma anche altre in base al contesto).
Ma non solo! Tutto questo a noi non è bastato e abbiamo voluto creare un livello di astrazione ulteriore, per aiutare ulteriormente i nostri programmatori a concentrarsi sul business e non sulla tecnologia. Di certo qualcosa di “nuovo” c’è sempre da imparare, e forse è anche questo il bello del nostro lavoro, la continua evoluzione e il non annoiarsi mai, ma per aggiornarsi alle nuove tecnologie ci sono importanti costi di training e di migrazione del codice, e proprio con lo scopo di minimizzare questi costi ci siamo inventati un nostro linguaggio – ABSolution by Datatex (eh sì…non bastavano gli oltre 9000 linguaggi di programmazione esistenti…volevamo il 9001!). Il nostro, per la precisione, è un meta-linguaggio, ovvero un linguaggio che permette di definire altri linguaggi, e nel nostro caso permette di generare Java (secondo le specifiche Java EE/Jakarta EE 8, oggi). Ed è questo che ci aiuta moltissimo nel seguire le evoluzioni delle architetture: abbiamo fatto le migrazioni dalle primissime versioni di J2EE a Jakarta EE semplicemente andando a ridefinire le regole di generazione dal nostro meta-linguaggio a Jakarta EE! Per noi questo significa anche poter assicurare qualità del software e uniformità negli standard ma mantenendo i punti di forza di Java (e la sua versione enterprise) per tutto il backend. Mentre per il front-end ci basiamo principalmente su dei pattern visuali (che sono in continua evoluzione, con implementazioni di nuovi pattern), sempre nell’ottica di mascherare la complessità tecnologica al programmatore, e demandando il tutto al nostro Engine sviluppato appunto in JavaScript e relative framework. Ma sempre con un occhio alla possibilità di integrarsi con tutto il mondo circonstante.