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.

avatar Gueven | 

@fte

Ils sont pourtant assez proche.

avatar fte | 

@Gueven

La programmation orientée objets est majoritairement impérative.

Ce n’est pourtant pas pareil.

Idem pour le procédural.

Procédural ou objet sont deux abstractions structurelles. La programmation impérative est abstraction d’implémentation, d’expression des traitements. Tout comme la programmation fonctionnelle est une abstraction structurelle et la programmation déclarative une autre abstraction d’implémentation, d’expression des traitements.

La confusion est aisée parce que programmation procédurale implique pratiquement obligatoirement une implémentation impérative. Une approche déclarative bascule vite vers du fonctionnel élémentaire et des monads explicites. Le monad de contexte impératif actionné par l’opérateur point virgule (majoritairement, ou retour à la ligne en Swift) est toujours implicite et virtuel.

avatar Gueven | 

@fte

En effet j’ai tendance à oublier qu’avant la POO on était en procédurale.
Il est vrai que souvent impératif exclue la POO dans mon esprit (et aussi de nombreuses personnes).

avatar fte | 

@Gueven

"Il est vrai que souvent impératif exclue la POO dans mon esprit (et aussi de nombreuses personnes)."

Et c’est faux. L’OOP est impérative pour l’essentiel.

Il est essentiel de comprendre sur quoi portent ces diverses abstractions.

Procédural et OOP (et fonctionnel) portent sur les liens entre code et données et sur la structure.

Procédural : programmation structurée et sous-programmes (procédures), séparation des données et des traitements, données mutables par toute procédure.

OOP : couplage des données et traitements, contrôle d’accès et interfaces aux données et traitements, données mutables selon les accès accordés.

Fonctionnel : séparation des données et traitements, mais données immutables sauf circonstances très spéciales (monad IO pour simplifier).

Fonctionnel objet : couplage des données et traitements, contrôle d’accès, données immuables pour l’essentiel, mutabilité contrôlée plus souple qu’en pur fonctionnel (monad IO et state) mais néanmoins très contrôlée.

C’est bien entendu une grossière simplification, mais l’essentiel y est.

Il n’est pas question d’implémentation des traitements ici. Uniquement de structure et relations.

Impératif vs descriptif est plus délicat à résumer.

Impératif est simple. Notre esprit est impératif, les processeurs sont impératifs. L’attention porte sur les étapes de traitements nécessaires pour réaliser un calcul.

Descriptif est beaucoup plus délicat à vulgariser. Disons que l’attention n’est pas portée sur les étapes de traitements, mais sur la composition de transformations amenant au résultat. On exécute pas une série d’instructions, on décrit comment les données se transforment.

Nulle structure ici.

avatar byte_order | 

@dxosi
> Quant à la fin de ton discours, ça confirme ce que je pensais.
> Tu as peur du changement et de l'inconnu qu'apporte Swift.

J'ai plutôt lu une peur d'un langage imposé de force par Apple, plutôt qu'une peur du langage lui-même.

Par ailleurs, je ne le répéterais jamais assez, merci de ne pas confondre peur du changement et peur du progrès. Le changement n'est pas automatiquement un synonyme de progrès jusqu'à preuve du contraire !

Exemple : votre employeur vous change votre salaire... à la baisse. C'est un changement.
Pourquoi en avoir peur alors !?
Voilà.

Merci donc de considérer que chacun est libre de voir par lui même dans un changement les avantages et les inconvénients et que ce n'est pas parce que vous n'avez pas la même vision sur ces points que c'est la preuve définitive qu'autrui refuse le progrès ni que ce changement sera véritablement un progrès.

Après tout, Objective C à l'époque à été justifié avec le même type d'argumentaires à l'époque : c'était censé être mieux que les autres langages etc. Sans Apple, pourtant, ce langage serait mort depuis très longtemps, et son audience tient nettement plus au fait que c'est l'ABI native de macOS et surtout de iOS que des ses qualités propres.

Sinon, son audience aurait tout simplement débordé sur les autres plateformes.
Les développeurs, collectivement, ne sont pas masos au point de se priver d'un moyen d'être plus productif pour des raisons irrationnels.

Les promesses c'est bien gentil mais à un moment le pragmatisme est propre à chacun, il ne s'impose pas *parce que c'est comme ça, point, sinon vous etes des nazes !*

avatar fte | 

@pecos

Les langages sont des modes. Et des fausses solutions à des problèmes sans solution.

Stroustroup disait qu’il y a deux catégories de langages : ceux que l’on critique et déteste, et ceux qu’on utilise pas.

Il y a cependant une petite différence dans l’écosystème Apple. On n’a pas tant que ça le choix du langage.

Pourquoi une réécriture en Swift ? Parce que c’est encore un peu à la mode, et bientôt parce qu’Apple ne laissera plus le choix. Après tout, les développeurs ont aussi le droit de jouer avec les derniers jouets à la mode, avant de réaliser que c’est la même merde qu’avant.

avatar pecos | 

