Swift vs Objective-C: 10 raisons pour lesquelles l'avenir favorise Swift

Les langages de programmation ne meurent pas facilement, mais les ateliers de développement qui s'accrochent à des paradigmes en déclin le font. Si vous développez des applications pour appareils mobiles et que vous n'avez pas étudié Swift, prenez note: Swift ne supplantera pas seulement Objective-C lorsqu'il s'agit de développer des applications pour Mac, iPhone, iPad, Apple Watch et les appareils à venir, mais il remplacera également C pour la programmation embarquée sur les plateformes Apple.

Grâce à plusieurs fonctionnalités clés, Swift a le potentiel de devenir le langage de programmation de facto pour créer des applications immersives, réactives et destinées aux consommateurs pour les années à venir.

Apple semble avoir de grands objectifs pour Swift. Il a optimisé le compilateur pour les performances et le langage pour le développement, et il fait allusion au fait que Swift est «conçu pour évoluer de« bonjour, monde »à un système d'exploitation entier» dans la documentation de Swift. Bien qu'Apple n'ait pas encore déclaré tous ses objectifs pour le langage, les lancements de Xcode 6, Playgrounds et Swift signalent ensemble l'intention d'Apple de rendre le développement d'applications plus facile et plus accessible qu'avec toute autre chaîne d'outils de développement.

Voici 10 raisons de prendre une longueur d'avance en commençant à travailler avec Swift maintenant.

1. Swift est plus facile à lire

Objective-C souffre de toutes les verrues que vous attendez d'un langage basé sur C. Pour différencier les mots-clés et les types des types C, Objective-C a introduit de nouveaux mots-clés en utilisant le symbole @. Parce que Swift n'est pas construit sur C, il peut unifier tous les mots-clés et supprimer les nombreux symboles @ devant chaque type Objective-C ou mot-clé lié à un objet.

Swift abandonne les conventions héritées. Ainsi, vous n'avez plus besoin de points-virgules pour terminer les lignes ou de parenthèses pour entourer les expressions conditionnelles à l'intérieur des instructions if / else. Un autre changement important est que les appels de méthode ne nichent pas dans l'autre résultant en enfer-bye-bye console, [[[ ]]]. Les appels de méthode et de fonction dans Swift utilisent la liste standard de paramètres séparés par des virgules entre parenthèses. Le résultat est un langage plus propre et plus expressif avec une syntaxe et une grammaire simplifiées.

Le code Swift ressemble plus étroitement à l'anglais naturel, en plus d'autres langages de programmation populaires modernes. Cette lisibilité permet aux programmeurs existants de JavaScript, Java, Python, C # et C ++ d'adopter Swift dans leur chaîne d'outils, contrairement au vilain petit canard qui était Objective-C.

2. Swift est plus facile à entretenir

L'héritage est ce qui retient Objective-C - le langage ne peut pas évoluer sans C évoluer. C exige que les programmeurs maintiennent deux fichiers de code afin d'améliorer le temps de construction et l'efficacité de la création de l'application exécutable, une exigence qui se répercute sur Objective-C.

Swift supprime l'exigence de deux fichiers. Xcode et le compilateur LLVM peuvent déterminer les dépendances et effectuer automatiquement des constructions incrémentielles dans Swift 1.2. Par conséquent, la tâche répétitive de séparation de la table des matières (fichier d'en-tête) du corps (fichier d'implémentation) appartient au passé. Swift combine l'en-tête Objective-C (.h) et les fichiers d'implémentation (.m) en un seul fichier de code (.swift).

Le système à deux fichiers d'Objective-C impose un travail supplémentaire aux programmeurs - et c'est un travail qui détourne les programmeurs de la vue d'ensemble. Dans Objective-C, vous devez synchroniser manuellement les noms de méthodes et les commentaires entre les fichiers, avec un peu de chance en utilisant une convention standard, mais cela n'est pas garanti à moins que l'équipe n'ait mis en place des règles et des révisions de code.

Xcode et le compilateur LLVM peuvent travailler en arrière-plan pour réduire la charge de travail du programmeur. Avec Swift, les programmeurs font moins de comptabilité et peuvent passer plus de temps à créer une logique d'application. Swift supprime le travail standard et améliore la qualité du code, des commentaires et des fonctionnalités pris en charge.

3. Swift est plus sûr

Un aspect intéressant d'Objective-C est la façon dont les pointeurs - en particulier les pointeurs nil (nul) - sont gérés. En Objective-C, rien ne se passe si vous essayez d'appeler une méthode avec une variable de pointeur qui est nil (non initialisée). L'expression ou la ligne de code devient une no-operation (no-op), et bien qu'il puisse sembler avantageux qu'elle ne plante pas, elle a été une énorme source de bogues. Un no-op conduit à un comportement imprévisible, qui est l'ennemi des programmeurs essayant de trouver et de réparer un crash aléatoire ou d'arrêter un comportement erratique.

Les types optionnels rendent la possibilité d'une valeur optionnelle nulle très claire dans le code Swift, ce qui signifie qu'il peut générer une erreur de compilation lorsque vous écrivez du mauvais code. Cela crée une courte boucle de rétroaction et permet aux programmeurs de coder avec intention. Les problèmes peuvent être résolus au fur et à mesure que le code est écrit, ce qui réduit considérablement le temps et l'argent que vous passerez à corriger les bogues liés à la logique des pointeurs d'Objective-C.

Traditionnellement, en Objective-C, si une valeur était renvoyée par une méthode, il était de la responsabilité du programmeur de documenter le comportement de la variable de pointeur retournée (en utilisant des commentaires et des conventions de dénomination de méthode). Dans Swift, les types optionnels et les types valeur indiquent explicitement dans la définition de méthode si la valeur existe ou si elle a le potentiel d'être facultative (c'est-à-dire que la valeur peut exister ou être nulle).

