Raphaël Sebbe parle du langage Swift

swift-banner

Ayant un peu « joué » avec l’Objective-C (langage de programmation de iOS/MacOS), je me suis demandé si le nouveau langage Swift développé par Apple pouvait apporter un réel plus, notamment pour les débutants en programmation.

Pour répondre à cette question, j’ai fait appel à mon ami Raphael Sebbe, développeur et fondateur de l’entreprise Belge Creaceed (Prizmo, hydra, etc..).

Avec son accord, voici ci-dessous, le texte intégral du mail qu’il a eu la gentilesse de m’envoyer ce jour.

Le langage Swift

Swift est une évolution intéressante, mais imparfaite à ce stade. J’essaie de toujours faire la part des choses entre le changement de ses habitudes qui est souvent désagréable, même si je suis un early adopter en général, et fonctionnalités réelles. Je suis passé par a peu près tous les langages (Java, JavaScript, Python, Obj-C, C, C++, Pascal…)  sauf Ruby et les fonctionnels comme Haskell, Caml.

Points positifs

  • C’est un langage très proche du C++ en terme de fonctionnalités (typage fort, templates, etc.)
  • Possibilité de définir ses propres opérateurs, très pratique mais aussi très dangereux pour la lisibilité du code. Il faut être très rigoureux.
  • Il a une syntaxe plus sympa, inspirée de l’Obj-C pour ce qui est des labels d’argument de méthode, et donc plus lisible que le C++.
  • Il intègre également un concept apparenté aux catégories Obj-C, les extensions. C’est très bien pour écrire du code modulaire.
  • Closures et fonctions: c’est built-in et pas un ajout comme en C++ ou même Obj-C. Un peu comme JavaScript, mais syntaxe plus efficace. C’est d’ailleurs un langage qui permet la programmation fonctionnelle, qui est assez tendance de ces jours-ci. La syntaxe est plus simple que les blocks Obj-C, et il y a qqs bonnes idées comme le raccourci pour la dernière closure, argument d’une fonction.
  • Plus de clarté dans l’intention du code. On doit marquer une fonction comme override d’une autre, et donc quand la fonction « parent » change de nom, on a directement une erreur (justifiée). Donc très bien pour détecter les bugs à la compilation.
  • Swift résout aussi le problème des headers files à maintenir (couple .h, .m), il n’y a plus qu’un seul fichier, le .swift.

La lisibilité du code peut être assez mauvaise

Points négatifs

  • En évolution constante, c’est un peu galère de maintenir du code face aux évolutions nécessaires, mais continues.
  • Le concept « d’optionnels ». Si une variable est supposée accepter la valeur « nil » (absence de valeur), elle doit être définie comme optionnelle, avec une syntaxe spécifique (le ?):
var myVar :MyClass?

Et quand on veut l’utiliser, on doit faire myVar!, après avoir testé qu’elle n’est pas nil. Il y a tout une panoplie de mécanismes complémentaires: ! -> implicitly unwrapped optionals, if let, etc.

Ca formalise l’intention du développeur et permet de détecter certains bugs à la compilation ou très tôt au runtime, mais en pratique c’est lourd à porter. On doit décider pour chaque variable si on autorise la valeur nil, avec une syntaxe spécifique. C’est un peu un boulet à trainer.

Personnellement, je préfère le choix de l’Obj-C: autoriser les message vers nil (ignorés) et utiliser des asserts / exceptions pour tester les variables quand nécessaire, qui est plus léger pour le cas moyen.

Certains développeurs aiment les optionnels, mais personnellement j’aurais souhaité que ce concept ne soit pas imposé aux développeurs.
– Manque de dynamisme par rapport à Obj-C: introspection et modification des classes au runtime est une fonctionnalité très utile et utilisée par les développeurs.
– Impedance mismatch: les APIs Cocoa ne s’interfacent pas toujours très bien avec Swift, même s’il y a amélioration dans les versions récentes (les APIs Cocoa sont marquées, pour chaque argument de méthode, comme acceptant ou pas la valeur nil). Les arrays et les strings sont maintenant des structures et plus des objets. Cela me semble être une figure de style, car les objets « immutables » de Cocoa étaient efficaces. Ce choix comporte des complications d’implémentation.
– L’édition de code dans Xcode est très lente.
– La lisibilité du code peut être assez mauvaise
– Opportunité manquée de gérer les tâches asynchrones, qui sont très répandues avec GCD sur Mac et iOS. Un peu comme Microsoft l’a fait avec async/await de C#, qui rend le code beaucoup + lisible.

« J’ai l’impression que le langage a été designé sans concertation avec des développeurs d’applications… »

Conclusions

J’ai l’impression que le langage a été designé sans concertation avec des développeurs d’applications, et sans prendre en compte des besoins de haut niveau, pour gérer des structures complexes d’application, tâche pour laquelle l’Obj-C est très bon et depuis longtemps, et que le focus a été mis sur comment faire un meilleur C++, langage bas niveau, très optimisé. C’est pas mal, mais pas 100% idéal.

J’ai fait pas mal de bugreports depuis juin 2014, comme beaucoup d’autres dévs, et pas mal de choses ont déjà évolué dans la bonne direction (mais pas les optionnels malheureusement…). C’est positif.

Nous l’utilisons dans une de nos futures apps, pour une fonction bien spécifique mais substantielle. C’est une première expérience, mais j’avoue qu’on va attendre de voir des exemples d’apps Apple l’utilisant avant de migrer à 100% sur Swift, car on s’est déjà fait avoir par le passé en migrant trop vite (Garbage Collection, abandonné qq années après…) et on en a payé les frais. [même raisonnement pour les Storyboards par ex., pratiquement pas utilisés par Apple].

Quand Apple utilisera Swift en interne de manière systématique pour ses nouveaux développements, cela voudra dire que les problèmes auront été résolus, et cela fera office de feu vert pour y aller.

Petite précision, Raphaël recommande aux débutants d’apprendre l’Objective-C à ce stade, ne serait-ce que pour la quantité de ressources disponibles sur internet (Tutos, cours,..)