Swift vs Objective-C: 10 motivi per cui il futuro preferisce Swift

I linguaggi di programmazione non muoiono facilmente, ma i negozi di sviluppo che si aggrappano a paradigmi in dissolvenza sì. Se stai sviluppando app per dispositivi mobili e non hai studiato Swift, prendi nota: Swift non solo sostituirà Objective-C quando si tratta di sviluppare app per Mac, iPhone, iPad, Apple Watch e dispositivi futuri, ma sostituirà anche C per la programmazione embedded su piattaforme Apple.

Grazie a diverse funzionalità chiave, Swift ha il potenziale per diventare il linguaggio di programmazione de facto per la creazione di applicazioni coinvolgenti, reattive e rivolte ai consumatori per gli anni a venire.

Apple sembra avere grandi obiettivi per Swift. Ha ottimizzato il compilatore per le prestazioni e il linguaggio per lo sviluppo e allude al fatto che Swift è "progettato per scalare da 'ciao mondo' a un intero sistema operativo" nella documentazione di Swift. Sebbene Apple non abbia ancora dichiarato tutti i suoi obiettivi per il linguaggio, i lanci di Xcode 6, Playgrounds e Swift insieme segnalano l'intenzione di Apple di rendere lo sviluppo di app più facile e più accessibile rispetto a qualsiasi altra catena di strumenti di sviluppo.

Ecco 10 motivi per anticipare il gioco iniziando a lavorare con Swift ora.

1. Swift è più facile da leggere

Objective-C soffre di tutte le verruche che ti aspetteresti da un linguaggio basato su C. Per differenziare parole chiave e tipi dai tipi C, Objective-C ha introdotto nuove parole chiave utilizzando il simbolo @. Poiché Swift non è basato su C, può unificare tutte le parole chiave e rimuovere i numerosi simboli @ davanti a ogni tipo di Objective-C o parola chiave relativa agli oggetti.

Swift abbandona le convenzioni legacy. Pertanto, non è più necessario il punto e virgola per terminare le righe o le parentesi per racchiudere le espressioni condizionali all'interno delle istruzioni if ​​/ else. Un altro grande cambiamento è che le chiamate di metodo non lo fanno il nido dentro l'altro con conseguente staffa inferno-bye-bye, [[[ ]]]. Le chiamate a metodi e funzioni in Swift utilizzano l'elenco di parametri separati da virgole standard del settore tra parentesi. Il risultato è un linguaggio più pulito ed espressivo con una sintassi e una grammatica semplificate.

Il codice Swift ricorda più da vicino l'inglese naturale, oltre ad altri moderni linguaggi di programmazione popolari. Questa leggibilità rende più facile per i programmatori esistenti di JavaScript, Java, Python, C # e C ++ adottare Swift nella loro catena di strumenti, a differenza del brutto anatroccolo che era Objective-C.

2. Swift è più facile da mantenere

L'eredità è ciò che trattiene Objective-C: il linguaggio non può evolversi senza che il C si evolva. C richiede ai programmatori di mantenere due file di codice al fine di migliorare il tempo di compilazione e l'efficienza della creazione di app eseguibili, un requisito che viene trasferito a Objective-C.

Swift elimina il requisito di due file. Xcode e il compilatore LLVM possono capire le dipendenze ed eseguire automaticamente build incrementali in Swift 1.2. Di conseguenza, il compito ripetitivo di separare il sommario (file di intestazione) dal corpo (file di implementazione) è un ricordo del passato. Swift combina l'intestazione Objective-C (.h) e i file di implementazione (.m) in un unico file di codice (.swift).

Il sistema a due file di Objective-C impone un lavoro aggiuntivo ai programmatori, ed è il lavoro che distrae i programmatori dal quadro più ampio. In Objective-C devi sincronizzare manualmente i nomi dei metodi ei commenti tra i file, si spera usando una convenzione standard, ma ciò non è garantito a meno che il team non abbia regole e revisioni del codice in atto.

Xcode e il compilatore LLVM possono lavorare dietro le quinte per ridurre il carico di lavoro del programmatore. Con Swift, i programmatori fanno meno contabilità e possono dedicare più tempo alla creazione della logica dell'app. Swift elimina il lavoro standard e migliora la qualità del codice, dei commenti e delle funzionalità supportate.

3. Swift è più sicuro

Un aspetto interessante di Objective-C è il modo in cui vengono gestiti i puntatori, in particolare i puntatori nulli (nulli). In Objective-C, non succede nulla se provi a chiamare un metodo con una variabile puntatore che è nulla (non inizializzata). L'espressione o la riga di codice diventa una non operazione (nessuna operazione) e, sebbene possa sembrare vantaggioso che non si blocchi, è stata un'enorme fonte di bug. Un no-op porta a un comportamento imprevedibile, che è il nemico dei programmatori che cercano di trovare e riparare un crash casuale o fermare un comportamento irregolare.

