Développeurs : les petites nouveautés de Swift 4.2, en attendant Swift 5

Nicolas Furno |

Pour la première fois depuis la présentation initiale de Swift à la WWDC 2014, Apple n’a pas présenté de mise à jour majeure à sa conférence dédiée aux développeurs. La cinquième version de Swift a bien été évoquée à la WWDC 2018, mais elle sortira l’année prochaine. Un retard par rapport au planning initial qui prévoyait un lancement cette année. Pour autant, les développeurs ne sont pas repartis bredouilles de San José.

La première bêta de Swift 4.2 a été publiée dans la foulée de la conférence et cette version contient plusieurs nouveautés détaillées dans une session de la WWDC 2018. Petit tour d’horizon rapide de ce qui va changer dès la rentrée avec Swift 4.2, et surtout en 2019 avec Swift 5.

Swift 4.2, une étape de parcours pour aider les développeurs

Même si elle a le numéro de version d’une mise à jour mineure, Swift 4.2 est une version importante, a clairement expliqué Apple pendant la session dédiée à son langage de développement. Néanmoins, cela ne se verra pas forcément, puisque c’est avant tout une étape significative vers Swift 5 qui sortira dans un deuxième temps. Précisons encore que cette mise à jour est actuellement bêta et qu’elle sera finalisée en même temps que toutes les autres nouveautés logicielles, à l’automne prochain.

Comme avec iOS 12, les ingénieurs de Cupertino se sont concentrés sur la vitesse pour Swift 4.2. En particulier, les compilations d’apps écrites avec cette version sont plus rapides lors de la phase de debug, c'est-à-dire quand le développeur teste des changements en local, dans le simulateur ou directement sur un appareil. En fonction du projet, on peut attendre des compilations plus de deux fois plus rapides avec Swift 4.2 et Xcode 10.

Les progrès viennent surtout de l’outil de développement d’Apple, comme nous vous l’expliquions dans un précédent article. La compilation se fait en parallèle, ce qui explique d’ailleurs que les gains seront plus significatifs sur les Mac qui disposent d’un grand nombre de cœurs. Par ailleurs, Apple a optimisé le processus pour réduire le nombre de tâches redondantes et ainsi gagner du temps pendant la création d’une app.

Xcode, toujours, propose de nouvelles options pour les compilations. Pendant la phase de debug, quand le développeur teste son app sans la publier, une préférence permet de réduire l’optimisation et ainsi compiler le programme plus rapidement, au détriment des performances. Du côté du langage, plusieurs optimisations ont été menées, notamment dans la gestion du texte, à la fois pour améliorer la vitesse d’exécution et l’utilisation de la mémoire.

Notons aussi que Xcode 10 dispose d’une option qui optimise la compilation pour le poids du code en langage machine généré dans le processus. Ça ne réduira pas nécessairement le poids de l’app elle-même, puisque cela dépend avant tout des ressources annexes, par exemple des images utilisées par l’app. Mais c’est un levier proposé aux développeurs pour qui les performances brutes ne sont pas l’essentiel. En échange d’une réduction de 10 à 30 % du code généré, la baisse de performances se limite à 5 % en général d’après Apple.

Depuis la sortie de Swift 4, la syntaxe du langage est désormais stable, ce qui veut dire que des lignes de code écrites pour Swift 4.0 seront parfaitement compatibles avec la version 4.1 sortie il y a quelques mois, et avec la 4.2 qui sortira à l’automne. C’était une promesse d’Apple l’an dernier et l’entreprise s’y tient logiquement, mais cela n’empêche pas cette version d’introduire plusieurs nouveautés.

Nous n’allons pas détailler ici les nouvelles fonctions proposées cette année aux développeurs. Elles sont évoquées dans la session d’Apple ainsi que résumées dans ce Swift Playground interactif qui permet de les tester directement. Parmi toutes les nouveautés, évoquons tout de même celle qui est la plus facile à comprendre et expliquer : Swift 4.2 dispose d’une méthode simple pour générer des nombres aléatoires. Aussi étonnant que cela puisse paraître, le langage d'Apple ne proposait rien de tel auparavant et les développeurs devaient utiliser du C pour cette fonction assez basique et courante.

Xcode 10 propose de convertir le code écrit en Swift dans la dernière version du langage. Ce qui permet de bénéficier des nouvelles fonctions dans un projet, automatiquement quand c’est possible.

Point important, Xcode 10 sera la dernière version à prendre en charge le « mode Swift 3 » et donc à pouvoir compiler des apps écrites avec cette version du langage. Xcode 11 commencera avec Swift 4.0 au minimum et tous les développeurs devront avoir converti leur projet à cette date… ou bien continuer à utiliser une ancienne version. Ce qui est toujours possible, Xcode 9 restant disponible et pris en charge pendant un an encore au moins.