Oui, c'est bien vrai.
Maintenant faut pas non plus trop me titiller.
Je n'ai pas fait de la programmation toute ma vie et si je fais autre chose je ne m'en porterais pas plus mal.
Ce que je veux dire c'est que l'attitude d'Apple qui consiste à forcer les gens (clients ou fournisseurs) est détestable.
Tant que Obj-C est supporté, je reste avec eux.
Après, je vends suffisamment sur Android pour pouvoir me passer d'Apple.

L'attitude de Google est autrement plus saine : imagine que je développe mes apps pour Android avec une vieille version d'Eclipse (de 2015) et que je build en SDK 4.1, API 14. (on en est à l'API 26 actuellement).
Ils sont vraiment pas chiants chez Google. Et comme java et les apis sont très stables, c'est tranquille.

En comparaison c'est comme si je pouvais créer une nouvelle app avec XCode 6 (iOS8) et l'envoyer à l'appstore.
Rigoureusement interdit par apple, évidemment : XCode 9 minimum pour les nouvelles apps. C'est délirant parce qu'au final je ne me sers de XCode 9 que pour la compilation finale de l'archive avant envoi à Apple, et pour de très rares tests.

(si certains se demandent pourquoi utiliser XCode6 à la place de XCode 9 c'est encore une question de rapidité : bien plus rapide à compiler le bougre. Et je ne parle pas de la charge CPU en ces temps de canicule...)

avatar fte | 

@pecos

"Maintenant faut pas non plus trop me titiller."

Uh ? Mais je ne te titillais pas. Pas volontairement en tout cas.

"Ce que je veux dire c'est que l'attitude d'Apple qui consiste à forcer les gens (clients ou fournisseurs) est détestable."

J’ai pratiquement complètement arrêté le développement iOS de part l’attitude d’Apple. J’ai mieux à faire que de subir les lubies tyranniques de cette boite. Android est une plateforme tellement plus agréable pour bosser.

avatar pecos | 

On est parfaitement d'accord alors, et c'est apple qui me "titille", pas toi... ;-)

avatar Derw | 

Ces débats sont socialement intéressants. Ils tombent tout à fait dans le classique débat des anciens et des modernes. Le pire est que, comme à chaque fois dans ce genre de débat, vous avez tous raison.
Oui, quand on a une entreprise à faire tourner on doit privilégier la productivité. Oui il semble inutile de quitter un truc qui marche pour un truc qui ne marche peut-être pas encore. Oui, le pragmatisme et la prudence sont des qualités importantes pour faire vivre un business.
Mais en même temps, la curiosité et la nouveauté sont aussi des qualités importantes pour créer des projets. Être développeur et ne pas accorder au moins 10% de son temps à de la veille techno ce n’est pas cohérent. Enfin, je suis peut-être naïf, mais j’aime à croire que le projet de développer Swift n’est pas né de la lubie d’un geek pourri-gâté mais de répondre à un besoin auxquels ne répondait pas le C ou l’objective C. Mais ce besoin, il est probable que tous les développeurs ne le ressentent pas…

En ce qui me concerne, je ne sui pas développeur, mais Swift est le premier langage qui me donnerait envie de le devenir…

avatar Gueven | 

@pecos

Swift fait parti de la nouvelle vague des langages qui sont aussi efficient que le C mais avec un niveau d'abstraction très élevé.

Il tend comme "rust" vers l'abstraction à 0 cost. On est bien loin d'un language comme Java.

Comme rust, il se veut "safe".

Bref, Swift comme Rust valent le coup d'oeil. Dans les langages impératifs, pour moi ceux sont les plus séduisants.

Il est tend de passer à autre chose car le monde des langages bouge car LLVM fait réellement bouger les choses, et c'est bien.

Un développeur qui n'évolue pas risque de très vite être dépassé.
Et puis, c'est en essayant qu'on apprend beaucoup.

avatar fte | 

@Gueven

"Un développeur qui n'évolue pas risque de très vite être dépassé."

Moyennant que les langages représentent moins du quart du travail d’un développeur, qu’entends-tu par "qui n’évolue pas", dans le contexte des trois autres quart du travail d’un développeur ?

avatar IGerard | 

@fte

L’outil/language que tu utilises modifie beaucoup la manière de bosser.

1/4 du taff ? Ça me semble étrange comme ratio... je dirais 3/4

avatar fte | 

@IGerard

Tu travailles seul sur un compilateur ?

Sinon, il y a l’équipe, le social, l’algorithmique, le design, le debugging, l’issue tracking et le reporting, les meetings client, l’éthique, l’outillage, le refactoring, les code reviews, le suivi de la dette technique, la veille technologique, les relations avec le fucking AppStore... en fait les langages représentent moins de 10% du job.

avatar Gueven | 

@fte

Si le développement ne présent que 10% du boulot d’un développeur, la productivité est ... famélique.

Même moi qui est software / system architect je passe plus de 10% de mon temps en développement.

Donc pour un développeur....

avatar fte | 

@Gueven

"Si le développement ne présent que 10% du boulot d’un développeur"

Je n’ai pas parlé de 10% de développement. J’ai parlé de 10% de langage. Le développement n’a que très peu avoir avec les langages.

avatar Gueven | 

@fte

Il va falloir que tu m’explique comment développer sans connaissance d’un ou plusieurs langages.

Et par expérience je sais trop bien que la majorité des développeurs ne connaissent même pas 70% du langage sur lequel ils s’appuient pour développer.
De plus connaître plusieurs langages et leurs paradigmes permet de développer avec une meilleure efficacité.
Savoir changer de langage pour une problématique spécifique peut être un énorme gain de temps.

avatar IGerard | 

@fte

Développeur Scala depuis plus d’un an, bien qu’ayant pratiqué le Lisp dès 85 et Mathematica dès 89/90... ObjC/NeXTStep des 89 également, tout en codant en ADA professionnellement.

les spécificités du language, l’approche très spécifique font que la partie langage prend pas mal de place...

Cela étant dit, je n’avais pas saisis que tu considérais le langage comme activité spécifique hors codage, review, refactoring, codage même, sans parler de la phase design où le langage utilisé impose sa marque...

Effet de mode, oui en partie, mais également évolution des outils, des complexités logicielles atteintes qui imposent de nouvelles pratiques.

Il est marquant de voir qu’il y a eu de manière majoritaire la pratique du procédural, est venu ensuite l’avènement de la programmation orienté objet et maintenant on voit les langages à forte connotation fonctionnelle prendre le relais...

PS: je fais du dev iOS / Swift dans mon temps libre

avatar fte | 

@IGerard

"Cela étant dit, je n’avais pas saisis que tu considérais le langage comme activité spécifique"

Disons les choses ainsi : à environnement égal, par exemple la JVM et ses API standard, maîtrisé, changer de langage ne représente qu’un effort minimal si on sait les grands paradigmes.

Je crois que c’est Alan Kay qui disait qu’il fallait un jour pour apprendre Smalltalk, un mois pour maitriser l’orientation objet et un an pour être à l’aise avec la librairie standard.

C’est assez vrai je pense, l’idée en tout cas. Langages « paradigmes « API.

avatar Gueven | 

@fte

Je ne sais pas d’où du tiens que le langage ne représente que 1/4 du travail.
Il est clair que la connaissance du métier est important, ainsi que les API des librairies utilisées.

N’empêche (et l’expérience me permet de le dire), un développeur est vite dépassé s’il ne se tient pas à jour vis à vis des nouveaux paradigmes des langages.

avatar fte | 

@Gueven

"s’il ne se tient pas à jour vis à vis des nouveaux paradigmes des langages."

Le dernier paradigme d’importance date de 1966 environ. Fonctionnel avec LISP en 58 et OOP avec Simula 67 en 66. A plus ou moins un an, l’année précise m’échappe.

Depuis il y a eu des API, des patterns, des tas de réinventions de la roue à chaque nouveau langage... mais aucune réelle invention.

Théorie des types, lambda calculus, functors et monads, valeurs types et places, classes, instances, fonctions pures ou non, procédures, generics, meta-programming, DSLs, programmation structurée, tout existe depuis des décennies.

Il n’y a pas de nouveautés, seulement des modes.

avatar Gueven | 

@fte

Oui et non.
C’est en réagissant de cette manière que l’on rate certaines évolutions. Aujourd’hui il est vrai que pas mal de paradigmes datent, cela ne veut pas dire qu’il ne faut pas s’intéresser aux nouveaux paradigmes.

Tu as oublié le pattern matching (concept qui date aussi), dommage tu avais listé pas mal de chose qui viennent du fonctionnel et qui réapparaissent aujourd’hui car le nombre de cœurs se multiplient.

De plus aujourd’hui un langage vient avec sa librairie standard. Elle s’enrichit, il est par conséquent nécessaire de se maintenir à niveau.

avatar fte | 

@Gueven

"cela ne veut pas dire qu’il ne faut pas s’intéresser aux nouveaux paradigmes"

Lesquels ?

Ils ne sont pas nombreux. Pas nombreux du tout. Genre aucun.

De plus ma petite liste ne se voulait aucunement exhaustive. Elle ne l’est pas.

Quant aux librairies standard, il y aurait énormément à dire, mais disons de façon lapidaire qu’elles ne sont partie du langage que pour fraction seulement, éléments de runtime essentiellement. C’est un autre débat.

avatar Gueven | 

@fte

Programmation réactive.
Programmation orienté aspect (POA).
Programmation événementielle.

avatar fte | 

@Gueven

"Programmation réactive."

Origines LISP, 1958.

"Programmation orienté aspect (POA)."

Origines premières Simula 67, 1966, et surtout Smalltalk, 1969-1972.

"Programmation événementielle."

Tiens, je ne sais pas de quand ça date. Au moins des premières machines de traitement de texte type Wang, probablement antérieur. Années 60 au plus tard.

Rien de neuf. Des modes.

Pages

CONNEXION UTILISATEUR