I tipi opzionali rendono molto chiara la possibilità di un valore opzionale nullo nel codice Swift, il che significa che può generare un errore del compilatore mentre scrivi codice errato. Questo crea un breve ciclo di feedback e consente ai programmatori di programmare intenzionalmente. I problemi possono essere risolti durante la scrittura del codice, il che riduce notevolmente la quantità di tempo e denaro da spendere per correggere i bug relativi alla logica del puntatore da Objective-C.

Tradizionalmente, in Objective-C, se un valore veniva restituito da un metodo, era responsabilità del programmatore documentare il comportamento della variabile puntatore restituita (usando commenti e convenzioni di denominazione dei metodi). In Swift, i tipi opzionali e i tipi di valore rendono esplicitamente chiaro nella definizione del metodo se il valore esiste o se ha il potenziale per essere opzionale (ovvero, il valore può esistere o può essere nullo).

Per fornire un comportamento prevedibile, Swift attiva un arresto anomalo del runtime se viene utilizzata una variabile facoltativa nulla. Questo arresto anomalo fornisce un comportamento coerente, che facilita il processo di correzione dei bug perché costringe il programmatore a risolvere il problema immediatamente. L'arresto anomalo del runtime di Swift si interromperà sulla riga di codice in cui è stata utilizzata una variabile facoltativa nulla. Ciò significa che il bug verrà risolto prima o evitato completamente nel codice Swift.

4. Swift è unificato con la gestione della memoria

Swift unifica il linguaggio in un modo che Objective-C non ha mai fatto. Il supporto per il conteggio automatico dei riferimenti (ARC) è completo nei percorsi di codice procedurale e orientato agli oggetti. In Objective-C, ARC è supportato all'interno delle API Cocoa e del codice orientato agli oggetti; non è disponibile, tuttavia, per codice C procedurale e API come Core Graphics. Ciò significa che diventa responsabilità del programmatore gestire la gestione della memoria quando si lavora con le API grafiche di base e altre API di basso livello disponibili su iOS. Le enormi perdite di memoria che un programmatore può avere in Objective-C sono impossibili in Swift.

Un programmatore non dovrebbe pensare alla memoria per ogni oggetto digitale che crea. Poiché ARC gestisce tutta la gestione della memoria in fase di compilazione, le capacità intellettuali che sarebbero state destinate alla gestione della memoria possono invece essere concentrate sulla logica delle app di base e sulle nuove funzionalità. Poiché ARC in Swift funziona sia con codice procedurale che orientato agli oggetti, non richiede più cambi di contesto mentale per i programmatori, anche mentre scrivono codice che tocca API di livello inferiore, un problema con la versione corrente di Objective-C.

La gestione automatica e ad alte prestazioni della memoria è un problema che è stato risolto e Apple ha dimostrato di poter aumentare la produttività. L'altro effetto collaterale è che sia Objective-C che Swift non soffrono di un Garbage Collector che esegue la pulizia della memoria inutilizzata, come Java, Go o C #. Questo è un fattore importante per qualsiasi linguaggio di programmazione che verrà utilizzato per la grafica reattiva e l'input dell'utente, specialmente su un dispositivo tattile come iPhone, Apple Watch o iPad (dove il ritardo è frustrante e fa percepire agli utenti che un'app non funziona).

5. Swift richiede meno codice

Swift riduce la quantità di codice richiesta per istruzioni ripetitive e manipolazione di stringhe. In Objective-C, lavorare con stringhe di testo è molto prolisso e richiede molti passaggi per combinare due informazioni. Swift adotta le funzionalità del linguaggio di programmazione moderno come l'aggiunta di due stringhe insieme a un operatore "+", che manca in Objective-C. Il supporto per la combinazione di caratteri e stringhe come questo è fondamentale per qualsiasi linguaggio di programmazione che visualizza il testo a un utente su uno schermo.

Il sistema dei tipi in Swift riduce la complessità delle istruzioni del codice, poiché il compilatore può capire i tipi. Come esempio, Objective-C richiede programmatori memorizzare speciali gettoni corda ( %s, %d, %@) e fornire un elenco separato da virgole di variabili per sostituire ogni token. Swift supporta l'interpolazione delle stringhe, che elimina la necessità di memorizzare i token e consente ai programmatori di inserire variabili direttamente in linea in una stringa rivolta all'utente, come un'etichetta o il titolo di un pulsante. Il sistema di inferenza del tipo e l'interpolazione di stringhe mitigano una fonte comune di arresti anomali comuni in Objective-C.

Con Objective-C, incasinare l'ordine o utilizzare il token di stringa sbagliato causa l'arresto anomalo dell'app. In questo caso, Swift ti solleva nuovamente dal lavoro di contabilità, traducendo in meno codice da scrivere (codice che ora è meno soggetto a errori) grazie al suo supporto in linea per la manipolazione di stringhe di testo e dati.

6. Swift è più veloce

L'abbandono delle convenzioni C legacy ha notevolmente migliorato Swift sotto il cofano. I benchmark per le prestazioni del codice Swift continuano a indicare l'impegno di Apple nel migliorare la velocità con cui Swift può eseguire la logica dell'app.