Pour fournir un comportement prévisible, Swift déclenche une panne d'exécution si une variable facultative nil est utilisée. Ce plantage fournit un comportement cohérent, ce qui facilite le processus de correction des bogues car il oblige le programmeur à résoudre le problème immédiatement. Le crash de l'exécution de Swift s'arrêtera sur la ligne de code où une variable optionnelle nil a été utilisée. Cela signifie que le bogue sera résolu plus tôt ou entièrement évité dans le code Swift.

4. Swift est unifié avec la gestion de la mémoire

Swift unifie le langage d'une manière qu'Objective-C n'a jamais. La prise en charge du comptage automatique de références (ARC) est complète sur les chemins de code procéduraux et orientés objet. En Objective-C, ARC est pris en charge dans les API Cocoa et le code orienté objet; il n'est cependant pas disponible pour le code procédural C et les API comme Core Graphics. Cela signifie qu'il devient de la responsabilité du programmeur de gérer la gestion de la mémoire lorsqu'il travaille avec les API Core Graphics et d'autres API de bas niveau disponibles sur iOS. Les énormes fuites de mémoire qu'un programmeur peut avoir en Objective-C sont impossibles dans Swift.

Un programmeur ne devrait pas avoir à penser à la mémoire de chaque objet numérique qu'il crée. Étant donné que l'ARC gère toute la gestion de la mémoire au moment de la compilation, le cerveau qui aurait été consacré à la gestion de la mémoire peut plutôt être concentré sur la logique principale de l'application et les nouvelles fonctionnalités. Étant donné que ARC dans Swift fonctionne à la fois avec du code procédural et orienté objet, il ne nécessite plus de changement de contexte mental pour les programmeurs, même lorsqu'ils écrivent du code qui touche les API de niveau inférieur - un problème avec la version actuelle d'Objective-C.

La gestion automatique et performante de la mémoire est un problème qui a été résolu, et Apple a prouvé qu'elle pouvait augmenter la productivité. L'autre effet secondaire est que Objective-C et Swift ne souffrent pas d'un Garbage Collector exécutant le nettoyage de la mémoire inutilisée, comme Java, Go ou C #. C'est un facteur important pour tout langage de programmation qui sera utilisé pour les graphiques réactifs et la saisie utilisateur, en particulier sur un appareil tactile comme l'iPhone, l'Apple Watch ou l'iPad (où le décalage est frustrant et fait percevoir aux utilisateurs qu'une application est cassée).

5. Swift nécessite moins de code

Swift réduit la quantité de code requise pour les instructions répétitives et la manipulation de chaînes. En Objective-C, travailler avec des chaînes de texte est très détaillé et nécessite de nombreuses étapes pour combiner deux informations. Swift adopte des fonctionnalités de langage de programmation modernes telles que l'ajout de deux chaînes avec un opérateur «+», qui manque dans Objective-C. La prise en charge de la combinaison de caractères et de chaînes comme celle-ci est fondamentale pour tout langage de programmation qui affiche du texte à un utilisateur sur un écran.

Le système de types de Swift réduit la complexité des instructions de code - car le compilateur peut déterminer les types. À titre d'exemple, exige des programmeurs Objective-C pour mémoriser des jetons de chaîne spéciale ( %s, %d, %@) et de fournir une liste de variables séparées par des virgules pour remplacer chaque jeton. Swift prend en charge l'interpolation de chaîne, ce qui élimine le besoin de mémoriser des jetons et permet aux programmeurs d'insérer des variables directement en ligne à une chaîne destinée à l'utilisateur, telle qu'une étiquette ou un titre de bouton. Le système d'inférence de type et l'interpolation de chaîne atténuent une source courante de plantages communs en Objective-C.

Avec Objective-C, perturber la commande ou utiliser le mauvais jeton de chaîne provoque le blocage de l'application. Ici, Swift vous soulage à nouveau du travail de comptabilité, traduisant en moins de code à écrire (code qui est maintenant moins sujet aux erreurs) en raison de sa prise en charge en ligne pour la manipulation de chaînes de texte et de données.

6. Swift est plus rapide

L'abandon des conventions C héritées a considérablement amélioré Swift sous le capot. Les références pour les performances du code Swift continuent de témoigner de l'engagement d'Apple à améliorer la vitesse à laquelle Swift peut exécuter la logique des applications.

