I benefattori

Osservando le nuove offerte in campo dello sviluppo, vedo strumenti cross platform sopratutto per i cellulari.
Ho parlato con un amico, titolare di una importante software house, il quale mi diceva che stava cercando uno strumento per scrivere il codice una volta sola per Android e iOS.
Scrivere il codice una volta sola vuol dire risparmiare, avere una base unica sulla quale fare le modifiche, vuol dire tagliare i costi di produzione del proprio prodotto e raggiungere un target di clienti il più ampio possibile.

Uso Java dalla versione 1.0.1beta su OS/2 Warp, che i più giovani forse nemmeno ricordano. Dovrei sentirmi inorgoglito del fatto che oggi sempre più persone riconoscano che avevo ragione, che è importante non escludere dei clienti possibili, rispettando le loro scelte, perché il sistema operativo è parte importante del modo di lavorare di una persona e una persona lavora diverse ore al giorno...
Ricordo il dileggio di chi mi faceva notare che Microsoft era la più forte, che il mercato era saldamente nelle sue mani e gli altri erano ininfluenti. A onor del vero oggi lo scenario delle piattaforme mobili è ben diverso, molto più variegato e probabilmente gli stessi che tempo fa imparavano a usare VisualBasic e si sentivano Grandi Programmatori non si preoccuperebbero minimamente di studiare HTML, JavaScript, Java ecc... se il loro campione da seguire oggi fosse ancora il dominatore assoluto delle percentuali di installato, come negli anni '90. A loro vorrei ricordare che senza Java non ci sarebbe nemmeno C#, tentativo fallito di Microsoft di copiare una tecnologia allora migliore della loro. Oggi C# è un ottimo strumento per sviluppare su piattaforma Microsoft e gli altri mercati desktop sono ininfluenti, diverso invece è il discorso per quanto riguarda il mercato mobile.

Invece io non sono più così convinto che il cross platform sia la scelta vincente sempre.

E' più facile oggi fare cross platform rispetto a 20 anni fa: ci sono più librerie che nascondono la piattaforma e la crescente potenza dell'hardware permette di tenere degli strati di compatibilità tra l'applicativo nativo e il sistema sottostante. Penso per esempio all'ottimo Parallels su Mac OS X che permette di fare girare ad esempio  Microsoft Office per Windows senza vedere il desktop di Windows, ma di vedere le finestre Windows assieme a quelle del Mac. Penso proprio ai tempi di OS/2 quando di vedevano le finestre dei programmi per windows 3.1 assieme a quelle di OS/2, ma allora l'hardware non era così generoso come oggi e andava tremendamente piano.

20 anni di sviluppo cross platform mi hanno però insegnato che ci sono delle spine in questo mondo di rose. Le applicazioni cross platform non sfruttano mai le caratteristiche della macchina, ma soprattutto NON SI COMPORTANO SECONDO LE ABITUDINI DEGLI UTENTI.

Parlavo con un utente Windows che per le prime volte usava il fantastico The Gimp per il fotoritocco. Egli si arrabbiò perché la finestra di dialogo per aprire i file non era quella alla quale lui era abituato (The Gimp usava finestra di dialogo per Gnome) e questo particolare sminuiva tutto il progetto.

Chi ci "regala" applicazioni cross platform lo fa per LEGARCI ALLA SUA PIATTAFORMA, rendendo inutile il sistema operativo sottostante, per creare un ecosistema di applicazioni e quindi di persone, che hanno bisogno di lui. Questo spiega anche perché spesso le piattaforme cross platform impongono il loro look and feel anche quando potrebbero (e dovrebbero) appoggiarsi ai componenti del sistema sottostante. Garantire lo stesso aspetto su più piattaforme non serve tanto agli utenti, i quali tipicamente ne usano soltanto una. HTML5 mi sembra un'ottima specifica, applicata solo in parte dai produttori di piattaforme, i quali vedono positivamente la sostituzione di Flash, che è proprietario e i plugin sono pesanti, con uno standard aperto, ma l'idea che gli applicativi possano farsi senza dipendere da loro non va loro certamente a genio: quindi l'uso di uno strumento cross platform è sempre più scomodo per l'utente rispetto alle applicazioni native.

Prima di scegliere lo strumento bisogna pensare bene a cosa serve e a CHI LO USA.

NON DICO CHE BISOGNA TORNARE ALLE SOLUZIONI NATIVE in massa, dico che vedo un futuro migliore per chi sviluppa una soluzione nativa per il core dell'applicazione, che deve espandersi e crescere tramite dei generatori di codice o con dei motori che creano l'applicazione a partire da regole o parametri. Questa soluzione è oggi usata da pochi, per quando posso vedere dalla piccola finestra che ho sulla realtà, il motivo è che progettare un'applicazione è un conto, ma progettare un'architettura magari personale è tutt'altra cosa. Su questo fronte c'è ancora spazio per la piccola azienda creativa, che riscopra il valore della progettazione e dell'analisi sui dettagli che si ripropongono nei vari progetti dei quali si occupa.

La logica si può sviluppare con uno dei tanti linguaggi cross platform (Java, C#, JavaScript, anche il C++ 14 va bene) o con sistemi più sofisticati di scripting.
Anche le tanto vituperate stored procedure oggi sono piuttosto portabili e possono essere prese in considerazione e chi le sceglie merita rispetto.

Ci vuole coraggio per sviluppare la propria libreria di base. Scrivere generatori di codice o addirittura scrivere in xml dei layout che poi si applicano automaticamente ai dati da rappresentare, magari seguendo il Naked Object pattern e mettendo da parte il sopravvalutassimo MVC.

Sono queste secondo me le linee da seguire per chi nel 2015 non lavora solo su progetti altrui e vuole continuare a fare il proprio mestiere di produttore di progetti software, senza reinventare la ruota ma mantenendo la propria indipendenza e libertà.