Chris Lattner abandonne le développement de Swift face à la fermeture d’Apple
Chris Lattner n’est plus employé par Apple depuis plus de cinq ans maintenant, mais le créateur de Swift avait gardé un pied dans le développement du langage. Il participait aux réunions hebdomadaires, sur place puis à distance avec la pandémie, il suivait les évolutions du langage et participait aussi à la rédaction de propositions. Bref, un membre toujours très actif… jusqu’à récemment, puisque Chris Lattner a officialisé récemment son départ.
Ce développeur qui a bien bougé depuis son départ d’Apple1 détaille les raisons de son retrait dans le développement de Swift. On pourrait les résumer en un mot : fermeture. Même si le langage de développement est open-source et même si n’importe qui peut créer une variante (fork), Swift est toujours resté entre les mains d’Apple et c’est elle qui décide de sa direction et des nouveautés effectivement implémentées. Puisque c’est Apple qui contrôle ce qui est intégré à Xcode et surtout à iOS et macOS, les développeurs qui veulent utiliser le langage n’ont pas d’autres choix que d’utiliser la version officielle.
Le goût du secret d’Apple cohabite mal avec un développement public et communautaire. Chris Lattner se plaint tout particulièrement des propositions faites par ses soins ou par un autre membre de la communauté qui sont refusées par Apple sans vraie discussion. Ou à l’inverse, des évolutions soumises par Apple qui sont validées même s’il y a des membres de la communauté qui les critiquent. Pour le dire autrement, même si Swift est un langage open-source, il est difficile pour ne pas dire impossible de le faire évoluer dans une direction qui ne convient pas à Apple.
Ajoutez à cela des conflits personnels et Chris Lattner préfère jeter l’éponge et laisser Apple gérer Swift sans lui. Conséquence de son départ, la « core team » va être restructurée, comme l’a annoncé Ted Kremenek, le successeur de Chris Lattner chez Apple qui dirige les développements de Swift depuis 2017. Cette restructuration permettra notamment de créer un groupe de travail centré sur les évolutions du langage, l’équipe principale pouvant alors concentrer son temps sur la direction générale du projet.
En réponse aux critiques sur la fermeture, Apple annonce son intention d’ouvrir plus largement ces groupes de travail à la communauté. Est-ce que cela changera néanmoins la direction générale du langage ? Il faudra en juger dans quelques années, mais on peut compter sur l'entreprise pour maintenir sa mainmise, au minimum sur le développement en Swift des apps destinées à son écosystème.
-
Après quelques mois chez Tesla, il est resté chez Google jusqu’en 2020, puis est passé chez SiFive jusqu’en début d’année, où il a choisi de lancer avec Tim Davis (un ancien de Google) sa propre entreprise, Modular AI. ↩︎
@ YetOneOtherGit
> je trouve que Swift s’éloigne de ses fondamentaux et devient un rien inutilement monstrueux.
Je suis en train de réaliser un projet perso pour ATV et je me suis mis enfin au Swift, passage devenu obligatoire.
Et bien je ne sais pas quels sont les « fondamentaux » dont tu parles, mais déjà rien que l'histoire des variables "optionnelles", pour moi c'est l'archétype de la fausse bonne idée.
Tu lis la doc, tu te dis, ouais, cool.
Tu vois en pratique et....
Je suis en train de programmer en Swift, mais je dois appeler des API bas niveau en C avec callbacks en C. Quelle horreur ! Chaque parramètre qui est un pointeur est "optionnel", même si la doc originale dit explicitement que le char * que tu vas récupérer contiendra telle donnée. Seule le contexte en void * peut être nul. Et bien non. Tout est déclaré en optionnel. Et bonjour la simplicté pour récupérer le contenu de ton char * dans une var de ton code en Swift. Ensuite, c'est sympa le passage d'un objeet en Swift via la paramètre "contexte" en void*. Bref.
Un langage de Schadok avec pour principe "pourquoi faire simple quand on peut faire compliqué".
Ça me rappelle quand je développais dans l'environnement Windows.
Ce que je me disais c'est que les ingés chez Microsoft sont cools : Ils assurent du travail permanent aux développeurs en changeant régulièrement les choses et en cassant la compatibilité de certaines API. Bref.
Une plaie faite pour des gens qui ne maîtrisent pas les pointeurs.
Je suis assez d'accord avec ce que tu écris, à part de mon côté que j'ai jeté l'éponge depuis longtemps.
Vu l'âge que j'ai, je compte bien continuer à développer en objective-c jusqu'à la retraite et ne surtout pas me pencher sur ce que j'ai considéré depuis le début comme une grosse verrue logicielle comme il y en a tant.
Je sais que c'est un peu excessif et que les goûts et les couleurs... tout ça...
OK.
Mais tout ce que je lis à propos de swift me fait le détester plus à chaque fois... y compris ce que tu viens de décrire.
Pour finir, je ne vois pas exactement en quoi c'est un "passage devenu obligatoire" ?
Juste parce qu'on te l'impose, j'imagine ?
Parce que pour un dev indépendant, je vois pas l'intérêt.
(en fait je crois que je déteste le type de syntaxe de swift, en gros tout ce qui s'éloigne du C. Chacun son truc.)
@pecos
Une simple question, combien de paradigme de programmation et de langages maitrises-tu ?
Changer de paradigme et de langage et difficile quand on n’a pas été habitué à le faire.
C’est une hygiène intellectuelle de s’astreindre à se confronter au moins une fois par an à un langage faisant sortir de sa zone de confort ou à un autre paradigme de programmation au sein d’un langage qu’on maîtrise.
En ce moment pour s’ouvrir l’esprit je recommande fortement Rust 😋
@marc_os
"Une plaie faite pour des gens qui ne maîtrisent pas les pointeurs."
Là tu te trompes un peu de guerre avec ton scénario d’usage assez atypique. (« Je suis en train de programmer en Swift, mais je dois appeler des API bas niveau en C avec callbacks en C »)
Bien des langages modernes ne sont pas fait pour manipuler des pointeurs et font tout pour rendre cela difficile.
La manipulation directe de pointeur est depuis longtemps identifiée comme une source courante de bug. Et même les approches modernes de C++ les évites dans bien des cas.
Un langage moderne se définit presque d’abord par ce qu’il interdit de faire et non ce qu’il permet de faire.
Là j’ai le sentiment que tu reproches à Swift de ne pas être C 😁
Les choix discutables sur les évolutions du langage ne sont pas de cet acabit.
Beaucoup de langages modernes te confronteront aux mêmes pertes de repérés par rapport à tes habitudes.
Swift est assez représentatif de l’état de l’art sur ce qui n’est pas issu du fonctionnel.
Tu travails habituellement sur quels langages ?
@ YetOneOtherGit
> Là tu te trompes un peu de guerre avec ton scénario d’usage assez atypique
Je me doute que mon scénario est atypique, d'autant plus que les API que j'utilise sont utilisées par une minorité de gens de manière générale, sans même parler de Swift. Mais voilà, c'est mon lot visiblement, et c'est ce qui arrive quand tu fais souvent du bas niveau.
Edit : Trop d'infos personnelles, je vire.
@marc_os
"Bref, des langages j'en ai vu passer, et le Swift me rappelle en fait dans sa façon de masquer les pointeurs à VisualBasic"
Dans ta liste de langages expérimentés je ne vois aucun langage « moderne » ceci explique peut-être en partie ta déstabilisation.
Il y a eu de grands changements sur ces dernières décennies quant à la conceptualisation des langages de programmation et tout ce que tu énumères est issu d’un héritage assez ancien 😉
@ YetOneOtherGit
Je n'ai cité que les langages que j'ai utilisés dans un cadre professionnel plus que quelques jours.
Quant aux langages "modernes", j'en ai entendu parler mais pour moi c'est de la branlette intellectuelle. Contrairement à Objective C / NextStep qui avait une base, un héritage solide.
Tout ça c'est juste du boulot d'informaticiens en mal de reconnaissance pour donner du travail à des informaticiens.
Jusqu'à l'arrivée de Swift, les stats d'utilisation d'Objective C montaient en flèche parce de nombreuses personnes voulaient proposer des apps pour iPhone.
Et que voit-on aujourd'nui ?
Non pas de superbes développements pour macOS ou iOS développés avec ces langages "modernes", mais des merdes en Electron.
L'app de la SNCF utilise-t-elle l'un de ces fameux langages "modernes" ?
Dans le "monde du bois" du début du 20ième siècle, ont disait qu'on reconnaissait les bons ouvriers à ses outils. Je pense que cette parole est toujours valable.
@marc_os
"Quant aux langages "modernes", j'en ai entendu parler mais pour moi c'est de la branlette intellectuelle."
Partant de là 😄
Pas grand chose à discuter et il est donc simplement préférable que tu restes dans ta zone de confort ce qui est parfaitement respectable 😃
@marc_os
"Non pas de superbes développements pour macOS ou iOS développés avec ces langages "modernes", mais des merdes en Electron."
L’adoption des technologies issues du web qui dépasse très largement le cadre d’iOS n’a rien à voir avec l’apparition des langages « modernes » ou de Swift.
Elle serait advenue quoi qu’il arrive tant elle est économiquement rationnelle
@marc_os
"Dans le "monde du bois" du début du 20ième siècle, ont disait qu'on reconnaissait les bons ouvriers à ses outils. Je pense que cette parole est toujours valable."
Yep mais pas forcément dans le sens que tu entends 😎
A titre personnel quelqu’un qui considère comme de la « branlette intellectuelle » plusieurs décennies de travail en sciences informatiques sur les langages de programmation et qui s’accroche à des visions issues des années 70, je le respect, mais je ne le recrûtes pas.
Et il y a des chances qu’en plus les évolutions de pratiques en terme de qualité logicielle et de méthodologies de développement lui soit étrangère.
@ YetOneOtherGit
> A titre personnel quelqu’un qui considère comme de la « branlette intellectuelle » plusieurs décennies de travail
Blabla.
Les mot "moderne" est le seul argument que tu as avancé.
Tu parles aussi de paradigmes mais en restant très vague sans rien préciser.
De la branlette.
Je parles POO, parallélisme, et toi tu parles de « plusieurs décennies de travail en sciences informatiques ». Oui, on n'est pas au même niveau du tout.
Je parle performances, aucune réponse. Bref.
@marc_os
Toujours la même chose avec toi : quand on monte un peu en abstraction il n’y a plus personne en face, c’est vraiment dommage 😎
Au final tu as le même rapport aux sciences informatiques qu’aux théories Marxistes semble-t-il : du bricolage intellectuelle terre à terre.
Vraiment dommage 😉
@ YetOneOtherGit
> quand on monte un peu en abstraction
Utiliser des mots creux comme "modernité", ce n'est pas monter en abstraction.
@marc_os
"Oui, on n'est pas au même niveau du tout."
Effectivement tu montres remarquablement ton niveau avec tes propos et tes visions 👏👏👏
C’est intéressant de constater que c’est en allant sur le terrain technologique que mes impressions sur ton niveau se confirment sans l’ombre d’un doute.
Il nous reste heureusement le Jazz 🖖
@ YetOneOtherGit
> C’est intéressant de constater que c’est en allant sur le terrain technologique
Quel terrain technologique ?
Utiliser les mots "modernité" et de "paradigme" c'est faire une argumentation sur le terrain technologique ? 😳
Si tu le dis...
(J'allais dire quelque chose sur certaines de mes compétences validées par l'industrie, mais je préfère m'abstenir car je sens que ça serait retourné contre moi. Donc je m'abstiens, et bref.)
@marc_os
"Ah oui, j'oubliais Flash 5.0 et son "action script" pour un CD-Rom institutionnel début 2000... 🤪"
On a dit qu’on restait poli 😉😄
@ YetOneOtherGit
> On a dit qu’on restait poli
Et oui, il ya des gens qui ont gagné de l'argent en produisant des CD-Roms réalisés avec Director ou même Flash 5.0. Et des clients qui ont été satisfaits. Tout en restant poli. (Et dieu sait que j'ai pesté contre Flash, mais c'est une autre histoire.)
@marc_os
"Et oui, il ya des gens qui ont gagné de l'argent en produisant des CD-Roms réalisés avec Director ou même Flash 5.0. Et des clients qui ont été satisfaits. Tout en restant poli. (Et dieu sait que j'ai pesté contre Flash, mais c'est une autre histoire.)"
L’ironie de mon propos t’aurais visiblement échappé, t’inquiète il y a même beaucoup de monde faisant du très profitable business avec Java Script 😜😉
@marc_os
"Je me doute que mon scénario est atypique, d'autant plus que les API que j'utilise sont utilisées par une minorité de gens de manière générale, sans même parler de Swift. Mais voilà, c'est mon lot visiblement, et c'est ce qui arrive quand tu fais souvent du bas niveau."
Sur ce type d’enjeu je te recommande chaudement de t’intéresser à Rust 😉
@ YetOneOtherGit
> je te recommande chaudement de t’intéresser à Rust
Je peux utiliser Rust dans mon application pour Apple TV qui fait appel à des API en C ? 😳
@marc_os
"Je peux utiliser Rust dans mon application pour Apple TV qui fait appel à des API en C ? 😳"
Nope je t’ai dit de t’y intéresser pas que c’était la solution à tes pb.
Après c’est sans doute pour toi de la branlette intellectuelle que la très intéressante approche de Rust 😉
@ YetOneOtherGit
> Après c’est sans doute pour toi de la branlette intellectuelle que la très intéressante approche de Rust
> Nope je t’ai dit de t’y intéresser pas que c’était la solution à tes pb
C'est bien ce que je dis.
Si ça ne sert à rien, c'est du joli blabla. Ou de la branlette intellectuelle.
Car le code que mes collègues et moi écrivons se retrouve dans les logiciels que notre boite vend, ce qui rend service à nos clients et paye nos salaires ainsi que nos actionnaires.
@marc_os
"Si ça ne sert à rien, c'est du joli blabla. Ou de la branlette intellectuelle."
C’est intéressant de te voir exhiber ton niveau et ton rapport à la chose informatique 🤭
Un praticien manquant totalement de fondements théoriques et engoncé dans des approches très datées qu’il est incapable de dépasser faute d’accepter de sortir de sa zone de confort et de monter en abstraction.
Ce qui est amusant c’est qu’exactement les mêmes types de propos réactionnaires ont été tenus à l’arrivée de la programmation structurée, du paradigme objets, de la rationalisation des méthodologies de développement, de tests, d’intégration…
archétypal 🤭
@ YetOneOtherGit
> Un praticien manquant totalement de fondements théoriques
Dixit celui qui avance totalement masqué et n'a comme argument "technique" que des mots creux comme "modernité" et "paradigme" (oui, je me répète).
@marc_os
"Car le code que mes collègues et moi écrivons se retrouve dans les logiciels que notre boite vend, ce qui rend service à nos clients et paye nos salaires ainsi que nos actionnaires."
Bien des boîtes sont effectivement encore sur un héritage des années 70 sur leur approche du développement, cela permet à des dev théoriquement obsolètes de continuer à travailler.
Même sur du C++ elles font du C avec de mauvaise architecture de classes.
Pas étonnant de râler à ce point sur les langages, les framework, les design patterns, les librairies, les outils, les approches, les architectures modernes qui donnent effectivement bien du mal à ceux qui pensent encore avec un mind-set des années 70.
@ YetOneOtherGit
> Même sur du C++ elles font du C avec de mauvaise architecture de classes
Aller, tu parles sans savoir, ignorant ce que j'ai dit précédemment sur l'importance de la maîtrise des concepts de la POO.
Mais je me doute que tu n'as pas de clients avec de vieilles machines avec disque dur et que bien sûr tu ne supporte plus macOS 10.9 - c'est la cas quand tu produits de logiciels grand public - si tant est que tu produises des logiciels commerciaux pour Mac.
C'est sûr que quand on fait joujou avec des app pour iOS uniquement pour des clients avec iPhone Pro Max 24, on écrit tout en Swift. (Moi aussi je peux avancer des préjugés.)
../..
@marc_os
"Je peux utiliser Rust"
Il a pas dit utiliser, il a dit intéresser.
@fte
"Il a pas dit utiliser, il a dit intéresser."
Pour quelqu’un qui a des enjeux « bas niveau » ce me semble être une approche qu’on ne peut ignorer actuellement au moins en veille technologique.
@marc_os
"librairie bas niveau écrite en C++"
C++ est aujourd’hui tellement multi-paradigme et a tant évolué sur les itérations de normalisation à tel point que l’on parle couramment dans la literature de « modern C++ » pour différentier, que dire « je fais du C++ » ne veut quasiment plus rien dire sans précision ;-)
Beaucoup de monde utilise encore C++ comme un C avec des classes par exemple ce qui est une sous exploitation de ce complexe langage.
D’ailleurs plus que de se focaliser sur les langages, c’est pour moi l’apprentissage des paradigmes de programmation qui reste essentiel et demande de réelles efforts intellectuelles 🤓
Mes entretiens d’embauche de dev s’articulent de plus en plus sur des enjeux de compréhension de paradigme d’ailleurs.
@YetOneOtherGit
"Mes entretiens d’embauche de dev s’articulent de plus en plus sur des enjeux de compréhension de paradigme d’ailleurs."
Les miens l’ont toujours été. Il n’y a pas grand chose de plus stupide que de demander 5 ans d’expérience de Java. Ça n’a aucun intérêt et ne dit rien sur les compétences d’un développeur. Rien d’intérêt en tout cas.
C’est bien plus intéressant de demander l’avis d’un candidat sur les diverses implementation de la boucle for en procédural, objet, fonctionnel.
@fte
"Il n’y a pas grand chose de plus stupide que de demander 5 ans d’expérience de Java"
Ils n’ont jamais été axé sur des enjeux de langage, mais la part axée sur le pb solving et la capacité à déployer un esprit d’analyse synthèse à été réduite au profits d’enjeux de paradigme et d’architecture 😉
@ YetOneOtherGit
> c’est pour moi l’apprentissage des paradigmes de programmation qui reste essentiel
Pour moi LE point essentiel à maitriser c'est la programmation orientée objet. C'est pour moi LA différence entre C++ et C plus que des constructions spécifiques comme les vecteurs.
Savoir ce qu'implique l'héritage multiple de C++ vs. l'héritage "unique" d'Objective C.
J'ai vu aussi beaucoup de gens coder avec des langages orientés objet pour au final faire en vérité du procédural. Bref.
Et quand on maîtrise bien les concepts orientés objets, ou même ce qu'on appelait aux temps du Pascal, la "programmation structurée", on peut ensuite pondre de bonnes architectures qui se prêteront bien aux tâches en parallèle. A ce sujet, je suis un grand fan de libdispatch qui a enfin permis de programmer les tâches parallèles relativement facilement. D'ailleurs, si je ne m'abuse, Switt commence à peine à gérer le parallélisme correctement "en natif" sans devoir faire appel à libdispatch.
@ marc_os : « Tiens, justement ces variables "optionnelles". Comme je le disais, la vraie fausse bonne idée. Car en vérité, c'est rare qu'on en ait besoin. »
Ben si on en a rarement besoin, alors elles ne sont pas bien gênantes. 🙂
Blague à part : l’idée de ce principe des optionnels, c’est de te forcer à t’interroger systématiquement sur la nullabilité des variables que tu manipules et, pour celles qui peuvent être à NULL, sur les conséquences que ça doit avoir quand elles le sont. Et te forcer à indiquer dans ton code, d’une façon ou d’une autre, que tu as fait cette démarche et choisi une solution.
Alors certes, ça paraît lourd au début puisqu’au lieu de prendre implicitement le raccourci de se dire « ça, ça ne vaudra jamais NULL » (ce qui est d’ailleurs trop souvent synonyme de « ça, si je ne me trompe pas ça ne devrait jamais valoir NULL ») sans rien écrire qui montre qu’on a eu cette réflexion, ici on se retrouve obligé d’indiquer qu’on a pris ce raccourci. Mais ça reste très rapide et ça atteint bien son but de nous forcer à nous pencher, même brièvement, sur la question alors qu’on ne voulait pas… ou qu’on avait oublié de le faire.
Bien sûr, quand on interragit avec du C qui ne dispose pas du même mécanisme, on se retrouve avec un Swift qui doit forcément considérer comme optionnels tous les pointeurs que le C retourne. Mais il suffit, dans tous les cas où on sait réellement que la valeur NULL est impossibles, de se débarrasser de l’optionnalité avec un simple point d’exclamation, à la frontière des échanges avec le C. Ce n’est pas vraiment la mer à boire, et c’est loin d’être le plus gros reproche à faire à Swift.
« Et les tuples... alors que @[bidule, machin], ça le fait très bien. »
Ça ne fait pas la même chose. Sémantiquement et syntaxiquement. 😛
(Petite précision au cas où : moi aussi, Objective C — mais surtout Cocoa — me régale depuis plus de 20 ans et j’en suis un grand fan ; mais ça ne m’empêche pas d’apprécier Swift pour ce qu’il est.)
@BeePotato
"Blague à part : l’idée de ce principe des optionnels"
Ce n’est ni unique à Swift, ni nouveau depuis Swift. J’utilisais des pointeurs intelligents en C++ avant 2000, permettant les pointeurs nuls sans risque de plantage, ou des valeurs intelligentes permettant aussi soit de retourner une valeur arbitraire soit rien avec le rien explicitement défini… ce qui est relativement nouveau est d’avoir une syntaxe dédiée partie du langage de base, encore qu’il ne semble que Scala avait ça avant… et Haskell. C’était peut-être la librairie standard. Je ne sais plus.
Enfin bref. Le langage a ses qualités. Pas que. Normal. Il avait totalement remplacé Objectivé-C pour moi très rapidement, plus pour le pattern matching et la distinction entre types valeur et types référence…
Je ne réutiliserai pas Swift de sitôt cependant, programmer spécifiquement pour l’écosystème Apple est de l’histoire ancienne en ce qui me concerne.
@fte
"Ce n’est ni unique à Swift, ni nouveau depuis Swift. J’utilisais des pointeurs intelligents en C++ avant 2000"
Je suis toujours surpris par l’attachement viscéral de certains à croire que l’on n’est un “vrai” dev si on manipule directement des pointeurs alors même que c’est depuis longtemps identifié comme une des grandes sources de bug.
Il y a des horreurs issues de l’usage prétendument “optimal” des pointeurs qui sont remarquables de conséquences et sont aussi des entraves à la portabilités duc code. (J’ai quelques beaux exemples de code C « optimisé » dépendant au final de l’endianness de la machine 😄)
Bien des évolutions sur les langages modernes visent à imposer des contraintes qui sont des gardes fous plus que nécessaire.
Et sur C++ la masse de ceux qui continuent à l’utiliser comme un C avec des classes ne cesse aussi de me surprendre.
Par moment j’ai l’impression de voir les refus face à la programmation structurée des années 70 avec les mêmes accusations de « branlette intellectuelle » inutile 😁
@ fte : « Ce n’est ni unique à Swift, ni nouveau depuis Swift. »
En effet. J’espère ne pas avoir donné l’impression de penser ça (en tout cas, ce qui est certain, c’est que je n’ai rien affirmé de tel).
« J’utilisais des pointeurs intelligents en C++ avant 2000, permettant les pointeurs nuls sans risque de plantage »
Ce qui, comme tu le rappelles toi-même juste après, n’est pas tout à fait la même chose.
« Je ne réutiliserai pas Swift de sitôt cependant, programmer spécifiquement pour l’écosystème Apple est de l’histoire ancienne en ce qui me concerne. »
Pour ma part, je n’utilise pas Swift que dans l’écosystème Apple.
@BeePotato
"Pour ma part, je n’utilise pas Swift que dans l’écosystème Apple."
Tu fais partie de ceux qui continuent à l’utiliser en back malgré le retrait d’IBM ?
@ YetOneOtherGit : « Tu fais partie de ceux qui continuent à l’utiliser en back malgré le retrait d’IBM ? »
Je l’utilise en effet un peu pour ça — mais un peu seulement.
Car il n’y a (fort heureusement) pas que le « front » et le « back » dans la vie (rien de personnel — juste qu’à force d’être régulièrement irrité de voir des tonnes d’articles ou autres formes de blabla où les auteurs cherchent systématiquement à faire entrer toute activité de développement dans une de ces deux cases comme s’il n’existait rien d’autre, j’en arrive presque à haïr ces termes 🙂). Et comme j’ai la chance d’être dans un poste où je dispose d’une liberté de choix au niveau des langages utilisés pour certains projets, je me suis mis à utiliser Swift pour plusieurs outils tournant sur des Linux.
Parfois à des endroits où j’aurais auparavant utilisé du C, parfois à d’autres endroits où j’aurais pu utiliser du Python. La simplicité de l’accès depuis Swift à des bibliothèques dans ces langages facilite ce genre d’usages.
Quand le boulot sur la gestion des expressions régulières en Swift aura progressé de manière satisfaisante, ça m’ouvrira d’autres possibilités encore.
@BeePotato
"Ce qui, comme tu le rappelles toi-même juste après, n’est pas tout à fait la même chose."
Bin en fait, ça peut. En tout cas en C++. Avec la surcharge d’opérateurs, on peut implémenter pas mal de mécanismes bien fins. Et super chiants à debugger, comme tous les templates. Sans parler de la lisibilité. C++ quoi.
Mais bon. Pour dire que comptage de références, optionnels, trilean (true, false, wtf ou maybe)… ce n’est pas nouveau.
@fte
J’avais mal vue le destinataire de ton commentaire, j’imaginais un peu vite que c’était en réponse de Marc_OS 🙃
Bon, OK, @ YetOneOtherGit, la discussion est passionnante.
Et je l'avoue, tout ce qui s'éloigne un peu trop du paradigme et de la syntaxe du C me donne des gros boutons.
mais je crois que tu te fais une idée un peu farfelue du développement en fait.
Non, je n'ai pas du tout envie de me remettre en question tous les ans en "essayant" un "langage de programmation moderne", alors que ce que je fais marche toujours très bien en C/Objective-C (et en Java accessoirement, faut pas oublier android...)
Pourquoi ?
Parce que franchement, ça m'amuse plus de perdre mon temps à ces co... hum...
J'ai des apps à développer, et c'est déjà suffisamment casse-bonbon de tout re-vérifier à chaque version d'iOS, sans compter les fonctions que j'ajoute et les nouvelles apps, pour, en plus me mettre à un autre langage.
Je ne fais pas du "test de langage" dans la vraie vie.
Par ailleurs, je ne peux qu'être d'accord avec marc_os quand il écrit qu'il ne voit pas bien ce qu'apporte swift en terme de nouveaux devs et d'élargissement de la base.
Alors que c'était bien parti avec objective-C à un moment.
Là c'est juste le bordel et même Apple semble mettre bien du temps à faire tout migrer vers cette petite merveille...
Donc la seule interrogation que j'ai au sujet d'Apple, c'est "mais qu'allaient-ils faire dans cette galère ?"
@pecos
"mais je crois que tu te fais une idée un peu farfelue du développement en fait."
Pourquoi la qualifier de farfelu?
La tienne est respectable si tu y trouves ton compte et ne tombe pas dans la facilité du mépris pour des nécessaires évolutions dont tu ne veux pas pour toi.
Mais elle est loin d’être la norme et ce que je met en avant et assez largement partagé dans la communauté 😉
@pecos
"Par ailleurs, je ne peux qu'être d'accord avec marc_os quand il écrit qu'il ne voit pas bien ce qu'apporte swift en terme de nouveaux devs et d'élargissement de la base."
Marc_os et toi appartenait à une catégorie fort respectable de dev qui ne veulent pas bouger et rester sur un sam’suffit.
Cela ne me pose aucun pb tant que cela ne devient pas un mépris pour l’évolution des sciences informatiques, des pratiques, des méthodologies…
Comme je l’écrivais à Marc_OS on a connu exactement les mêmes positions face à l’arrivée de la programmation structurée, de l’orientation objet, des méthodologies sérieuses de développement…
Ce qui est problématique ce n’est nullement votre volonté de rester tranquillement figé dans votre zone de confort, mais le mépris affiché pour de pourtant nécessaire évolution.
C’est une classique guerre des anciens et des modernes et sans l’ombre d’un mépris vous évoluez dans une vision du développement issue des années 70.
Avec vos postures Fortran et Cobol serait encore la norme.
Et j’espère que tu ne vois aucun mépris dans ces propos, ta position et ton rapport pragmatique sont respectables. A condition de ne pas afficher le mépris d’un Marc_Os pour ce qui le dépasse.
@pecos
"Parce que franchement, ça m'amuse plus de perdre mon temps à ces co... hum..."
C’est un choix personnel que de désirer arrêter d’apprendre, de progresser, de sortir de sa zone de confort.
A titre personnel je trouve ça assez mortifère et antinomique de la grande qualité qu’offre le développement: on n’en à jamais fait le tour et c’est une constante motivation intellectuelle.
Mes cela demande évidemment une véritable passion et une grande curiosité intellectuelle pour la chose informatique.
@pecos
"je n'ai pas du tout envie de me remettre en question"
Hum.
Apprendre. Nous avons tous une marge de progression. Apprendre. Se remettre en question est surtout identifier où progresser. Et apprendre.
Si des choses nouvelles se font, si des combinaisons nouvelles sont utilisées… c’est peut-être une mode… ou pas. C’est peut-être qu’il y a des choses valables, intéressantes, et de quoi s’inspirer. Et apprendre.
En tant que patron, un employé qui ne veut plus apprendre est un employé qui perd de la valeur, donc son salaire est amené à être ajusté à la baisse.
Je viens de forker SWIFT !
A moi le fric
les putes et la gloaaaarrreee !
🤡
Cet article est très orienté (dès le titre) « Chris contre la fermeture d’Apple », mais pour ma part quand j’ai lu le message de Lattner, j’y ai plus vu un conflit de personnes et une divergence de vision.
Et du coup, il préfère s’occuper d’autre chose, et il a bien raison.
Une correction d’un passage de l’article :
« Puisque c’est Apple qui contrôle ce qui est intégré à Xcode et surtout à iOS et macOS, les développeurs qui veulent utiliser le langage n’ont pas d’autres choix que d’utiliser la version officielle. »
Les développeurs qui veulent utiliser le langage pour le développement d’applications MacOS ou iOS (et dérivés) n’ont pas d’autre choix que d’utiliser la version officielle.
Mais il y a d’autres usages possibles pour Swift, qui peuvent se faire avec d’autres branches.
https://media3.giphy.com/media/3og0ICG4WxdKSRzE3K/giphy.gif?cid=5e214886...
Pages