À ce sujet, macOS Mojave réduira toutefois les options, puisque ni Xcode 7, ni Xcode 8 ne peuvent être lancés sur ce système, alors que c’était encore possible jusqu’à High Sierra. On pourra en revanche continuer d’utiliser Xcode 9, qui est d’ailleurs installé par défaut en parallèle de Xcode 10 pendant la phase de bêta. Swift 3 sera donc la version la plus ancienne du langage qu’il est possible de compiler sur un Mac et Apple est très claire sur le sujet, cela ne devrait pas durer.

Xcode 7 refuse obstinément de se lancer sur macOS Mojave, au moins à ce stade du développement. C’était la dernière version capable de compiler du code Swift 2.

Swift 5 : enfin l’intégration au système

Swift 4 devait apporter la stabilité du code source et la stabilité des binaires, deux enjeux importants pour généraliser le langage et qu’il serve dans tous les cas de figure (lire : La stabilité, principal enjeu de Swift 4). Finalement, seul le code source a été stabilisé l’an dernier et ce n’est toujours pas en 2018 que l’édifice sera complété. Il faudra attendre Swift 5, prévu pour le début de l’année prochaine comme on le disait en préambule, pour bénéficier de la stabilité ABI.

Pour faire (très) simple, les ABI (Application Binary Interface) sont des briques de bas niveau qui font le lien entre l’app écrite par le développeur et le langage machine exécuté par le processeur. Avec Objective-C, ces briques sont intégrées directement dans iOS (ainsi que macOS, watchOS et tvOS) et une app peut compter dessus sans problème, quelle que soit la version du système. Swift a commencé son existence sans cette assurance : chaque app doit intégrer les ABI dans ses ressources, les systèmes ne fournissent rien.

Chaque app écrite en Swift doit embarquer ces fichiers avec tout le reste pour fonctionner correctement sous iOS. À partir de Swift 5, ces fichiers seront intégrés directement dans le système.

Quand un langage de développement est tout nouveau, cette approche reste indispensable pour ne pas bloquer ses évolutions dans les premiers temps. Swift a beaucoup évolué en quatre ans et les ABI ont été modifiées à plusieurs reprises pour s’adapter aux changements apportés au langage. Mais la contrepartie, c’est qu’une app créée avec Swift 1 risque de ne plus bien fonctionner, voire de ne plus fonctionner du tout aujourd'hui. Chaque mise à jour du système nécessite aussi une mise à jour des ABI et donc une nouvelle compilation.

Swift se stabilise, Apple a cessé d’introduire des changements cassants dans le code source et l’entreprise travaille depuis plusieurs années sur la stabilité ABI. Elle devrait enfin arriver en 2019 et l’entreprise a déjà annoncé que les mises à jour annuelles correspondantes de ses systèmes d’exploitation seront les premières à intégrer les binaires. À partir d’iOS 13 et de macOS 10.15, les développeurs pourront compiler une app sans ABI, ce qui permettra d’alléger le fichier final et apportera quelques optimisations.

Du côté du poids des apps, le gain pourra être très significatif pour les plus légères, comme notre app iOS. La version actuelle d’iGeneration iOS pèse environ 77 Mo, dont 27 Mo rien que pour les binaires indispensables à Swift. Plus du tiers du poids total de l’app pourra être éliminé quand ces nouveautés seront déployées. Apple promet d’autres gains pour les utilisateurs : les temps de lancement devraient être plus rapides, ce sera aussi un gain en matière de mémoire vive consommée, bref des performances en hausse grâce à cette meilleure intégration.

Pour les développeurs, Swift 5 sera l’étape à partir de laquelle ils auront l’assurance d’écrire du code et surtout de créer des apps qui fonctionneront sans problèmes sur les futures versions des OS Apple. Naturellement, il y aura toujours des changements dans les API et des nouveautés à prendre correctement en charge. Mais jusque-là, même les apps les plus basiques pouvaient casser à chaque mise à jour annuelle d’iOS et des autres systèmes.

Certains attendaient cette étape pour franchir le pas et abandonner Objective-C au profit de Swift, la version 5.0 devrait ainsi attirer davantage de développeurs. Y compris au sein d’Apple, où Swift reste encore le langage minoritaire, même s’il gagne du terrain chaque année.

avatar pecos | 

Plus le temps passe, plus je considère Swift non seulement non abouti, mais inutile.

