dotSwift 2017

Le 27 Janvier dernier, nous avons été à la dotSwift, conférence se déroulant à Paris autour du « nouveau » langage d’Apple : Swift. Le cru 2016 nous ayant laissé sur notre faim, nous nous demandions à quoi nous attendre. Au final, nous n'avons pas été déçus. Cette demi-journée était intéressante et est de bon augure sur ce que pourrait donner la dotSwift dans les années futures.

Cette année, la conférence a abordé 3 thèmes :

• Les nouveautés du langage (avec Swift 3) et ses bonnes pratiques
• Swift sur les autres plateformes (non Apple) : serveur linux et IoT
• Retour d’expérience sur l’utilisation de Swift sur des cas d’usages complexes

Les spécificités du langage

Ce premier thème a abordé les questions récurrentes sur le « protocol-oriented language », les generics et les autres spécificités qu’apportent Swift par rapport à l’Objective-C.

Tout d’abord Marin Todorov, de Realm, nous a parlé de RxSwift. La facilité de chaîner les appels est un point clairement mis en avant par Marin. Il nous a rappelé qu’il est facile de faire du MVVM avec cette technologie et de découper un traitement complexe en plusieurs, plus simples et spécifiques.

Ensuite, Michele Titolo nous a dressé un tableau sur l’état des generics et leur devenir. Au début de son talk, elle nous a présenté ce qui est la principale force des generics : le typage est au final laissé à l’utilisateur de la classe (ou de la librairie). Pour mieux comprendre comment et quand s’en servir, Michele nous dit tout simplement que la meilleure documentation est : de regarder comment Apple s’en sert dans la « standard library » (sigh). Elle nous rappelle également qu’il y a un Generic Manifesto et invite toute la communauté des développeurs Swift à y contribuer, et plus largement au langage dans son ensemble.

Enfin, la plupart des lightning talks avait comme sujet une feature du langage :

• Saul Mora nous rappelle que nous pouvons mêler du Swift avec le côté dynamique de l’objective C pour jouer avec le Runtime.
• Dimitri Dupuis-Latour nous a présenté son astuce pour faire des sous-classes de struct : l’utilisation des enums.
• Greg Lhotellier a conté la “malédiction” de l'héritage et montré qu'il est possible de s'en défaire... sauf si on fait de l'UIKit.
• Erica Sadun nous a conseillé d'utiliser les variables shadows lorsqu'il s'agissait d'unwrapper les optionnels : une bonne pratique pour améliorer la lisibilité du code.

Notre avis : les lightning talks n'ont pas abordé de grande nouveauté par rapport à ce qu'on pouvait déjà voir à la WWDC ou dans d'autres conférences des années passées. Le sujet de Michele a abordé avec un autre regard les generics en ne les présentant pas comme nouvelle solution ultime, mais clairement comme une nouvelle corde à notre arc.

Swift en dehors d’Apple

Ian Partridge, qui travaille chez IBM sur le framework Kitura, nous a partagé les difficultés rencontrées sur l’utilisation du langage d’Apple sur Linux. Le principal frein au développement est bien entendu le portage de Foundation et de libdispatch sur les distributions Linux. Ces dernières étant écrites en Objective-C sur les architectures Darwin, elles n’existent pas telles quelles ailleurs. Un des progrès que voyait Ian au développement de Swift sur serveur est la possibilité laissée aux équipes Front de développer leur propre middleware dans le langage qu’elles maîtrisent :

• Front web : javascript (avec nodejs pour le back)
• iOS : swift avec Kitura comme exemple de framework pour le développement du back

Ensuite, Bernet Holland nous a parlé de l’usage dans le langage dans l’IoT. Il met en garde ceux qui veulent utiliser cette technologie sur les objets connectés car le simulateur ne peut plus être utilisé. Ainsi, il préconise de créer son propre simulateur d’appareil et de mettre en place une couche d’abstraction avec les drivers. Sa dernière recommandation a été d’insister sur les tests unitaires : indispensables dans le monde du hardware.