Selon Primate Labs, fabricant du populaire outil de performance GeekBench, Swift approchait des caractéristiques de performance du C ++ pour les tâches liées au calcul en décembre 2014 à l'aide de l'algorithme de Mandelbrot.

En février 2015, Primate Labs a découvert que la version bêta de Xcode 6.3 améliorait les performances de Swift de l'algorithme GEMM - un algorithme lié à la mémoire avec accès séquentiel à de grands tableaux - d'un facteur 1,4. L'implémentation FFT initiale - un algorithme lié à la mémoire avec un accès aléatoire de grandes baies - a amélioré les performances de 2,6 fois.

D'autres améliorations ont été observées dans Swift en appliquant les meilleures pratiques, ce qui a entraîné une augmentation de 8,5 fois des performances de l'algorithme FFT (laissant C ++ avec seulement un gain de performances de 1,1 fois). Les améliorations ont également permis à Swift de surpasser C ++ pour l'algorithme de Mandelbrot d'un facteur de seulement 1,03.

Swift est presque à égalité avec C ++ pour les algorithmes FFT et Mandelbrot. Selon Primate Labs, les performances de l'algorithme GEMM suggèrent que le compilateur Swift ne peut pas vectoriser le code que le compilateur C ++ peut - un gain de performances facile qui pourrait être obtenu dans la prochaine version de Swift.

7. Moins de conflits de noms avec les projets open source

Un problème qui a tourmenté le code Objective-C est son manque de support formel pour les espaces de noms, qui était la solution de C ++ aux collisions de noms de fichiers de code. Lorsque cette collision de noms se produit dans Objective-C, il s'agit d'une erreur de l'éditeur de liens et l'application ne peut pas s'exécuter. Des solutions de contournement existent, mais elles présentent des pièges potentiels. La convention courante consiste à utiliser des préfixes de deux ou trois lettres pour différencier le code Objective-C écrit, par exemple, par Facebook par rapport à votre propre code.

Swift fournit des espaces de noms implicites qui permettent au même fichier de code d'exister dans plusieurs projets sans provoquer d'échec de construction et nécessitant des noms tels que NSString (Next Step - la société de Steve Jobs après avoir été viré d'Apple) ou CGPoint (Core Graphics). En fin de compte, cette fonctionnalité de Swift maintient les programmeurs plus productifs et signifie qu'ils n'ont pas à faire la comptabilité qui existe dans Objective-C. Vous pouvez voir l'influence de Swift avec des noms simples comme Array, Dictionary et String au lieu de NSArray, NSDictionary et NSString, qui sont nés du manque d'espaces de noms dans Objective-C.

Avec Swift, les espaces de noms sont basés sur la cible à laquelle appartient un fichier de code. Cela signifie que les programmeurs peuvent différencier les classes ou les valeurs à l'aide de l'identificateur d'espace de noms. Ce changement dans Swift est énorme. Cela facilite grandement l'incorporation de projets, de frameworks et de bibliothèques open source dans votre code. Les espaces de noms permettent à différentes éditeurs de logiciels de créer les mêmes noms de fichiers de code sans se soucier des collisions lors de l'intégration de projets open source. Désormais, Facebook et Apple peuvent utiliser un fichier de code objet appelé FlyingCar.swift sans aucune erreur ni échec de construction.

8. Swift prend en charge les bibliothèques dynamiques

Le plus grand changement de Swift qui n'a pas reçu suffisamment d'attention est le passage des bibliothèques statiques, qui sont mises à jour dans les principales versions (iOS 8, iOS 7, etc.), aux bibliothèques dynamiques. Les bibliothèques dynamiques sont des morceaux de code exécutables qui peuvent être liés à une application. Cette fonctionnalité permet aux applications Swift actuelles de se lier à des versions plus récentes du langage Swift au fur et à mesure de son évolution.

Le développeur soumet l'application avec les bibliothèques, qui sont toutes deux signées numériquement avec le certificat de développement pour garantir l'intégrité (bonjour, NSA). Cela signifie que Swift peut évoluer plus rapidement que iOS, ce qui est une exigence pour un langage de programmation moderne. Les modifications apportées aux bibliothèques peuvent toutes être incluses avec la dernière mise à jour d'une application sur l'App Store, et tout fonctionne simplement.

Les bibliothèques dynamiques n'ont jamais été prises en charge sur iOS jusqu'au lancement de Swift et iOS 8, même si les bibliothèques dynamiques sont prises en charge sur Mac depuis très longtemps. Les bibliothèques dynamiques sont externes à l'exécutable de l'application, mais sont incluses dans le bundle d'applications téléchargé depuis l'App Store. Il réduit la taille initiale d'une application lors de son chargement en mémoire, car le code externe n'est lié que lorsqu'il est utilisé.

La possibilité de différer le chargement dans une application mobile ou une application intégrée sur Apple Watch améliorera les performances perçues par l'utilisateur. C'est l'une des distinctions qui rendent l'écosystème iOS plus réactif. Apple s'est concentré sur le chargement uniquement des actifs, des ressources et désormais du code compilé et lié à la volée. Le chargement à la volée réduit les temps d'attente initiaux jusqu'à ce qu'une ressource soit réellement nécessaire pour s'afficher à l'écran.