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,..)

Les problèmes de Safari avec Youtube

Hier, j’ai passé une partie de ma soirée à râler devant écran, et pour cause, safari refusait systèmatiquement de lancer une vidéo sur Youtube alors que ses concurrents Firefox et Chrome le faisaient sans le moindre problème.

Ayant passé mon iMac sous Yosmite 10.10.1, je me suis demandé si le problème venait de là. Pour en avoir le coeur net, j’ai tenté de lancer une vidéo sur un MacBook Air 11’’ resté sur la version 10.10, puis sur un MacBook Pro retina 13’’ (OS X 10.10), malheureusement, le problème était identique.

Dernière chance pour moi, j’ai décidé d’activer le mode développeur de Safari, puis en me rendant dans le menu Développement > agent d’utilisateur, j’ai testé différents paramètres (Internet explorer 10, Google Chrome). Miracle ! Les vidéos se lancaient à nouveau !

Apparemment, d’après MacPlus, je n’étais donc pas le seul à rencontrer ce problème vraiment étrange ! Si vous rencontrez un telle situation à l’avenir, essayez cette astuce qui consiste à changer d’agent utilisateur…

[MàJ] : Je précise que tout est rentré dans l’ordre depuis ce matin.
[MàJ 2] : Le problème ne concernait que Safari 8, en effet en utilisant un agent utilisateur Safari 7.1 ou Safari 6.2, cela fonctionnait parfaitement.

APR : Apple Premiers Rigolos

Nerd

L’histoire qui suit est réelle, si elle n’était pas si désolante, on en rirait encore en se frappant les couilles sur le rebord de la fenêtre.

Depuis quelques temps, mon cousin a de gros soucis avec la carte graphique de son MacBook Pro 17 pouces début 2011d’ailleurs il n’est pas le seul !

Le curseur de la souris devient invisible, un glitch graphique apparait, toutes commandes se bloquent, et l’écran est coupé en deux, bref dédoublé.

Afin de palier le problème, il téléphone au SAV d’Apple pour exposer la situation. Un opérateur téléphonique lui retorque que cela doit bien venir de la carte graphique, que le problème est connu et qu’elle sera remplacée gratuitement après l’avis d’un réparateur agréé – ce dernier lui confie également qu’il a eu le même soucis avec son MacBook Pro personnel. Ce même opérateur fournit à mon cousin l’adresse d’un Apple Premium Reseller dans le 3ème arrondissement de Paris qui pourrait faire ce fameux diagnostic. Cette proposition lui convient, il se rend sur place et laisse sa machine.

AppleEuro

Une semaine plus tard, alors qu’il venait récupérer son précieux, le technicien lui indique qu’il n’a trouvé aucun problème. Mon cousin lui demande alors la méthode de test utilisé pour cela.

Réponse du technicien de l’APR: « On a fait tourner votre MacBook Pro sur Youtube plusieurs jours, et nous n’avons observé aucun problème, on en conclut donc que votre carte graphique n’a pas de défaut.. »

apr

Dépité, mon cousin va donc faire tourner de grosses applications ce week-end, afin de reproduire les problèmes d’affichage, puis les mettre sous le nez de ce soit-disant technicien – où plutôt, ce bricoleur du dimanche.

Moralité: Avec de tels techniciens, il ne faut guère s’étonner que les APR boivent le bouillon par les trous de nez !