Imparare la programmazione Swift: è pronto per la prima serata?

Il lancio da parte di Apple lo scorso giugno di Swift, un nuovo linguaggio di programmazione per la scrittura di app iOS, ha creato molto entusiasmo ed entusiasmo nella comunità degli sviluppatori iOS.

Fin dal suo lancio, molti sviluppatori iOS hanno lottato con la domanda se, come e quando passare da Objective-C a Swift. La risposta a questa domanda sarà ovviamente diversa per ogni team e ogni progetto.

Ci sono numerosi articoli che puoi leggere che coprono molti dei vantaggi di Swift. Quindi, invece di ripassare quegli stessi punti, in questo articolo ci concentreremo invece su alcune delle preoccupazioni che potresti voler considerare prima di imparare lo sviluppo di app con Swift.

Ma prima, riportiamo un po' indietro l'orologio...

Prima di Swift: userai Objective-C e ti piacerà...

L'anno era il 2010. L'iPhone non aveva ancora 3 anni e la possibilità di scrivere app native per l'iPhone esisteva solo da circa 2 anni. L'8 aprile di quell'anno, Apple ha annunciato la versione del sistema operativo iPhone. Il sistema operativo iPhone (questo era prima che cambiasse il suo nome in iOS) includeva nuove allettanti funzionalità come multitasking, cambio rapido delle app e servizi in background. Comprensibilmente, gli sviluppatori di iPhone non vedevano l'ora di mettere le mani sul nuovo SDK e iniziare a giocare con tutte queste nuove entusiasmanti funzionalità.

Ma l'SDK di iPhone OS 4 conteneva una bomba inaspettata. Questa bomba non era nel software, era nel contratto di utilizzo. Con iPhone OS 4 SDK, la sezione 3.3.1 del contratto per gli sviluppatori è stata aggiornata per includere il seguente linguaggio problematico:

Le applicazioni devono essere originariamente scritte in Objective-C, C, C++... e solo il codice scritto in C, C++ e Objective-C può essere compilato e collegato direttamente alle API documentate.
– Sezione 3.3.1 dell'Accordo per gli sviluppatori SDK di iPhone OS 4

Inutile dire che questa nuova restrizione ha colto di sorpresa molti sviluppatori. Il motivo ufficiale del cambiamento, fornito dallo stesso Steve Jobs, era impedire l'utilizzo di strumenti multipiattaforma come Flash CS5 recentemente annunciato. Si dice che Jobs abbia affermato che "i livelli intermedi tra la piattaforma e lo sviluppatore alla fine producono [sic] app scadenti". Ma il fatto che l'approccio di Apple per combattere questi "strati intermedi" fosse quello di limitare i linguaggi di programmazione che potevano essere usati per scrivere app per iPhone ha rivelato qualcosa in più sul pensiero di Apple: Objective-C dovrebbe essere abbastanza buono per chiunque.

Si potrebbe essere perdonati per essere d'accordo con questa affermazione, poiché Objective-C ha vinto il premio "Programming Language of the Year" del Tiobe Index per due anni consecutivi. Ma la realtà era che la popolarità di Objective-C era una funzione del crescente ecosistema di app, e non il contrario. Già nel 2010 molte persone erano insoddisfatte di Objective-C e, di conseguenza, stavano già emergendo modi alternativi per scrivere app per iPhone in altri linguaggi di programmazione.

Alla fine, sotto la pressione della comunità di sviluppatori in generale, Apple ha annullato queste modifiche alla Sezione 3.3.1 dell'Accordo per gli sviluppatori SDK solo cinque mesi dopo. Tuttavia, il messaggio era chiaro: se volevi scrivere app per iPhone, probabilmente dovresti usare Objective-C.

… o forse no. Inserisci la nuova lingua iOS Swift.

Avanti veloce di 4 anni da quell'incidente al giugno del 2014, quando Apple ha presentato agli sviluppatori il suo nuovo linguaggio, Swift. Se il messaggio di 4 anni prima era che Apple era perfettamente soddisfatta di Objective-C, allora il messaggio inviato dall'introduzione di Swift era che Apple era finalmente pronta ad ammettere la verità. Objective-C potrebbe non essere necessariamente il miglior linguaggio per scrivere app mobili.

Molto è stato detto su come Swift sia un linguaggio più "moderno" di Objective-C. Se sei interessato a come imparare il linguaggio di programmazione Swift, potresti voler consultare la guida per passare da Objective-C a Swift.

