A tre anni dalla introduzione di Swift da parte di Apple per la programmazione di applicazioni iOS, anche Google ha finalmente adottato un linguaggio più evoluto su Android rispetto a quello con cui è nata la piattaforma: si chiama Kotlin, è sviluppato da JetBrains, è open source e promette, tra le altre cose, di ridurre la quantità di codice ripetitivo da scrivere e di rendere lo sviluppo più sicuro consentendo di evitare intere categorie di errori in fase di esecuzione.

L’annuncio non è rivoluzionario come quello di Apple. Nel caso di Google, infatti, si tratta di una mossa più politica che tecnologica: era già possibile usare Kotlin per sviluppare applicazioni Android introducendo una serie di librerie e plugin nei propri progetti. Ora il supporto per questo linguaggio è direttamente fornito dall’ambiente di sviluppo (Android Studio 3.0 attualmente in versione beta) e la legittimazione derivata dalla ufficialità ne ha ridotto al minimo gli eventuali rischi di adozione. Inoltre, il linguaggio Java, finora unico disponibile sulla piattaforma (a meno di non volersi avventurare nei profondi meandri di C e C++ utilizzando il Native Software Development Kit) si trova certamente a un livello di astrazione più elevato rispetto a Objective-C, il suo corrispondente nel mondo Apple. Il passaggio dal vecchio al nuovo promette dunque di essere meno traumatico, ma anche di avere un impatto minore per quanto riguarda la produttività degli sviluppatori.

Per quale motivo, allora, darsi la pena di supportare ufficialmente un nuovo linguaggio di programmazione sulla propria piattaforma? Non tutti i linguaggi sono potenti allo stesso modo, ed evidentemente Google riconosce che i limiti di Java, così come è stato implementato su Android, si sono accumulati fino ad alzare a livello di guardia il grado di insoddisfazione della comunità di sviluppatori. Va notato, infatti, che il linguaggio Java di cui Google ha dotato Android non è lo stesso linguaggio gestito da Oracle. L’originale, in particolare nelle ultime versioni, sta portando a compimento una lunga evoluzione, cominciata una decina d’anni fa con l’introduzione dei tipi generici e disegnata per allontanarlo dalle rigidità della propria implementazione del paradigma orientato agli oggetti. La versione di Google, sotto questo aspetto, è rimasta costantemente indietro per quanto riguarda le caratteristiche più avanzate del linguaggio: si va dai ritardi nell’adozione di costrutti come il try-with-resources fino alla necessità di introdurre librerie aggiuntive per sfruttare le lambda expression. Le promesse per il supporto completo delle funzionalità di Java 8, compresa la notevole libreria di stream di oggetti per la manipolazione delle collezioni, sono arrivate troppo tardi, e nel caso delle API si notano fastidiose limitazioni sulla minima versione del sistema operativo su cui eseguire le applicazioni che ne facciano uso.

Promesse

Kotlin, d’altro canto, è stato progettato per fornire fin da subito quella flessibilità nella programmazione che Java ha solo faticosamente e incrementalmente cercato di raggiungere negli ultimi dieci anni. Kotlin fa parte di quella genìa di linguaggi, che comprende Scala e Clojure, nati allo specifico scopo di girare sulla Java Virtual Machine (JVM), per poterne sfruttare solidità ed efficienza, e contemporaneamente liberare gli sviluppatori dalle costrizioni e dalla prolissità di Java. Il movimento degli Alternative JVM Languages, esploso nella seconda metà della prima decade degli anni duemila, anche grazie a implementazioni per la JVM di linguaggi già esistenti come JRuby, ha prodotto risultati rimasti pressoché di nicchia, a volte per l’eccessiva complessità (Scala), a volte per la totale estraneità della sintassi e del paradigma di programmazione (Clojure). Kotlin è il primo di questa nidiata a essere adottato da un colosso del web come linguaggio ufficiale per una delle sue piattaforme più importanti.

Forze

Che cosa offre Kotlin dal punto di vista tecnico? Tra le caratteristiche più rilevanti possiamo ricordare quelle che seguono.

• Una sintassi tersa e concisa. Più istruzioni è necessario scrivere per implementare una certa funzionalità, più è facile introdurre bug e più è difficile trovarli quando si riscontra un malfunzionamento dell’applicazione.
• Protezione dai riferimenti nulli. Tramite l’uso di appositi operatori, Kotlin permette di verificare in quali punti del codice è possibile avere riferimenti nulli e consente allo sviluppatore di proteggere l’esecuzione del programma dalle temute NullPointerException.
• Una nuova istruzione avanzata per il controllo del flusso di esecuzione.
• Una serie di costrutti per rappresentare e utilizzare funzioni come entità computazionali indipendenti, che espande e arricchisce quanto offerto dalle lambda expression di Java 8.
• Un costrutto per esprimere in maniera rapida classi che rappresentano dati (note tipicamente, anche se in modo non del tutto corretto, come POJO o componenti JavaBeans nel mondo Java).
• Una ricca libreria standard che comprende funzioni per la manipolazione avanzata delle collezioni.
• Una interoperabilità pressoché totale con il codice scritto in Java.

Nessun linguaggio è perfetto, e Kotlin non fa eccezione. Alcuni concetti, come quello del cosiddetto companion object, potrebbero risultare ostici a chi si è formato quasi esclusivamente sul linguaggio Java, così come l’assenza di riferimenti statici. Più in generale, persino il funzionamento della istruzione return in certi ambiti potrebbe risultare spiazzante. Nonostante questi difetti, non c’è dubbio che Kotlin rappresenti un passo in avanti rispetto a Java per quanto riguarda l’espressività e l’efficacia della programmazione: laddove Java vi costringe a scrivere “aggeggio di metallo che si usa per scavare il cibo”, Kotlin vi consente di usare la parola “cucchiaio” e di proseguire serenamente con il resto del codice.

Debolezze

Rimangono comunque aperte alcune questioni riguardanti l’adozione del linguaggio da parte degli sviluppatori. In primo luogo, Kotlin, come qualsiasi altro linguaggio, va imparato, e non bastano certo ventiquattro ore o tre settimane per farlo. Nel tempo necessario a rendere i propri sviluppatori competenti è prevedibile che la loro produttività diminuisca. Va poi considerato, nel caso si decida di adottare Kotlin per una parte o per la totalità di una o più applicazioni, se sarà facile o meno trovare nuovi sviluppatori dotati di una proprietà di linguaggio adeguata per estendere o correggere il codice esistente. Infine, le difficoltà che rendono Android la piattaforma più dispendiosa su cui sviluppare rispetto ad iOS potrebbero non essere dovute al solo linguaggio di programmazione, e gli sviluppatori potrebbero influire maggiormente nella riduzione di costi e tempi se concentrassero i propri sforzi su altri aspetti del processo di costruzione delle applicazioni.

Conclusione

In Mango queste riflessioni sono all’ordine del giorno. Ogni sviluppatore impiega parte del proprio tempo ad aggiornare conoscenze e competenze che non necessariamente riguardano in modo esclusivo il proprio ambito di azione all’interno del gruppo di lavoro. Se si ritiene che una tecnologia possieda le qualità desiderate, si apre una discussione e si decide insieme di valutare l’opportunità più adeguata per adottarla all’interno di un progetto.

Nel caso specifico in esame, riteniamo che la strada per semplificare la programmazione su Android sia ancora lunga. Ma ogni viaggio comincia con un passo, e Kotlin è un passo nella direzione giusta.