Apprendre la programmation Swift : est-ce prêt pour Prime Time ?

Le lancement par Apple en juin dernier de Swift, un nouveau langage de programmation pour l'écriture d'applications iOS, a créé beaucoup de buzz et d'enthousiasme dans la communauté des développeurs iOS.

Depuis son lancement, de nombreux développeurs iOS ont du mal à savoir si, comment et quand passer d'Objective-C à Swift. La réponse à cette question sera bien sûr différente pour chaque équipe et chaque projet.

Il existe un certain nombre d'articles que vous pouvez lire sur de nombreux avantages de Swift. Ainsi, au lieu de ressasser ces mêmes points, dans cet article, nous nous concentrerons plutôt sur certaines des préoccupations que vous voudrez peut-être prendre en compte avant d'apprendre le développement d'applications avec Swift.

Mais d'abord, remontons un peu le temps...

Avant Swift : Vous utiliserez Objective-C, et vous l'aimerez…

Nous étions en 2010. L'iPhone n'avait pas encore 3 ans et la possibilité d'écrire des applications natives pour l'iPhone n'existait que depuis environ 2 ans. Le 8 avril de cette année-là, Apple a annoncé la version de l'iPhone OS. Le système d'exploitation de l'iPhone (c'était avant qu'il ne change de nom pour iOS) incluait de nouvelles fonctionnalités alléchantes telles que le multitâche, la commutation rapide d'applications et les services d'arrière-plan. Naturellement, les développeurs d'iPhone étaient impatients de mettre la main sur le nouveau SDK et de commencer à jouer avec toutes ces nouvelles fonctionnalités passionnantes.

Mais le SDK iPhone OS 4 contenait une bombe inattendue. Cette bombe n'était pas dans le logiciel, c'était dans l'accord d'utilisation. Avec iPhone OS 4 SDK, la section 3.3.1 du contrat de développeur a été mise à jour pour inclure le langage troublant suivant :

Les applications doivent être écrites à l'origine en Objective-C, C, C++… et seul le code écrit en C, C++ et Objective-C peut être compilé et lié directement aux API documentées.
– Section 3.3.1 du contrat de développeur du SDK iPhone OS 4

Inutile de dire que cette nouvelle restriction a surpris de nombreux développeurs. La raison officielle du changement, fournie par Steve Jobs lui-même, était d'empêcher l'utilisation d'outils multiplateformes tels que le Flash CS5 récemment annoncé. Jobs a été cité comme disant que "les couches intermédiaires entre la plate-forme et le développeur produisent finalement [sic] des applications inférieures aux normes". Mais le fait que l'approche d'Apple pour lutter contre ces "couches intermédiaires" consistait à restreindre les langages de programmation pouvant être utilisés pour écrire des applications iPhone a révélé quelque chose de plus sur la pensée d'Apple : Objective-C devrait être assez bon pour tout le monde.

On pourrait être pardonné d'être d'accord avec cette affirmation, car Objective-C a remporté le prix du "langage de programmation de l'année" du Tiobe Index deux années de suite. Mais la réalité était que la popularité d'Objective-C était fonction de l'écosystème croissant des applications, et non l'inverse. Même en 2010, de nombreuses personnes n'étaient déjà pas satisfaites d'Objective-C et, par conséquent, d'autres moyens d'écrire des applications iPhone dans d'autres langages de programmation faisaient déjà leur apparition.

Finalement, sous la pression de la communauté des développeurs dans son ensemble, Apple a annulé ces modifications de la section 3.3.1 du contrat de développeur SDK cinq mois plus tard. Pourtant, le message était clair : si vous vouliez écrire des applications pour l'iPhone, vous devriez probablement utiliser Objective-C.

… ou peut être pas. Entrez la nouvelle langue iOS Swift.

Avance rapide de 4 ans depuis cet incident jusqu'en juin 2014, lorsque Apple a présenté aux développeurs son nouveau langage, Swift. Si le message d'il y a 4 ans était qu'Apple était parfaitement satisfait d'Objective-C, alors le message envoyé par l'introduction de Swift était qu'Apple était enfin prêt à admettre la vérité. Objective-C n'est pas nécessairement le meilleur langage pour écrire des applications mobiles.

Beaucoup a été dit sur la façon dont Swift est un langage plus "moderne" qu'Objective-C. Si vous souhaitez apprendre le langage de programmation Swift, vous pouvez consulter le guide pour passer d'Objective-C à Swift.

Ce que vous devez remarquer, cependant, c'est qu'il existe deux différences importantes entre les langages Objective-C et Swift :