Quello che dovresti notare, però, è che ci sono due importanti differenze tra i linguaggi Objective-C e Swift:

1. Swift non è un superset rigoroso del linguaggio C.
2. Swift è tipizzato staticamente, non digitato dinamicamente.

Non essere un superset rigoroso di C significa che Swift è libero di utilizzare costrutti di sintassi che altrimenti non sarebbero consentiti. Ciò consente, ad esempio, di implementare operatori personalizzati in Swift.

Essere tipizzati staticamente significa che Swift può trarre vantaggio da molti dei recenti progressi nei sistemi di tipi sperimentati da linguaggi come Haskell.

Nonostante sia stato in sviluppo per 4 anni prima di essere rivelato al pubblico, Swift è ancora un giovane linguaggio di programmazione, quindi viene fornito con una serie di avvertimenti.

Compatibilità con Objective-C

iOS condivide un'eredità comune con OS X, che a sua volta prende la sua storia dal sistema operativo NeXTSTEP rilasciato per la prima volta nel 1989. NeXTSTEP è stato originariamente scritto in gran parte in Objective-C e molte delle librerie principali in OS X e iOS hanno tutte le loro radici la via del ritorno a queste implementazioni originali. (Per inciso, è da qui che deriva l'onnipresente prefisso "NS" che si trova sulle classi principali come NSString .) Mentre Swift potrebbe teoricamente esistere in assenza di queste librerie principali, la realtà è che qualsiasi programma Swift che potresti scrivere nel prossimo futuro dovrà interfacciarsi con Objective-C.

A loro merito, gli sviluppatori dietro Swift hanno fatto un lavoro fantastico rendendo l'interazione con le librerie Objective-C esistenti il ​​più indolore possibile. Questo non vuol dire che il processo sia completamente indolore. Apple ha fornito un'utile guida che spiega come chiamare il codice Objective-C da Swift e viceversa, ma ci sono alcuni importanti disallineamenti di impedenza di cui essere a conoscenza.

Forse la mancata corrispondenza più evidente riguarda i file di intestazione. Objective-C, a causa delle sue radici C, richiede ancora che le funzioni siano dichiarate prima di essere chiamate. Quando si chiama una libreria, queste dichiarazioni si troveranno nei file di intestazione della libreria. Swift, tuttavia, non utilizza i file di intestazione. Quindi, se vuoi chiamare il codice Swift da Objective-C, dovrai prima creare un "bridging header". Anche se concettualmente questo può non sembrare così complesso, in pratica può essere davvero un compito.

Un'altra serie di complicazioni nell'interfaccia tra Swift e Objective-C deriva dalle differenze intrinseche nei loro sistemi di tipo. Swift, prendendo spunto da altri linguaggi moderni, ha eliminato il concetto di nil . Al suo posto ci sono i tipi opzionali di Swift. Ad esempio, un metodo che apre un file solo se esiste già avrebbe un tipo restituito di File? (anziché solo File ) in Swift. Tracciando tutti i punti in cui i tipi sono opzionali, il compilatore Swift può effettivamente rendere impossibile l'incontro con il temuto "Errore del puntatore nullo". Ovviamente, a meno che tu non chiami Objective-C. Poiché Objective-C non fornisce tali garanzie sulla mancata restituzione nil , Swift ha una categoria speciale di tipi chiamata Implicitly Unwrapped Optionals che vengono utilizzati quando si chiama il codice Objective-C. Questi tipi possono essere trattati come optional nel linguaggio Swift, insieme a tutto l'overhead necessario per il controllo dell'esistenza. In alternativa, possono essere usati come qualsiasi tipo non opzionale, ma se Objective-C restituisce nil ti ritroverai con un errore di runtime, quindi perderai alcune delle garanzie di sicurezza in fase di compilazione di Swift.

Infine, una discrepanza leggermente più sottile da considerare quando si programma tra Swift e Objective-C ha a che fare con il modo in cui gli oggetti e le classi vengono creati sotto le coperte in questi due linguaggi. Objective-C, a causa della sua natura dinamica, utilizza l'invio dinamico per chiamare metodi sugli oggetti (tramite objc_msgSend ). Swift può certamente utilizzare l'invio dinamico, ma poiché è tipizzato staticamente ha anche la possibilità di utilizzare una vtable per memorizzare i puntatori a funzione per ciascun metodo. Quale di questi due meccanismi utilizza Swift dipende da un paio di fattori. Plane Old Swift Objects utilizzerà il meccanismo vtable , a meno che la classe o i metodi all'interno della classe non siano annotati utilizzando l'attributo @objc Swift. Le classi Swift che ereditano dalle classi Objective-C utilizzeranno l'invio dinamico per i metodi ereditati, ma non per i nuovi metodi introdotti dalla sottoclasse (sebbene, ancora una volta, puoi forzare l'uso dell'invio dinamico con l'attributo @objc ). Indipendentemente da ciò, il codice Swift sarà sempre in grado di funzionare con le classi Swift, ma il codice Objective-C può utilizzare solo oggetti e metodi Swift che sono stati adeguatamente annotati.