Et me pose toujours cette question :
*Pourquoi*, mais pour quelle raison totalement irrationnelle avoir créé un nouveau langage alors qu'Obj-C (et C) est parfait pour développer des apps iOS et mac OS ? (c'est d'ailleurs avec lui qu'Apple travaille en très brande majorité)
Apple s'imagine sans doute que ça va faire venir des développeurs ?
Je ne crois pas que ça soit avec un langage comme Swift tout aussi rébarbatif que peut l'être Obj-C pour un débutant.
Et en attendant Java caracole en tête, très très loin devant... et c'est mérité.

Il aurait fallu au moins ne pas trop s'éloigner de la bonne vieille syntaxe façon "C" qu'on retrouve facilement dans Java, Javascript, ou même PHP.
Je ne parle pas de la compulsion sado-masochiste qui consiste à apprécier un compilateur tellement écrit avec les pieds qu'il mets entre 10X et 100X plus de temps à compiler que le code équivalent en Obj-C avec LLVM.
(mais comme Apple se fiche parfaitement des performances ces dernières années, plus rien ne m'étonne)

Pour le reste, non, je ne compte pas du tout réécrire toutes mes apps en Swift, pour la raison suivante : Ce n'est pas un superset de C.

Ce n'est pas seulement une question de langage : il y a tellement de facilités et d'intérêt à passer le plus souvent possible à du C "regular" dans le code objective-C (pour optimiser la vitesse, surtout) que je ne vois pas comment m'en passer. Sans compter surtout toutes les librairies existantes.

Dernière question, au staff de macg : mais qu'est ce qui vous a pris de réécrire votre app en Swift alors qu'obj-C marchait très bien ?
C'est pour le plaisir d'aller faire un tour à chaque fois que vous lancez une compilation ?
Ou pour les centaines d'heures passées à apprendre un nouveau langage qui change à chaque version et qui est totalement chronophage ?

Comme geek, je pourrais le comprendre. Comme chef d'entreprise, ça me dépasse. Totalement.

avatar dxosi | 

Vous avez tout faux. Avez-vous déjà utilisé Swift ?

Swift est de plus en plus abouti. Les premières versions ne l'étaient pas, mais quel language été abouti dès la première version ? Aucun. De plus, dire qu'un language est abouti n'a pas vraiment de sens. Un language n'est jamais parfaitement abouti mais évolue au fil du temps. Un language de programmation qui n'évolue pas est comme une langue morte.

Le choix de partir de zéro avec un nouveau language n'avait strictement rien d'irrationnel. Ce n'est pas parce que vous ne parvenez pas à comprendre la raison qu'il n'y en a pas.
Le but était de créer un language moderne, compréhensible, performant, sûr (typage statique), évolutif, utilisable à différents niveaux et surtout sans les contraintes du C.

Swift est loin d'être rébarbatif pour les débutants comme Objective-C (même ma fille de 7 ans arrive à utiliser Swift (merci Swift Playgrounds)), et il peut aussi bien être utilisé comme language fonctionnel, OOP, POP, etc.

Votre admiration pour le language Java en dit long sur vos connaissances...

Le but de Swift est justement de s'éloigner des contraintes du C. De plus, le code Swift est beaucoup plus lisible que le C (notamment grâce aux paramètres nommés hérités en partie d'Objective-C).

Le compilateur est de plus en plus rapide, mais surtout ce n'est pas comparable avec la compilation d'Obj-C. Obj-C est un language dynamique tandis que Swift est statique. Le compilateur a beaucoup plus de travail à faire, qui permet justement un code beaucoup plus performant (ce qui contredit totalement ce que vous dites). D'ailleurs, Swift se permet même le luxe d'être plus rapide que le language C dans certains cas.

Surtout, n'essayez pas de réécrire vos apps en Swift, cela est réservé aux vrais développeurs, ceux qui ne sont pas bornés à quelques languages et paradigmes.

Enfin, vous pouvez toujours utiliser du C ou Objective-C depuis Swift. Mais l'intérêt est de plus en plus limité. De plus, il est même possible d'utiliser des pointeurs dans Swift si ça vous dit.

S'il vous faut des centaines d'heures pour apprendre un nouveau language, il faudrait remettre en doute vos compétences et songer à changer de métier si vous être développeur. Quant aux dernières versions de Swift, il n'y a quasiment plus de changement entre versions.

Je comprends que ça vous dépasse totalement. S'il n'y avait que ça...

avatar oomu | 

"n'essayez pas de réécrire vos apps en Swift, cela est réservé aux vrais développeurs, ceux qui ne sont pas bornés à quelques languages et paradigmes. »

quelque soit son camps du jour, un geek ne peut jamais répondre à une critique ou une interrogation autrement qu’en y ajoutant du sarcasme.