James Duncan Davison, architecte chez Microsoft et qui clôturait la conférence, comparait la création de Swift et ses possibilités à celle de Java en son temps. En effet, pour lui, la meilleure contribution d’Apple à l’Open Source est la llvm. Il fait le parallèle entre l’usage de la llvm et le meilleur de Java : sa VM et son bytecode. En fin de compte, Swift est indépendant de la plateforme sur laquelle il tourne (n.d.r. : enfin, presque… bientôt…).

Notre avis : Sans tomber dans les clichés où Swift pourrait être vu comme génial, même sur serveur, les conférenciers ont eu un discours avec du recul et objectif sur ce thème. Mais le langage porte encore un certain nombre d’espérances et possibilités, notamment grâce aux outils sur lesquels il est construit : la llvm.

Usage concret de Swift

Drew McCormack, qui travaille aujourd'hui pour Sketch, nous a exposé la problématique de sauvegarde qu'ils rencontrent sur le produit. Il faut savoir qu'il est nécessaire pour un outil comme celui-ci de faire des sauvegardes incrémentales sur des informations volumineuses. Pour l'utilisateur, être capable en un clic de revenir en arrière et d'effacer sa dernière modification est primordial. Pour pouvoir simplifier la sauvegarde, la structure de données mise en place est celle d'un arbre (binaire ?!). Cependant, pour s'affranchir des problèmes de concurrence, cet arbre est immutable. D'où la problématique suivante de la taille des données à sauvegarder lorsqu'on souhaite passer à une version suivante de l'arbre de données : tout recopier serait trop volumineux en temps et en consommation mémoire. La solution que Drew a mise en place est celle de décomposer la sauvegarde en éléments plus petits : seuls les fils et les parents directs d'un nœud modifié sont sauvegardés, et non les nœuds de même niveau.

Puis, Károly Lőrentey nous a parlé d’algorithmie et de la façon d’optimiser une structure gérant une liste d’éléments qui est performante lors des recherches. Son but était de montrer le processus de réflexion pour optimiser les Array actuels, tout en gardant une écriture assez simple. Au final, sa solution a été d’écrire en Swift l’algorithme d’un BTree. Son code est disponible sur Github et il encourage quiconque ayant des propositions d’amélioration de son code à lui faire un retour.

Notre avis : Ces retours d’expérience ne sont pas spécifiques à Swift. Cependant, ils permettent de partager une maturité d’utilisation et de mise en pratique de cet outil jeune dans des cas divers et complexes.

Le fin mot

La meilleure conclusion de cette demi-journée pourrait paraphraser la conférence de Roy Marmelstein. Il nous a rappelé que Swift, comme toute technologie hype, n’est en aucun cas une « silver bullet ». Tous les talks que nous venions de voir à propos des nouveautés sur le langage sont intéressantes (protocol oriented, Rx, …) et donnent envie de jouer avec. Cependant, elles ne répondent pas par magie à tous les problèmes et ne se suffisent pas à elles seules pour nous donner la solution ultime. Roy confia même lors de l’interview de Daniel qu’il ne se sert pas aujourd’hui de Swift pour des projets en production…

Swift est le sens de l’histoire, car lorsque Apple propose une technologie, nous ne sommes en réalité qu’à quelques années avant qu’il l’impose à tout son écosystème. Les concepts apportés par le langage répondent à de nouveaux besoins, comme la plupart des autres “nouveaux” langages (i.e. Kotlin, Clojure, Scala, ...). Cependant aucun n’est un couteau suisse magique qui permet une meilleure productivité et la résolution de tous les problèmes (sans une connaissance approfondie des concepts qu’ils apportent).

Un autre maître mot est revenu tout au long de la conférence : n’hésitez pas à contribuer au langage. Il est ouvert et ne demande qu’à s’améliorer avec les apports de chacun d’entre nous.