Più veloce di Objective-C?

Quando Apple ha introdotto il suo lancio, uno dei vantaggi di Swift che è stato particolarmente enfatizzato era la sua velocità. Ciò è comprensibile se si considera che uno dei motivi spesso addotti per la riluttanza di Apple a passare da Objective-C a un linguaggio di livello superiore era che Objective-C, essendo essenzialmente un'estensione del C, era in grado di creare programmi molto più veloci ed efficienti di qualcosa come Python o Ruby. Anche così, Objective-C non è un razzo quando si tratta di prestazioni assolute, e gran parte di ciò può essere attribuito alla tipizzazione dinamica. Quindi, con Swift che adotta un sistema di tipo statico, ci si aspetterebbe che Swift sia almeno altrettanto veloce, o più veloce, di Objective-C.

Naturalmente, come si suol dire, "Ci sono tre tipi di bugie: bugie, maledette bugie e punti di riferimento". (O qualcosa del genere...) Certamente, ci sono numerose ragioni per cui il linguaggio Swift potrebbe funzionare più velocemente. Sfortunatamente, sembra che il modo in cui Swift utilizza la tecnica ARC (Automatic Reference Counting) di Apple per la gestione della memoria a volte porti il ​​compilatore di Swift a generare programmi significativamente più lenti, specialmente con impostazioni di ottimizzazione inferiori (come quelle che potresti usare durante lo sviluppo). La buona notizia è che sembra che i miglioramenti di Swift risolvano continuamente questo problema, ed è quindi probabile che nel prossimo futuro Swift genererà eseguibili almeno altrettanto veloci, o più veloci, di Objective-C.

C'è un altro avvertimento sulla velocità di Swift, però. Il punto centrale di Swift è che gli sviluppatori non scriveranno lo stesso codice che avrebbero scritto in Objective-C. Cosa significa questo per le prestazioni? Bene, certamente significa che confrontare le prestazioni tra Swift e Objective-C è più complicato di quanto possano rivelare semplici benchmark. Significa anche che confrontare le prestazioni assolute di runtime degli eseguibili generati racconta solo metà della storia.

Tutti vogliono programmi veloci, ma spesso la velocità di sviluppo è importante, se non di più. Un linguaggio più espressivo, in grado di svolgere più lavoro in meno righe di codice, può essere un enorme vantaggio in questo senso. D'altra parte, quando si lavora in un linguaggio compilato in cui il ciclo edit-compile-run-debug occupa gran parte della giornata di un programmatore, un compilatore lento può davvero danneggiare la produttività. Sebbene le prove siano principalmente aneddotiche, sembra che il compilatore Swift sia attualmente abbastanza lento da essere fastidioso, specialmente quando si lavora con codice che esercita il sistema di tipi avanzato di Swift. Un gruppo ha persino ritenuto che la velocità di compilazione fosse abbastanza problematica da motivare il ritorno a Objective-C.

Il compilatore

Parlando del compilatore Swift, è esso stesso la fonte di ulteriori avvertimenti quando si considera il passaggio al nuovo linguaggio Swift. A parte la velocità di compilazione, poiché Swift è emerso dal piccolo gruppo di sviluppatori che lavorano con esso in Apple e si è scatenato sulle masse, il compilatore ha iniziato a mostrare crepe sotto lo stress. C'è anche un intero repository GitHub dedicato alla raccolta di esempi di codice che causeranno l'arresto anomalo del compilatore Swift.

C'è anche la domanda su come cambierà il compilatore Swift. Un altro progetto su GitHub sta raccogliendo speculazioni e analisi dalla community su quali cambiamenti potrebbero essere in serbo per Swift. Ad esempio, gli operatori personalizzati possono mettere a dura prova un parser. Inizialmente, gli operatori personalizzati in Swift non potevano utilizzare un punto interrogativo (?). Sebbene questo problema sia stato risolto nell'ultima versione di Swift, le richieste continuano ad arrivare dalla crescente comunità di sviluppatori Swift per una flessibilità ancora maggiore in quello che può essere considerato un valido operatore personalizzato.