Arrêtez avec les sarcasmes, donnez simplement des explications, des arguments et soyez en fiers de leur qualité !

"Enfin, vous pouvez toujours utiliser du C ou Objective-C depuis Swift. »
Objective-C n’étant qu’un sur-ensemble de C, il n’y a pas de complications comme avec Swift.

-
"S'il vous faut des centaines d'heures pour apprendre un nouveau language, il faudrait remettre en doute vos compétences et songer à changer de métier si vous être développeur. «

la productivité. Il ne s’agit pas de la capacité d’apprendre un langage. Cela n’a rien d’extraordinaire. Mais en entreprise d’être productif et de ne pas perdre de temps dans des lubies ou mirages.

La question est très légitime et la réponse serait appréciée avec sincérité : quel intérêt y a t’il eu à passer l’app MacG à Swift ? Y a t’il eu un gain pour son développeur et MacG l’entreprise ?
Des défauts, des avantages, du potentiel ? En temps, en résultat ? etc.

Moins de sarcasme, plus de COEUR !

avatar IGerard | 

@oomu

J’ai commencé l’objC en 89, j’ai adoré ce language

Mais aujourd’hui je n’ai plus du tout envie de coder en ObjC

Tout mon codage iOS Metal est en Swift :)

avatar pecos | 

@dxosi
Je vais te dire cher collègue : je ne te connais pas et tu ne me connais pas.
Donc le mieux si tu ne veux pas avoir l'air ridicule est d'éviter les attaques ad-hominem.

Comme dit oomu, argumente, explique, et surtout répond aux question que j'ai posé et que je repose :
- pourquoi perdre des milliers d'heures à utiliser un langage totalement immature alors qu'Obj-c contient exactement les mêmes API ? Pour au final faire la même chose avec des temps de compilation 20 fois plus grands ?
- pourquoi suivre Apple dans cette voie (à part par "fanboyisme") alors que la sagesse dicte d'utiliser un langage éprouvé, rapide, facile et qui fait la même chose au final ?

Pour finir, ce que tu dis à propos de Java est en 2018 totalement à côté de la plaque, vu les milliards de périphériques qui tournent superbement bien avec (Android) et qui font la même chose qu'un iPhone.
Je ne vais donc pas dire que tu ne sais pas de quoi tu parle, car ce serait être aussi ridicule que toi.
Juste que tu es partisan et que ça t'aveugle.
De mon côté, je sais très bien avec quoi je gagne ma croute et c'est avec Objective-C et Java, pas avec Swift, heureusement.

avatar dxosi | 

En même temps, tu donnes le bâton pour te faire battre.

J'ai déjà répondu en grande partie à tes "questions". Mais pour vraiment comprendre l'intérêt de Swift, il faut l'avoir déjà utilisé.

"- pourquoi perdre des milliers d'heures à utiliser un langage totalement immature alors qu'Obj-c contient exactement les mêmes API ? Pour au final faire la même chose avec des temps de compilation 20 fois plus grands ?"
Déjà, Swift 4.x est très loin d'être immature. Tu pars sur des préjugés. Swift comprends certes l'accès aux mêmes API qu'Objective-C, mais en revanche offre de nouveaux paradigmes de programmation, qui permettent d'avoir un code plus structuré, évolutif, et surtout moins "error-prone". Quant aux temps de compilation, j'ai du mal à comprendre cette obsession. Tu compiles en mode release toutes les 2 secondes ? Quand on sait coder correctement, pas besoin de compiler en permanence.

"- pourquoi suivre Apple dans cette voie (à part par "fanboyisme") alors que la sagesse dicte d'utiliser un langage éprouvé, rapide, facile et qui fait la même chose au final ?"
Swift n'est peut-être pas encore éprouvé, mais il est rapide et relativement facile. Surtout, développer en Swift permet d'avoir un projet qui sera beaucoup plus facile à faire évoluer par la suite. Enfin, le code généré est plus performant qu'Objective-C.