Secondo Primate Labs, creatori del popolare strumento per le prestazioni GeekBench, Swift si stava avvicinando alle caratteristiche delle prestazioni del C ++ per le attività legate al calcolo nel dicembre 2014 utilizzando l'algoritmo di Mandelbrot.

Nel febbraio 2015, Primate Labs ha scoperto che Xcode 6.3 Beta ha migliorato le prestazioni di Swift dell'algoritmo GEMM, un algoritmo legato alla memoria con accesso sequenziale di array di grandi dimensioni, di un fattore di 1,4. L'implementazione FFT iniziale, un algoritmo legato alla memoria con accesso casuale di array di grandi dimensioni, ha avuto un miglioramento delle prestazioni di 2,6 volte.

Ulteriori miglioramenti sono stati osservati in Swift applicando le migliori pratiche, con un conseguente aumento di 8,5 volte per le prestazioni dell'algoritmo FFT (lasciando C ++ con un guadagno di prestazioni di solo 1,1 volte). I miglioramenti hanno anche consentito a Swift di superare il C ++ per l'algoritmo di Mandelbrot di un fattore di appena 1,03.

Swift è quasi alla pari con C ++ sia per gli algoritmi FFT che per Mandelbrot. Secondo Primate Labs, le prestazioni dell'algoritmo GEMM suggeriscono che il compilatore Swift non può vettorializzare il codice che il compilatore C ++ può fare - un facile guadagno di prestazioni che potrebbe essere ottenuto nella prossima versione di Swift.

7. Meno conflitti di nomi con progetti open source

Un problema che ha afflitto il codice Objective-C è la sua mancanza di supporto formale per gli spazi dei nomi, che era la soluzione di C ++ alle collisioni di nomi di file di codice. Quando questa collisione di nomi si verifica in Objective-C, è un errore del linker e l'app non può essere eseguita. Esistono soluzioni alternative, ma presentano potenziali insidie. La convenzione comune è quella di utilizzare un prefisso di due o tre lettere per differenziare il codice Objective-C scritto, ad esempio, da Facebook rispetto al proprio codice.

Swift fornisce spazi dei nomi impliciti che consentono lo stesso file di codice di esistere in più progetti senza causare un errore di compilazione e richiedere nomi come NSString (Next Step - la società di Steve Jobs dopo essere stata licenziata da Apple) o CGPoint (Core Graphics). In definitiva, questa funzionalità in Swift mantiene i programmatori più produttivi e significa che non devono fare la contabilità esistente in Objective-C. Puoi vedere l'influenza di Swift con nomi semplici come Array, Dictionary e String invece di NSArray, NSDictionary e NSString, che sono nati dalla mancanza di spazi dei nomi in Objective-C.

Con Swift, gli spazi dei nomi si basano sulla destinazione a cui appartiene un file di codice. Ciò significa che i programmatori possono differenziare classi o valori utilizzando l'identificatore dello spazio dei nomi. Questo cambiamento in Swift è enorme. Facilita notevolmente l'integrazione di progetti, framework e librerie open source nel codice. Gli spazi dei nomi consentono a diverse società di software di creare gli stessi nomi di file di codice senza doversi preoccupare delle collisioni durante l'integrazione di progetti open source. Ora sia Facebook che Apple possono utilizzare un file di codice oggetto chiamato FlyingCar.swift senza errori o errori di compilazione.

8. Swift supporta le librerie dinamiche

Il più grande cambiamento in Swift che non ha ricevuto abbastanza attenzione è il passaggio dalle librerie statiche, che vengono aggiornate nelle principali versioni (iOS 8, iOS 7 e così via), alle librerie dinamiche. Le librerie dinamiche sono blocchi eseguibili di codice che possono essere collegati a un'app. Questa funzione consente alle app Swift attuali di collegarsi alle versioni più recenti della lingua Swift man mano che si evolve nel tempo.

Lo sviluppatore invia l'app insieme alle librerie, entrambe firmate digitalmente con il certificato di sviluppo per garantirne l'integrità (ciao, NSA). Ciò significa che Swift può evolversi più velocemente di iOS, che è un requisito per un linguaggio di programmazione moderno. Le modifiche alle librerie possono essere tutte incluse con l'ultimo aggiornamento di un'app su App Store e tutto funziona semplicemente.

Le librerie dinamiche non sono mai state supportate su iOS fino al lancio di Swift e iOS 8, anche se le librerie dinamiche sono state supportate su Mac da molto tempo. Le librerie dinamiche sono esterne all'eseguibile dell'app, ma sono incluse nel pacchetto dell'app scaricato dall'App Store. Riduce la dimensione iniziale di un'app mentre viene caricata in memoria, poiché il codice esterno è collegato solo quando viene utilizzato.

La possibilità di posticipare il caricamento in un'app mobile o in un'app incorporata su Apple Watch migliorerà le prestazioni percepite dall'utente. Questa è una delle distinzioni che rendono l'ecosistema iOS più reattivo. Apple si è concentrata sul caricamento solo di risorse, risorse e ora codice compilato e collegato al volo. Il caricamento al volo riduce i tempi di attesa iniziali fino a quando una risorsa è effettivamente necessaria per la visualizzazione sullo schermo.