1. Swift n'est pas un sur-ensemble strict du langage C.
2. Swift est typé statiquement, pas typé dynamiquement.

Ne pas être un sur-ensemble strict de C signifie que Swift est libre d'utiliser des constructions de syntaxe qui ne seraient autrement pas autorisées. Cela permet, par exemple, d'implémenter des opérateurs personnalisés dans Swift.

Être typé statiquement signifie que Swift peut tirer parti de nombreuses avancées récentes dans les systèmes de typage lancés par des langages tels que Haskell.

Bien qu'il ait été en développement pendant 4 ans avant d'être révélé au public, Swift est encore un jeune langage de programmation, il comporte donc un certain nombre de mises en garde.

Compatibilité avec Objective-C

iOS partage un héritage commun avec OS X, qui à son tour tire son histoire du système d'exploitation NeXTSTEP sorti pour la première fois en 1989. NeXTSTEP a été écrit à l'origine en grande partie en Objective-C, et de nombreuses bibliothèques principales d'OS X et d'iOS retracent toutes leurs racines. le chemin du retour à ces implémentations originales. (Incidemment, c'est de là que vient le préfixe "NS" omniprésent trouvé sur les classes de base telles que NSString .) Alors que Swift pourrait théoriquement exister en l'absence de ces bibliothèques de base, la réalité est que tous les programmes Swift que vous pourriez écrire dans un proche avenir devra s'interfacer avec Objective-C.

À leur crédit, les développeurs derrière Swift ont fait un travail fantastique en rendant l'interaction avec les bibliothèques Objective-C existantes aussi indolore que possible. Cela ne veut pas dire que le processus est totalement indolore. Apple a fourni un guide utile expliquant comment appeler le code Objective-C à partir de Swift, et vice versa, mais il existe d'importantes inadéquations d'impédance à prendre en compte.

La non-concordance la plus évidente concerne peut-être les fichiers d'en-tête. Objective-C, en raison de ses racines C, nécessite toujours que les fonctions soient déclarées avant d'être appelées. Lors de l'appel à une bibliothèque, ces déclarations se trouveront dans les fichiers d'en-tête de la bibliothèque. Swift, cependant, n'utilise pas de fichiers d'en-tête. Ainsi, si vous souhaitez appeler du code Swift depuis Objective-C, vous devrez d'abord créer un "en-tête de pontage". Bien que conceptuellement, cela ne semble pas si complexe, dans la pratique, cela peut en fait être une tâche ardue.

Un autre ensemble de complications dans l'interfaçage entre Swift et Objective-C provient des différences inhérentes à leurs systèmes de type. Swift, s'inspirant d'autres langues modernes, a supprimé le concept de nil . À sa place se trouvent les types optionnels de Swift. Par exemple, une méthode qui ouvre un fichier uniquement s'il existe déjà aurait un type de retour de File? (au lieu de simplement File ) dans Swift. En suivant tous les endroits où les types sont facultatifs, le compilateur Swift peut effectivement rendre impossible la rencontre de la redoutable « erreur de pointeur nul ». C'est, bien sûr, à moins que vous n'appeliez Objective-C. Étant donné qu'Objective-C ne garantit pas de ne pas retourner nil , Swift a une catégorie spéciale de types appelés Options implicitement non enveloppées qui sont utilisées lors de l'appel de code Objective-C. Ces types peuvent être traités comme des options dans le langage Swift, avec tous les frais généraux associés requis pour la vérification de l'existence. Alternativement, ils peuvent être utilisés de la même manière que n'importe quel type non facultatif, mais si Objective - C renvoie un nil , vous vous retrouverez avec une erreur d'exécution, vous perdez donc certaines des garanties de sécurité au moment de la compilation de Swift.

Enfin, une inadéquation légèrement plus subtile à prendre en compte lors de la programmation entre Swift et Objective-C concerne la manière dont les objets et les classes sont créés sous les couvertures dans ces deux langages. Objective-C, en raison de sa nature dynamique, utilise la répartition dynamique pour appeler des méthodes sur des objets (via objc_msgSend ). Swift peut certainement utiliser la répartition dynamique, mais comme il est typé statiquement, il a également la possibilité d'utiliser une vtable pour stocker des pointeurs de fonction pour chaque méthode. Lequel de ces deux mécanismes utilise Swift dépend de plusieurs facteurs. Plane Old Swift Objects utilisera le mécanisme vtable , à moins que la classe ou les méthodes de la classe ne soient annotées à l'aide de l'attribut @objc Swift. Les classes Swift qui héritent des classes Objective-C utiliseront la répartition dynamique pour les méthodes héritées, mais pas pour les nouvelles méthodes introduites par la sous-classe (bien que, encore une fois, vous puissiez forcer l'utilisation de la répartition dynamique avec l'attribut @objc ). Quoi qu'il en soit, le code Swift pourra toujours fonctionner avec les classes Swift, mais le code Objective-C ne peut utiliser que des objets et des méthodes Swift qui ont été correctement annotés.

Plus rapide qu'Objective-C ?

Lorsque Apple a lancé son lancement, l'un des avantages de Swift qui a été particulièrement souligné était sa rapidité. Cela est compréhensible si l'on considère que l'une des raisons souvent invoquées pour expliquer la réticence d'Apple à passer de l'Objective-C à un langage de niveau supérieur était qu'Objective-C, étant essentiellement une extension du C, était capable de créer des programmes beaucoup plus rapides et plus efficaces. que quelque chose comme Python ou Ruby. Même ainsi, Objective-C n'est pas une fusée en matière de performances absolues, et une grande partie de cela peut être attribuée au typage dynamique. Ainsi, avec Swift adoptant un système de type statique, on pourrait s'attendre à ce que Swift soit au moins aussi rapide, ou plus rapide, qu'Objective-C.

Bien sûr, comme le dit le proverbe, « il y a trois types de mensonges : les mensonges, les maudits mensonges et les repères ». (Ou quelque chose comme ça…) Certes, il existe de nombreuses raisons pour lesquelles le langage Swift pourrait fonctionner plus rapidement. Malheureusement, il semble que la façon dont Swift utilise la technique ARC (Automatic Reference Counting) d'Apple pour la gestion de la mémoire entraîne parfois la génération de programmes beaucoup plus lents par le compilateur de Swift, en particulier avec des paramètres d'optimisation inférieurs (tels que ceux que vous pourriez utiliser pendant le développement). La bonne nouvelle est qu'il semble que les améliorations apportées à Swift résolvent continuellement ce problème, et il est donc probable que dans un avenir proche, Swift générera des exécutables au moins aussi rapidement, voire plus rapidement, qu'Objective-C.

Il y a cependant une autre mise en garde à la vitesse de Swift. L'intérêt de Swift est que les développeurs n'écriront pas le même code qu'ils auraient écrit en Objective-C. Qu'est-ce que cela signifie pour les performances ? Eh bien, cela signifie certainement que la comparaison des performances entre Swift et Objective-C est plus compliquée que de simples repères peuvent le révéler. Cela signifie également que la comparaison des performances d'exécution absolues des exécutables générés ne raconte que la moitié de l'histoire.

Tout le monde veut des programmes rapides, mais souvent la vitesse de développement est tout aussi importante, sinon plus. Un langage plus expressif, capable d'accomplir plus de travail en moins de lignes de code, peut être un énorme avantage à cet égard. D'autre part, lorsque vous travaillez dans un langage compilé où le cycle édition-compilation-exécution-débogage occupe une grande partie de la journée d'un programmeur, un compilateur lent peut vraiment nuire à la productivité. Bien que les preuves soient principalement anecdotiques, il semble que le compilateur Swift soit actuellement juste assez lent pour être ennuyeux, en particulier lorsque vous travaillez avec du code qui utilise le système de type avancé de Swift. Un groupe a même trouvé que la vitesse de compilation était suffisamment problématique pour motiver un retour à Objective-C.

Le compilateur

En parlant du compilateur Swift, il est lui-même la source d'encore plus de mises en garde lorsqu'on envisage de passer au nouveau langage Swift. Outre la vitesse de compilation, alors que Swift est sorti du petit groupe de développeurs travaillant avec lui chez Apple et s'est déchaîné sur les masses, le compilateur a commencé à montrer des fissures sous le stress. Il existe même un référentiel GitHub complet dédié à la collecte d'exemples de code qui entraîneront le blocage du compilateur Swift.

Il y a aussi la question de savoir comment le compilateur Swift va changer. Un autre projet sur GitHub recueille des spéculations et des analyses de la communauté sur les changements qui pourraient être en réserve pour Swift. Par exemple, les opérateurs personnalisés peuvent exercer une pression importante sur un analyseur. Initialement, les opérateurs personnalisés dans Swift ne pouvaient pas utiliser de point d'interrogation (?). Bien que cela ait été corrigé dans la dernière version de Swift, les demandes continuent d'affluer de la communauté croissante des développeurs Swift pour encore plus de flexibilité dans ce qui peut être considéré comme un opérateur personnalisé valide.

Chaque fois que vous entendez que l' analyseur d'un langage est en pleine mutation, cela devrait vous faire réfléchir. L'analyseur syntaxique d'un langage est le cœur et l'âme d'un langage de programmation. Avant qu'une sémantique de langage puisse être appliquée pour donner du sens au code, c'est l'analyseur qui détermine ce qui est et ce qui n'est pas du code valide pour commencer. Il est donc encourageant qu'Apple ait promis d'assurer un certain niveau de compatibilité d'exécution pour Swift. Cela ne garantit pas nécessairement, cependant, que le code Swift fonctionnera sans être recompilé pour chaque nouvelle version de Xcode et/ou iOS. Cela ne garantit pas non plus que vous n'aurez pas besoin de réécrire des parties de votre code Swift pour rester compatible avec les futures versions de Swift. Mais encore une fois, l'engagement d'Apple à rendre ce processus aussi indolore que possible est au moins un petit réconfort.

Communauté

Certains des pires langages de programmation jamais créés (qui resteront sans nom) ont été soutenus, longtemps après que le bon sens dit qu'ils auraient dû être relégués à la poubelle de la technologie défaillante par la seule force de leurs communautés respectives. Dans le même temps, la collection de langages de programmation vraiment sympas qui n'ont pas réussi à s'implanter faute de communauté est trop nombreuse pour être comptée. Des communautés fortes produisent des didacticiels, répondent aux questions sur Stack Overflow, passent du temps en ligne ou en personne lors de conférences pour partager des histoires, des conseils et des astuces, et écrivent et partagent des bibliothèques utiles les unes avec les autres. Lors du choix du langage à utiliser pour un projet, la communauté est certainement quelque chose à considérer.

Malheureusement, la communauté iOS/Objective-C n'a pas la meilleure réputation d'être amicale et accueillante. Cela change progressivement et l'open source joue un rôle de plus en plus important dans le développement d'Objective-C. Pourtant, à ce stade précoce, il est difficile de dire à quoi ressemblera la communauté Swift à l'avenir. Sera-t-il composé principalement de développeurs insulaires travaillant uniquement à partir des API Apple officielles et de leurs propres collections privées de code ? Ou s'agira-t-il d'une communauté dynamique de groupes partageant des conseils, des astuces et des bibliothèques utiles ?

Une autre facette du rôle de la communauté est le rôle des développeurs de Swift eux-mêmes. La tendance générale en matière de programmation a été de s'éloigner des langages de programmation et des plates-formes propriétaires pour adopter des solutions open source. Le développement Open Source, notamment au niveau des langages de programmation et des runtimes, peut être un réel avantage. Bien que les développeurs Swift aient déclaré à plusieurs reprises que leur intention était d'ouvrir complètement le langage et l'environnement d'exécution Swift, cela n'a pas encore eu lieu, la prudence s'impose donc.

Cela dit, les développeurs derrière Swift sont parmi les mêmes développeurs derrière le projet LLVM de longue date. LLVM n'est pas une analogie parfaite, car il a commencé sa vie à l'air libre en tant que projet de l'Université de l'Illinois, Urbana-Champaign. Mais à leur crédit, les principaux développeurs sont restés très ouverts et engagés avec la communauté, même après que la plupart d'entre eux soient passés à travailler pour Apple. Il est tout à fait raisonnable de s'attendre à ce que le langage Swift continue d'être développé (principalement) à l'air libre, bien qu'il reste à voir si des correctifs et des suggestions de fonctionnalités de la communauté feront leur chemin dans le langage.

Dois-je apprendre Swift ?

Il n'y a bien sûr pas de réponse "taille unique" ici. Comme toujours, choisir le bon outil pour le travail nécessite une connaissance intime de tous les détails du projet en question. Certes, à ce stade, Objective-C reste le choix "sûr" pour le développement iOS, mais Swift mérite certainement d'être pris en considération.

Le changement le plus important que Swift apporte au développement iOS, cependant, est que de nombreux développeurs vont, pour la première fois, se poser la question : « Quel langage dois-je utiliser ? » Compte tenu de l'histoire d'Apple, d'Objective-C et de la plate-forme iOS, ce changement à lui seul est plutôt excitant, d'autant plus que le choix n'est pas binaire. Alors qu'Apple a clairement indiqué sa préférence, la communauté des développeurs iOS dans son ensemble travaille dur depuis des années pour fournir encore plus de réponses possibles à cette question.