Ogni volta che senti che il parser di una lingua è in evoluzione, dovrebbe darti una pausa. Il parser di un linguaggio è il cuore e l'anima di un linguaggio di programmazione. Prima che qualsiasi semantica del linguaggio possa essere applicata per conferire significato al codice, è il parser che determina cosa è e non è codice valido per cominciare. È incoraggiante, quindi, che Apple abbia promesso di garantire un certo livello di compatibilità di runtime per Swift. Ciò non garantisce necessariamente, tuttavia, che il codice Swift verrà eseguito senza essere ricompilato per ogni nuova versione di Xcode e/o iOS. Né garantisce che non dovrai riscrivere parti del tuo codice Swift per rimanere compatibile con le versioni future di Swift. Ma ancora una volta, l'impegno di Apple a rendere questo processo il più indolore possibile è almeno un piccolo conforto.

Comunità

Alcuni dei peggiori linguaggi di programmazione mai creati (che rimarranno senza nome) sono stati incoraggiati, molto tempo dopo che il buon senso ha affermato che avrebbero dovuto essere relegati nella pattumiera della tecnologia fallita solo dalla forza delle rispettive comunità. Allo stesso tempo, la raccolta di linguaggi di programmazione davvero carini che non sono riusciti a prendere piede per mancanza di una comunità è troppo numerosa per essere contata. Comunità forti producono tutorial, rispondono a domande su Stack Overflow, frequentano online o di persona a conferenze condividendo storie, suggerimenti e trucchi e scrivono e condividono utili librerie tra loro. Quando si sceglie quale lingua utilizzare per un progetto, la community è sicuramente qualcosa da considerare.

Purtroppo, la comunità iOS/Obiettivo-C non ha la migliore reputazione di essere amichevole e accogliente. Questo sta gradualmente cambiando e l'open source sta giocando un ruolo sempre più importante nello sviluppo di Objective-C. Tuttavia, in questa fase iniziale è difficile dire come sarà la community di Swift in futuro. Sarà composto principalmente da sviluppatori insulari che lavorano solo al di fuori delle API Apple ufficiali e delle proprie raccolte private di codice? O sarà una vivace comunità di gruppi che condividono suggerimenti, trucchi e utili librerie?

Un altro aspetto del ruolo della community è il ruolo degli stessi sviluppatori di Swift. La tendenza generale nella programmazione è stata quella di passare da linguaggi e piattaforme di programmazione proprietari a soluzioni open source. Lo sviluppo Open Source, soprattutto a livello di linguaggi di programmazione e runtime, può essere un vero vantaggio. Sebbene gli sviluppatori di Swift abbiano affermato più volte che la loro intenzione è quella di aprire completamente il linguaggio e il runtime Swift, ciò deve ancora accadere, quindi è necessaria cautela.

Detto questo, gli sviluppatori dietro Swift sono alcuni degli stessi sviluppatori dietro il progetto LLVM di lunga data. LLVM non è un'analogia perfetta, dal momento che è nato all'aperto come progetto dell'Università dell'Illinois, Urbana-Champaign. Ma a loro merito, gli sviluppatori principali sono rimasti molto aperti e impegnati con la comunità, anche dopo che la maggior parte di loro è passata a lavorare per Apple. È del tutto ragionevole aspettarsi che il linguaggio Swift continuerà a essere sviluppato (per lo più) all'aperto, anche se resta da vedere se patch e suggerimenti di funzionalità dalla community si faranno strada nel linguaggio.

Dovrei imparare Swift?

Ovviamente non c'è una risposta "taglia unica" qui. Come sempre, la scelta dello strumento giusto per il lavoro richiede una profonda conoscenza di tutti i dettagli del progetto in questione. Certamente, in questo momento, Objective-C resta la scelta “sicura” per lo sviluppo iOS, ma Swift è sicuramente degno di considerazione.

Il cambiamento più significativo che Swift apporta allo sviluppo di iOS, tuttavia, è che molti sviluppatori, per la prima volta, si porranno la domanda: "Che lingua dovrei usare?" Vista la storia di Apple, Objective-C e della piattaforma iOS, questo cambiamento da solo è piuttosto eccitante, soprattutto considerando che la scelta non è binaria. Mentre Apple ha chiarito la propria preferenza, la comunità di sviluppatori iOS in generale ha lavorato duramente per anni fornendo già risposte ancora più possibili a questa domanda.