Pour d'anciens projets, le gain de passer à Swift n'est pas forcément évident. En revanche, pour des nouveaux projets, il peut être intéressant de passer directement en Swift.
Pour l'instant Apple n'a pas beaucoup utilisé Swift pour son propre usage, mais ça devrait venir avec Swift 5 et la stabilisation des ABI.
Pour faire simple, le coût de passer à Swift est élevé au début, mais sur le long terme, ça peut-être extrêmement bénéfique (à condition bien sûr de ne pas simplement écrire son code Swift à la manière d'Obj-C).

"Pour finir, ce que tu dis à propos de Java est en 2018 totalement à côté de la plaque, vu les milliards de périphériques qui tournent superbement bien avec (Android) et qui font la même chose qu'un iPhone."
Vu les fiches techniques, encore heureux. Pour le même algorithme, Swift 4.x peut utiliser 4 fois moins de RAM que Java, tout en étant beaucoup plus rapide. Mais ce n'est pas parce que Java est utilisé sur des milliards de périphériques (à cause au tout début d'un choix technique contestable, le projet Android ayant totalement changé de direction suite à l'iPhone) que cela en fait un meilleur language que Swift.

"Juste que tu es partisan et que ça t'aveugle."
Non, justement, je ne suis pas partisan. J'étais même récalcitrant à utiliser Swift au début. Mais lorsque je me suis aperçu de ses qualités, j'ai mis de côté mes a priori.
Je ne parle que de ce que je connais, pas comme certains qui se limitent à parler d'un language qu'ils n'ont jamais utilisé.

"De mon côté, je sais très bien avec quoi je gagne ma croute et c'est avec Objective-C et Java, pas avec Swift, heureusement."
Tu ne sais pas ce que tu perds à rester dans ton entêtement idéologique. Tant pis pour toi.

avatar pecos | 

Tu es sûr que c'est pas plutôt le gars qui me traite de débutant (sans rien connaître de mon parcours) parce que j'ose critiquer qui donne le bâton pour se faire battre ?
Hm ?
Tu es sûr aussi que les "préjugés" que j'ai à propos de swift, tu n'a pas exactement les mêmes à propos de Java que tu semble très peu apprécier ?
Hm ?

On peut avoir tous les deux des avis plutôt négatifs, l'un sur Java, l'autre sur Swift.
Java a quand même largement prouvé sa capacité et est largement plus mature que Swift. Et aussi monstrueusement plus employé, excuse du peu.
Je crois que j'ai donc bien plus d'excuses à avoir sorti le bazooka à propos de Swift que tu ne l'as à propose de Java.

« Quant aux temps de compilation, j'ai du mal à comprendre cette obsession. Tu compiles en mode release toutes les 2 secondes ? Quand on sait coder correctement, pas besoin de compiler en permanence. »

Ridicule, tu es encore en train d'insinuer que Toi Tu sais coder et que les misérables vermisseaux que nous sommes ne savons pas. Quand va Tu cesser ces attaques ad-hominem qui ne trompent personne ?

Sur le fond quand tu code toute l'interface intégralement et que tu n'utilise pas le plus petit bout de XIB ou de "storyboard" (vu la perte de temps que ça représente à tout revoir à chaque nouvelle version de l'OS) tu es bien obligé de compiler, non pas toutes les deux secondes, mais bien 1 ou deux fois par minute.
Vu le temps de compilation d'un app écrite en swift, c'est tout simplement INUTILISABLE en l'état.
Une app comme celle de macg ou comme celles que je fais, en Obj-c, ça se compile en 3-10 secondes maximum. (sinon, ya comme un souci, parce que c'est pas Adobe Photoshop CS, non plus qu'on compile...)
Là, on peut bosser.

« Pour faire simple, le coût de passer à Swift est élevé au début, mais sur le long terme, ça peut-être extrêmement bénéfique (à condition bien sûr de ne pas simplement écrire son code Swift à la manière d'Obj-C). »

J'ai déjà assez à faire comme ça à passer mon temps à porter des classes, des méthodes et des algorithmes de Obj-C à Java et vice-versa, afin d'assurer des versions de toutes mes apps à la fois sur iOS et sur Java, pour en plus m'intéresser à Swift qui a une syntaxe qui s'éloigne vraiment trop du C, tant grammaticalement que d'un point de vue logique.
Quand à reprendre mes apps en Swift ça ne risque pas : le code objective-c est tellement panaché avec du C à fin d'optimiser la vitesse que ce serait de toute façon un cauchemar.
Si on avait eu la possibilité de panacher avec du code en C dans les mêmes fichiers, peut-être que je me serais intéressé.

Pour finir, je vais te dire : quand j'ai lu qu'Apple développait un nouveau langage qui se voulait "moderne" et accessible, je me suis dit : pourquoi pas.
Après tout, Obj-C traine des scories assez pénibles qui rendent le code particulièrement bavard (quoique lisible).

Ben quand j'ai vu le résultat (Swift) j'ai été épouvanté.
Mais pourquoi tout reprendre de zéro, la syntaxe, les concepts, même jusqu'aux bonnes façon d'utiliser les variables ?
Par moment je pense que c'est juste pour le plaisir (bien compréhensible) d'inventer un truc entièrement nouveau (quoique). De la coquetterie de geek.

Et moi je bosse.

avatar dxosi | 

Si encore tu critiquais en donnant des arguments valables. Sauf que là, tu critiques un language que tu n'as visiblement jamais utilisé et dont tu ne comprends pas la logique.

Pour ce qui est de Java, je constate simplement que tu critiques Swift pour des choses sur lesquels Java n'est pas le mieux placé (performances notamment).

"Java a quand même largement prouvé sa capacité et est largement plus mature que Swift." On pourrait dire la même chose pour la plupart des languages qui existent depuis un certain temps. Ce n'est pas une raison pour passer à côté de Swift.

"tu es bien obligé de compiler, non pas toutes les deux secondes, mais bien 1 ou deux fois par minute." Non, pas avec un minimum de rigueur et de planification.

"Ben quand j'ai vu le résultat (Swift) j'ai été épouvanté.
Mais pourquoi tout reprendre de zéro, la syntaxe, les concepts, même jusqu'aux bonnes façon d'utiliser les variables ?"

Là encore, non, ce n'est pas pour le plaisir, il faut utiliser Swift pour le comprendre...

Je serais curieux de voir quelles apps tu développes.

avatar fte | 

@dxosi

"Pour ce qui est de Java, je constate simplement que tu critiques Swift pour des choses sur lesquels Java n'est pas le mieux placé (performances notamment)."

Java peut être extrêmement performant lorsqu’il est bien utilisé. Il n’est pas le mieux placé, mais il est certainement mieux placé que Swift.

"On pourrait dire la même chose pour la plupart des languages qui existent depuis un certain temps. Ce n'est pas une raison pour passer à côté de Swift."

Ça dépend de quels aspects de la maturité d’un langage ont priorité. La stabilité du langage est pour certains cruciale. C’est super hyper méga chiant de reprendre ses apps à chaque évolution de Swift et de passer des heures voire des jours à trifouiller pour recompiler ses apps. Les apps iOS sont généralement petites et jetables, donc ce n’est pas dramatique. Mais pour des projets plus importants et maintenus quelques années au moins, ça peut être une excellente raison d’éviter Swift comme le Mal.

"Non, pas avec un minimum de rigueur et de planification."

Hum. Je me trompe peut-être, mais ce commentaire sens le waterfall à plein nez.

La seule raison d’être du waterfall est que la population de développeurs double tout les 3 ou 4 ans depuis les années 80, donc la moitié des développeurs en activité ont moins de 5 ans d’expérience, sont jeunes, bref, des gamins impétueux sans discipline.

C’est pour cette raison que des développeurs ont programmé les tricheries pollution de Volkswagen. Des gamins impétueux sans discipline.

C’est pour ça que des Toyota je crois ont eu ce bug hallucinant de pédale de frein qui accélérait.

Tu imagines qu’il y a des centaines de milliers de lignes de code dans le firmware des voitures ? Pondues par des gamins sans expérience ?

Les cycles courts, la discipline, l’expérience, sont de très loin supérieurs à la planification. Le temps de compilation a un impact direct sur la qualité d’un code.

"Là encore, non, ce n'est pas pour le plaisir, il faut utiliser Swift pour le comprendre..."

Tu crois que Swift est révolutionnaire ? C’est un langage comme n’importe quel autre. Si tu as compris les grands concepts de l’orientation objet, et la moitié des développeurs n’ont pas compris, tu sais, les gamins impétueux et sans expérience, Swift n’a plus rien de miraculeux.

Ce ne sont pas les quelques bricoles fonctionnelles qui le distinguent particulièrement. LISP fait mieux depuis 60 ans.

avatar dxosi | 

"Java peut être extrêmement performant lorsqu’il est bien utilisé. Il n’est pas le mieux placé, mais il est certainement mieux placé que Swift."
C'était vrai pour les premières versions de Swift. Depuis, Swift est bien plus performant que Java sur tous les aspects (RAM, CPU).

"C’est super hyper méga chiant de reprendre ses apps à chaque évolution de Swift"
Là encore, c'est de moins en moins vrai.

"Je me trompe peut-être, mais ce commentaire sens le waterfall à plein nez."
Non. J'entendais simplement que (trop) souvent, le code est écrit à la volée avec une conception inexistante ou incomplète.

"Tu crois que Swift est révolutionnaire ? C’est un langage comme n’importe quel autre. Si tu as compris les grands concepts de l’orientation objet, et la moitié des développeurs n’ont pas compris, tu sais, les gamins impétueux et sans expérience, Swift n’a plus rien de miraculeux."

Le but de Swift n'est pas d'être révolutionnaire. En revanche, il offre de très nombreux avantages : syntaxe "moderne" et lisible, performances élevées malgré des concepts de haut niveau tout en conservant la possibilité de faire du bas niveau, polyvalence, sûreté du typage, programmation orientée protocoles, etc.

avatar fte | 

@dxosi

"Le but de Swift n'est pas d'être révolutionnaire. En revanche, il offre de très nombreux avantages : syntaxe "moderne" et lisible, performances élevées malgré des concepts de haut niveau tout en conservant la possibilité de faire du bas niveau, polyvalence, sûreté du typage, programmation orientée protocoles, etc."

Tu réalises que tout ce que tu cites ici s’applique aussi à ObjC ou C++ - j’ai pour ma part toujours codé en ObjC++ sur macOS ou iOS -, et que ObjC++ a certainement l’avantage sur Swift sur la plupart des points ?

Je pense que tu ne réalises pas.

avatar pecos | 

@dxosi
« Je serais curieux de voir quelles apps tu développes. »

Puisque c'est demandé si gentiment (je ne sais pas si c'est autorisé de faire de la pub ici...)

https://itunes.apple.com/fr/app/fleurs-en-poche/id352355925?mt=8

avatar dxosi | 

Tu as aussi peur d'adopter Swift que d'adopter l'IHM d'iOS 7+ ? Je comprends mieux.

Mais finalement, c'est peut être toi qui a raison. Pourquoi se fatiguer à faire de la qualité quand des utilisateurs se contentent de bien peu.

avatar Derw | 

Je suis un utilisateur des applications de @pecos et aussi un ex UI et UX designer. De mon point de vue les qualités d’une application sont dans l’ordre décroissant :
1. l’utilité
2. l’utilisabilité (ce qui englobe l’UX design et aussi les performances…)
3. l’esthétisme (l’UI)

Ces applications sont certes dépassées au niveau de l’UI. Sans doute le sont-elles au niveau de l’UX (et encore, toute argumentation UX doit s’appuyer sur des études sur un panel d’utilisateurs); mais elles sont performantes et surtout utiles. D’où leur succès…

Du coup, ton argument "Pourquoi se fatiguer à faire de la qualité quand des utilisateurs se contentent de bien peu." tombe complètement à plat pour moi. Ces applications sont très perfectibles sur l’UI (et peut-être le code, chose que je serais incapable de juger) mais elle rendent très bien le service qu’on leur demande, contrairement certaines applications au design tendance mais à l’utilité foireuse.

avatar dxosi | 

@Derw Je suis tout à fait d'accord.

J'ai un peu exagéré sur la dernière phrase, je l'avoue. Cependant, il se permet de critiquer un langage de programmation qu'il n'a jamais vraiment utilisé, et pour lequel il ne fait pas l'effort de s'intéresser, de la même manière qu'il ne fait pas d'effort pour mettre à jour correctement son application et pour respecter les recommandations les plus élémentaires (du genre, ne jamais utiliser de scène "Accueil" dans un TabBar).

Avec un peu d'effort, il pourrait facilement proposer des apps quasi-parfaites, l'utilité est là, le contenu est là (et je pourrais même être client ?).

avatar Billytyper2 | 

@pecos

C’est tout dans la poche…?
Plutôt de bons commentaires …?

avatar IGerard | 

@dxosi

Tout à fait d’accord...

Je fais du Scala, heureusement que Apple se met au goût du jour

Ensuite personne n’oblige qui que ce soit à abandonner ObjC

avatar reborn | 

@pecos

C’est la vision de Jobs ?‍♂️

avatar Rez2a | 

@pecos

Je ne comprends pas l’intérêt de vouloir rester autant attaché à C.
Si vous devez faire appel à du C au milieu de votre code Obj-C régulièrement uniquement pour des questions de performances, c’est que vous avez déjà des problématiques qui sont très éloignées de la grande majorité des développeurs iOS.
Mais même dans ce cas, il ne me semble pas que Swift se traîne particulièrement, lorsque Apple compare les performances de Swift sur des parcours de tableaux et autres, c’est pas avec Python qu’elle le compare (ou alors, juste pour le fun), mais à C++ et c’est pas franchement honteux.

Pour le reste, je pense que c’est avant tout des questions d’habitudes et de préférences donc je ne serai pas aussi catégorique que vous, mais pour ma part, ayant développé en Obj-C pendant 8 ans avant de migrer sur Swift il y a 2 ans, je préfère ce dernier de très (très) loin.

Entre autres, une syntaxe plus moderne (le « guard » et les switch sur des ranges et des Strings justifieraient à eux seuls le passage à Swift d’après moi ?), le compilateur qui fait un taf de fou et qui empêche un paquet d’oublis, les fonctions anonymes qui ne sont plus totalement imbitables comme en Obj-C, les optionnels qui incitent grandement à réfléchir à son code en amont, l’absence de headers qui n’est vraiment pas un mal, les enum qui peuvent être ultra puissants, les willSet / didSet sur les variables qui peuvent être ultra pratiques également...

Après je suis d’accord sur un point : Apple en fait beaucoup sur le côté « noob-friendly » de Swift, mais pour moi c’est un piège, le langage n’est clairement pas facile du tout à appréhender. C’est pas du tout évident de sortir du code « Swifty », encore moins lorsqu’on vient d’Obj-C et qu’on a tendance à vouloir réécrire son code « comme avant ».

avatar pecos | 

« Je ne comprends pas l’intérêt de vouloir rester autant attaché à C.»

Tu crois peut-être que chez Apple, les apps sont codées en Swift ?

-> Par exemple, quand tu ne fais que des apps qui manipulent des très grosses base de données avec des matrices de plusieurs dizaines de milliers d'éléments, y a pas photo, c'est terriblement plus rapide avec des tableaux C qu'avec des NSArrays.
Et j'aime la rapidité. Chacun son truc.

Maintenant pose toi la question :
Pourquoi veux-tu faire autrement ce qui marchait très bien jusque là ?
À part pour mieux contrôler l'ensemble, je ne vois pas.
Ça devient la spécialité d'Apple.

Pour finir, je dirais que Swift peut très bien un jour devenir le seul et unique langage utilisable pour faire une app iOS ou macOS.

Ça ne se fera jamais tout seul.
Mais, ça peut quand même arriver :

Il suffit pour cela qu'Apple décrète que Objective-C est "OBSOLETE" ou... "DEPRECATED".
Et cesse de supporter les mêmes API dans les deux langages.
Puis empêche qu'on soumette des builds non codées en Swift.

Un jour ou l'autre ça arrivera : dans ce genre de décision unilatérale, Apple est championne et nous a bien habitués.
Heureusement au final que ça n'est qu'un entreprise d'électronique grand public.
Imaginez que ça soit un état et que vous en soyez citoyen. LE cauchemar.

avatar dxosi | 

"Tu crois peut-être que chez Apple, les apps sont codées en Swift ?"

Tant que la stabilisation des ABIs n'est pas prête, les apps d'Apple restent majoritairement codées en Obj-C.

"Par exemple, quand tu ne fais que des apps qui manipulent des très grosses base de données avec des matrices de plusieurs dizaines de milliers d'éléments, y a pas photo, c'est terriblement plus rapide avec des tableaux C qu'avec des NSArrays.
Et j'aime la rapidité. Chacun son truc."

Si tu aimes la rapidité, tu devrais essayer Swift (qui d'ailleurs signifie "rapide" en anglais). Les toutes premières versions n'étaient pas à la hauteur, mais maintenant si. Le gain de performance entre chaque version est assez impressionnant.
Il est tout à fait possible d'écrire du code "haute performance" avec Swift, à condition de bien connaître le language. En fait, il est possible depuis Swift de générer exactement le même code que du C.

Quant à la fin de ton discours, ça confirme ce que je pensais. Tu as peur du changement et de l'inconnu qu'apporte Swift. Tu veux rester dans ton monde confortable des vieux paradigmes. Tu me fais penser à certains vieux développeurs qui avaient peur des nouveaux languages de programmation.

avatar Lonesome Boy | 

@dxosi

Désolé pecos, mais c’est l’impression que me donnent également tes posts. J’en connais qui sont encore en mode « la POO c’est de la m... ». Fais attention car avec cette approche tu risques d’être largué dans quelques années et tu te feras bouffer par les petits jeunes.

avatar fte | 

@Lonesome Boy

"la POO c’est de la m..."

C’est pourtant vrai.

Comme la programmation procédurale.

Ou la programmation fonctionnelle.

Ou pire, l’objet-fonctionnel.

La programmation c’est de la M. Il faut être masochiste pour programmer.

Ce qui est faux c’est de penser qu’un certain paradigme est moins merdique que les autres. Tout est tellement primitif.

avatar Gueven | 

@fte

Comme je déteste le terme « programmation procédurale », je lui préfère « programmation impérative ». C’est tellement plus proche de la réalité (je demande a l’ordinateur de faire d’une certaine manière en s’appuyant sur la machine de Von Neumann).

avatar fte | 

@Gueven

Ce dont deux choses différentes... étrange que tu puisses confondre les deux.

Pages

CONNEXION UTILISATEUR