Le existant te permet juste d'aller beaucoup plus vite dans ton test. La logique applicative ne dépend pas du langage mais du framework. Vu qu'ici le framework est le même, tu peux totalement traduire un code, c'est censé marcher.
On ne prévoit pas la même architecture, les mêmes design patterns internes et la même logique de code quand on code avec un langage qui offre des choses comme les Optionals ou les Generics. Mais qui n'offre pas de KVC et de bindings. Il faut prendre en compte les possibilités offertes par le langage dès la conception de l'appli (et ce quel que soit le langage considéré)
On ne prévoit pas la même architecture, les mêmes design patterns internes et la même logique de code quand on code avec un langage qui offre des choses comme les Optionals ou les Generics. Mais qui n'offre pas de KVC et de bindings. Il faut prendre en compte les possibilités offertes par le langage dès la conception de l'appli (et ce quel que soit le langage considéré)
Les optionals et les Generics c'est gentil, mais les cas d'usage réels sont particulièrement rare. L'absence des KVC et des Bindings, c'est chiant, ça en fait pour moi un langage totalement inutile sous Mac. Aucune grosse application Mac ne peut se passer des bidnings.
Mais pour le reste, c'est la même chose. Dans mon cas j'ai du virer les bindings oui, c'est tout. Les Generics et les Optionals ne me servent à rien. Par contre les choses qui servent ne fonctionnent pas.
Tu refait ton archi si les nouveautés ont une utilité, c'est très loin d'être le cas ici. Les optionals avec nil on les avait déjà sur toute archi objet. Swift ne fait que complexifié leur usage. Et les generics, le cas réel de gain par rapport à un NSArray sont assez restreint.
Moi comme en ObjC on avait pas de Generics j'avais fait des pseudo macros un peu bidouille pour indiquer ce que devait contenir mes NSArray tellement ça me manquait en ObjC.
Mais ce qui est intéressant dans les Generics c'est pas juste les Array dont le contenu est typé, ça c'est juste une petite partie de ce que permettent les Generics.
Et les nil et les Optional c'est pas pareil, en Swift c'est explicite et c'est du Opt-In (tout en permettant avec l'optional chaining de faire test et appel d'un coup) donc ça évite bien des erreurs (sur une appli récente j'ai vu pas mal de bugs à cause du fait que les devs ne pensaient pas au cas nil genre "if ([string isEmptyOrWhitespace]) ..." qui vaut NO si string est nil contrairement à ce que la première lecture du code peut laisser penser... donc moi je trouve ça bien d'expliciter exactement quand une String peut être nil ou quand elle ne peut pas l'être. Sans parler de la possibilité d'avoir des Int ou des BOOL qui sont nil si on en a besoin.
Ah oui c'est sur avec Swift ça falloir un peu plus réfléchir, ouh la la c'est dur... va falloir penser est ce que ma variable peut être nil ou pas et si oui qu'est ce que je veux comme comportement (tout en ayant l'Optional Chaining pour l'utiliser avec une syntaxe concise). Pauvres petits devs.
Sauf que moi je trouve que c'est pour l'instant le meilleur compromis que j'ai pu voir dans un langage de prog :
- l'appel d'une méthode sur nil en ObjC qui ne plante pas mais en même temps ne fait rien du tout, c'est risqué car on peut tomber dans des mauvais car par inattention (isEmptyOrWhitespace).
- l'appel sur NULL en C/C++ qui fait un crash (NULL pointer dereference) c'est aussi violent et on ne le voit que si on passe par le cas au Runtime. Pas beaucoup mieux.
- En Swift c'est à la compilation qu'il te dit "non c'est bon ce truc peut jamais être nil vas-y tu peux appeler la méthode ou faire ton truc" ou "fais gaffe ce truc peut potentiellement être nil pense à gérer le cas". Beaucoup + sécurisant et sûr
Avant en ObjC à la limite on avait __attribute__((nonnull)) avec GCC qui pouvait faire 2-3 verifs et encore... sauf que personne ne l'utilisait en pratique. Et du coup ça donne vite des misbehaviors.
Je crois qu'on est vraiment pas d'accord sur Swift ^^
Concernant les Generics, le pauvre tableau typé ça sert à rien, et c'est facile de faire un wrapper sur NSArray pour le simuler.
Ce qui est intéressant avec les Generics c'est de faire des classes abstraites, jusqu'à présent je me suis dit une seule fois que ça pourrait m'être utile pour un truc et je sais même plus pour quoi. C'est puissant mais ça ne justifie pas un switch de langage juste pour ça. L'apport aurait pu être fait sur ObjC directement.
Quand aux optionals, c'est exactement la même logique et les mêmes tests que pour nil qu'il y a à faire. La seule et unique différence c'est que c'est renforcé par le compilo.
L'appel à nil qui renvois nil c'est extrêmement puissant, ça te permet de faire plusieurs test en même temps. C'est particulièrement rare les API de tests qui ne sont pas compatible avec un test sur le retour à nil.
Quand aux optionals, c'est exactement la même logique et les mêmes tests que pour nil qu'il y a à faire. La seule et unique différence c'est que c'est renforcé par le compilo.
Et c'est bien ça qui est intéressant
L'appel à nil qui renvois nil c'est extrêmement puissant, ça te permet de faire plusieurs test en même temps. C'est particulièrement rare les API de tests qui ne sont pas compatible avec un test sur le retour à nil.
Exactement comme en Swift. Tant avec le protocole LogicValue auquel se conforme Optional<T> que via le Optional Chaining. C'est même beaucoup plus puissant qu'en ObjC.
En ObjC tu peux faire [obj foo] et ça retourne nil tant si obj était nil que si obj était non-nil et foo retournait nil... sauf que beaucoup de gens même s'ils le savaient car ils l'ont après, ne pensaient pas toujours, à force de pisser du code, à vérifier que ce double-test implicite était effectivement ce qu'ils voulaient, cf mon exemple avec isEmptyOrWhitespace plus haut mais j'en ai des tonnes dans le même genre vu tous les projets sur lesquels j'ai fait de l'archi et du CodeReview, crois moi).
En Swift tu peux faire "obj?.foo()" c'est pareil, t'appelle la méthode foo sur obj que si obj existe. Si obj est nil ça va retourner nil. Si obj n'est pas nil mais que foo retourne nil, bah ça va faire pareil. Donc c'est exactement pareil qu'en ObjC. Sauf que c'est explicite, quand un dev écrit ça ça lui fait prendre conscience que obj peut potentiellement être nil dans ce cas car il a été déclaré comme un Optional
Sauf qu'en Swift tu peux aussi faire "obj.foo?()" pour tester à la fois si la fonction foo existe sur obj ET l'appeler seulement si elle existe. Alors qu'en ObjC t'es obligé de faire un truc tordu comme faire appel à respondsToSelector: explicitement avec le @selector (= le nom de la méthode sans les paramètres) avant d'appeler ensuite la méthode (= exactement le même nom de méthode mais avec les paramètres cette fois pour l'appel). Et c'est vite fait ensuite, soit suite à un copier/coller rapide, soit suite à un refactoring où on aurait remplacé l'appel à la méthode mais où on aurait oublié de changer le @selector qui va avec, de se retrouver avec des incohérences, du style je vérifie si mon objet répond à une méthode A et si oui j'appelle une méthode B...
J'ai déjà donné des exemples variés, comme la syntaxe lourde en ObjC concernant l'appel d'une méthode optionnelle d'un @protocol en ObjC d'un côté, et son équivalent en Swift, à la fois plus compact, plus explicite sur le fait que chacun des éléments puisse être nil, sans pour autant compliquer la syntaxe ("tableView.delegate?.didSelectRowAtIndexPath?(indexPath)" contre un truc en 3 lignes avec de la répétition partout en ObjC que j'ai même la flemme de réécrire ici...) mais permettant aux gens de réaliser que le résultat peut être un appel de méthode non fait du fait que l'objet soit nil (donc comme en ObjC mais rendu explicite).
Autre exemple, en ObjC, si tu imagines une méthode "indexOfSubstring:" sur NSString qui te retourne la position de la chaà®ne passé en paramètre dans la chaà®ne cible... (ah, oui, ou bien cette valeur tordue et bizarre qu'est NSNotFound sinon parce qu'ObjC n'a rien d'autre à proposer et qu'on est obligé de bidouiller :-S). Si tu écris [str indexOfSubstring:@foo] et que tu utilises la valeur de retour, bien souvent tu ne vas pas penser sur le coup au cas "si str est nil alors ça va me retourner 0... ce qui est aussi la réponse voulant dire que la chaà®ne str contient "foo" dès le premier caractère". --> En Swift, str?.indexOfSubstring("foo") te retourne clairement nil si soit str est lui-même nil ou si foo n'a pas été trouvé dans str (plutôt qu'une valeur bizarroà¯de comme (NSUInteger)(-1)!) et ne retourne 0 que si str existe et que "foo" est trouvé dedans dès le tout début.
Au moins c'est clair, sans ambiguà¯té, et quand tu écris la ligne tu as conscience que str peut aussi être nil. Tout en gardant un comportement cohérent (et même + cohérent qu'en ObjC).
Tout ce que tu es en train de dire c'est que Swift est à Objective-C ce qu'iOS est au Mac, une version amoindri qui fait joli, semble plus pratique mais qui limite la personne qui s'en sert.
Autant j'accepte cette vision pour les end-user, autant cette envie de tout renforcer pour les dev est une connerie à mon sens. Tout ce que ça apporte c'est un lot de développeur de plus en plus incompétents, incapable de comprendre comment ça marche en bas niveau.
J'ai commencé par de l'ASM et du C, même si je n'écris plus d'ASM je le lis toujours et je m'en sert toujours dès que j'ai du reverse à faire ou du debug trop poussé. Quand je vois le nombre de dev qui ne comprennent même pas ce que c'est, perso ça me fait peur. Et cette mode de s'éloigner du C et de la machine me fait de plus en plus peur, on va finir avec une ribambelle de développeur débile qui ne comprenne pas qu'il faut faire attention à tout quand on code et par soi-même...
Je sais que je fait vieux con, mais c'est contre nature pour moi c'est langage et environnement où le dev est pris pour un end-user débile.
Je comprend ton point de vue, et moi aussi j'ai fait de l'ASM et du C (embarqué et bas niveau).
Je te rejoins sur le fait que les devs de maintenant ne comprennent plus trop ce qui se passe sous le capot, mais honnêtement, cette tendance m'a bien + choqué quand il y a eu le passage à ARC. J'ai longtemps dit d'ailleurs que je ne migrerai pas à ARC de sitôt, car je préférais faire la gestion de la mémoire moi-même, non seulement parce que je préférais comprendre ce que je faisais de ce côté et parce que ça me paraissait mieux. Et je voyais (et j'en vois encore) des gens qui ne comprennent pas trop ces problématiques de Retain Cycle et gestion mémoire parce qu'ils n'ont connu que ARC et jamais le Manual-Retain-Release, et qui du coup n'ont jamais eu à se demander ce qui se passait sous le capot au final ni à comprendre pourquoi ni comment ça marchait.
Là Swift au contraire de toi j'ai l'impression qu'au contraire d'avoir une version amoindrie, c'est une versionion plus safe et plus stricte. Certains aimerons moins ce côté strict car "pfff faut réfléchir à ce qu'on fait sinon le compilateur nous engueule". C'est pour ça que je disais plus haut "oh là là pauvres petits ils vont devoir réfléchir maintenant". Bah ouais mais moi désolé je trouve ça mieux de les forcer un peu à réfléchir à savoir si leur variable peut être nil ou pas et à les forcer à se poser la question, plutôt que de ne pas trop y réfléchir et de faire des erreurs (comme ne pas réaliser que [str indexOfSubstring:@foo] quand str est nil ça renverra zéro) mais de ne pas s'en rendre compte (parce que quand ils feront mumuse avec leur programme ça marchera car ils penseront jamais à faire le test qui tombe pile sur ce cas).
De ce côté là donc je trouve que Swift à la fois donne plus de flexibilité au sens du langage (Generics, Optionals) tout en étant safe et fortement typé et obligeant les devs à faire gaffe à ce qu'ils font sinon c'est le compilo qui pourra gueuler au plus tôt. D'autant que soyons honnêtes, même si nous on sait ce qu'on fait et qu'on connaà®t ces écueils dans lesquels on peut tomber comme le coup d'appeler une méthode sur nil et que ça renvoie 0==nil==NULL==NO en retour, ça ne nous empêche pas de risquer de tomber dedans quand même, surtout quand un code devient compliqué et qu'on peut passer à côté d'un de ces cas.
C'est comme le cas où tu appelles [super init] au tout début de la méthode "init" au lieu d'à la fin, les problèmes que ça peut causer sous le capot (encore + si tu utilises du KVO d'ailleurs, mais pas que), problèmes dont peu de gens ont conscience, et que même si toi tu as conscience des cas où ça peut poser problème, tu n'as pas envie d'avoir à te prendre la tête avec à chaque init et surtout il peut t'arriver de manquer un de ces cas (surtout qu'ils peuvent être assez tricky). Alors que là le compilo va savoir te le signaler au plus tôt, là où tu l'aurais peut-être loupé même si tu connais le problème, que tu es expérimenté, et que tu fais gaffe.
Le seul regret qu'on peut avoir avec Swift c'est que c'est pas fait pour faire du très bas niveau comme le C, à manipuler les pointeurs et la mémoire et tout. Et je te rejoins, là dessus c'est pas fait pour, et ça va pas inciter les nouveaux arrivants à comprendre comment ça marche sous le capot (sauf ceux qui ont fait des études et pour qui ça fait partie des cours). Mais Swift est un langage objet après tout, c'est pas sa vocation de faire du bas niveau. Si c'est ça que tu cherches à faire avec Swift je comprends que tu sois déçu. D'ailleurs rien ne t'empêche de continuer à faire du C là où tu en as besoin (algorithmes à optimiser, bidouilles bas niveau...) ; mais pour les applis de tous les jours dont l'architecture est orientée POO et haut niveau, un vrai langage POO qui ne s'embête plus avec les pointeurs et les trucs risqués auxquels peuvent mener des manipulations bas niveau, c'est quand même plus adapté.
En bref, je te rejoins sur le fait que plus on avance (ARC, Swift, ...) plus on s'éloigne du langage machine et plus on va dans des langages POO avec une couche d'abstraction pour simplifier la syntaxe et sécuriser le code. Mais est-ce une mauvaise chose ? Si tu aimes mettre les mains dans le cambouis, c'est sûr, c'est pas le truc qu'il te faut, mais si tu veux faire une appli bien architecturée et sans risque de coups fourrés ou de bugs difficiles à traquer, autant utiliser les outils haut niveau pour le faire. C'est comme si tu continuais à faire des threads avec pthread alors que tu as maintenant NSOperationQueue & GCD. Certes les pthread c'est plus bas niveau et alors ?
Ca va peut-être apporter son lot de devs de plus en plus incompétents exactement au même titre qu'ARC a déjà eu exactement ce même effet, avec les gens qui ne savent plus comment marche la mémoire sous le capot et les concepts de Reference Counting et tout. Mais d'un autre côté, avec sa syntaxe renforcée et son typage + fort qu'ObjC, ça va aussi forcer les nouveaux devs en Swift à + réfléchir sur d'autres points, là où avant ils auraient dû sans doute y réfléchir par eux-même ("est-ce que ma variable sur laquelle j'appelle cette méthode peut potentiellement être nil ? Et si oui quelle conséquence sur mon codeflow ?") là ils vont être obligés d'y réfléchir. Ca va peut-être au contraire se faire poser des questions à certains.
Je suis franchement pas convaincu, ceux qui ne se posaient déjà pas la question se la poseront n'importe comment et ne gèreront quand même pas leur erreur. Ce n'est pas par ce que le langage impose de faire un truc que les gens ne vont pas le contourner. Pour les boulets, pas de changement.
Pour les autres, ça casse les couilles pour rien vu que le système t'oblige à coder comme lui l'entend, même si tu sais ce que tu fais...
Sinon, ton commentaire sur le init m'interpèle. Je suis curieux de voir comment tu fait tes constructeurs avec un init qui n'est pas au début (et BTW, pour éviter le KVC dans les init, tu es censé faire des assignations d'ivar, pas des appels de properties).
Je suis franchement pas convaincu, ceux qui ne se posaient déjà pas la question se la poseront n'importe comment et ne gèreront quand même pas leur erreur. Ce n'est pas par ce que le langage impose de faire un truc que les gens ne vont pas le contourner. Pour les boulets, pas de changement.
Mouais, pour moi ça va dans le même sens que ARC et ce genre d'évolutions. Ca pouvait arriver à tout le monde, nous y compris, d'oublier un retain ou un release par-ci par-là . Et puis même si j'aimais gérer la mémoire manuellement, et que j'ai été réticent à passer à ARC, bah j'avoue que depuis que j'y suis passé je referai pas marche arrière
Sinon, ton commentaire sur le init m'interpèle. Je suis curieux de voir comment tu fait tes constructeurs avec un init qui n'est pas au début (et BTW, pour éviter le KVC dans les init, tu es censé faire des assignations d'ivar, pas des appels de properties).
Tel qu'ObjC est prévu avec le init qui retourne un instancetype on ne peut pas l'appeler avant. Et du coup faut être extra careful justement pour tous les effets de bord.
Donc déjà oui il faut utiliser les ivar dans les init, et les setters/getters dans le reste du code. Sauf que si dans ton init tu appelles une autre méthode parce que tu as du code commun à exécuter... et que cette méthode elle appelle une autre méthode qui... au final utilise le setter, bah tu as fini par appeler du KVC pour dans le init si tu fais pas gaffe. Mais y'a bien plus que ça, comme les valeurs non encore initialisées ou les init croisés quand certains sont overridés et pas d'autres. Ils parlent de 2-3 cas comme ça d'ailleurs dans les confs, même s'il en existe quelques autres aussi alambiqués. Bref y'a de quoi faire pour se faire avoir, même si t'es expérimenté et même si tu utilises des ivar dans ton init.
Et en passant avec Swift impossible d'avoir le problème puisqu'il impose l'ordre d'appel, qu'il empêche le KVO, qu'il impose que toutes les ivars soient initialisées, et qui fait ainsi tout ce qu'il faut pour éviter de tomber dans tous les ecueils possibles qu'ObjC permet, même aux plus expérimentés.
Je pense surtout que Yoann veut dire également que Swift n'apporte pas assez de nouveautés par rapport aux problèmes d'intégration qu'il peut susciter sur une app existante. Il faudra vraiment peser le pour et le contre avant de migrer son code.
Mon app fait 55k de code, et il faut vraiment être motivé pour se lancer dans une migration, même dans quelques mois quand Swift sera plus stable et mûr.
Pour les nouveaux projets, c'est différent, on peut partir de zéro: mais on ne fait pas des nouveaux projets sans arrêt (sauf si on est prestataire, et pas éditeur).
Je pense surtout que Yoann veut dire également que Swift n'apporte pas assez de nouveautés par rapport aux problèmes d'intégration qu'il peut susciter sur une app existante. Il faudra vraiment peser le pour et le contre avant de migrer son code.
Bah surtout il n'y a strictement rien qui justifie de casser les couilles avec un nouveau langage. Les trois conneries apportés auraient pu l'être dans ObjC, évitant ainsi de perdre des dizaines d'années de code. Car, que vous le vouliez ou non, si Swift est l'avenir, il faudra impérativement tout réécrire un jour où l'autre. Quand on voit le temps que ça a pris pour Carbon dont on sort à peine plus de dix ans après...
C'est vraiment un mauvais signal et une mauvaise stratégie pour moi au moment où l'environnement s'étend comme pas possible. Remettre à zéro l'historique des savoirs et des codes existants pour une lubie de pseudo performance de l'équipe LLVM et de sécurité pour prendre par la main les développeur, c'est con. Renforcer ObjC comme ils l'ont fait avec clang static analyzer et avec ARC aurait été bien plus intelligent.
Je pense surtout que Yoann veut dire également que Swift n'apporte pas assez de nouveautés par rapport aux problèmes d'intégration qu'il peut susciter sur une app existante. Il faudra vraiment peser le pour et le contre avant de migrer son code.
Mon app fait 55k de code, et il faut vraiment être motivé pour se lancer dans une migration, même dans quelques mois quand Swift sera plus stable et mûr.
Pour les nouveaux projets, c'est différent, on peut partir de zéro: mais on ne fait pas des nouveaux projets sans arrêt (sauf si on est prestataire, et pas éditeur).
mais c'est ce que j'arrête pas de dire !!! ça sert à rien de *migrer* du code d'une app existante (et en + je vois pas l'intérêt). Si vous voulez tester sur un vrai exemple faites une nouvelle app au lieu de porter une app déjà faite !!
mais c'est ce que j'arrête pas de dire !!! ça sert à rien de *migrer* du code d'une app existante (et en + je vois pas l'intérêt). Si vous voulez tester sur un vrai exemple faites une nouvelle app au lieu de porter une app déjà faite !!
C'est pas ce que je dis exactement.
Je dis que même dans 2 ans, ça n'aura sûrement pas plus d'intérêt.
Et puis faut avoir envie de faire du neuf pour trouver un intérêt !
Vu tout ce qui a été dit ici, je vais surseoir un certain temps à l'utilisation de Swift. J'ai commencé à lire, et cela va probablement vous sembler curieux, j'ai l'impression de trouver des petits bouts de Pascal, de Basic et même d'AppleScipt Studio. Dit autrement, je n'arrive pas à en saisir clairement la philosophie.
Renforcer ObjC comme ils l'ont fait avec clang static analyzer et avec ARC aurait été bien plus intelligent.
Ah là par contre je te rejoins entièrement. Je trouve que cela aurait été tout aussi bien de faire évoluer ObjC (comme ils l'ont déjà fait par le passé) pour ajouter toutes ces nouveautés.
Ah là par contre je te rejoins entièrement. Je trouve que cela aurait été tout aussi bien de faire évoluer ObjC (comme ils l'ont déjà fait par le passé) pour ajouter toutes ces nouveautés.
Moi aussi je suis d'accord !
Mais était-ce possible techniquement sur la base du C ?
Moi aussi je suis d'accord ! Mais était-ce possible techniquement sur la base du C ?
Je ne pense pas (et d'ailleurs c'est ce qu'ils expliquent dans les confs dédiées de la WWDC si je ne m'abuse). Et c'est l'explication pour laquelle ils sont partis sur Swift plutôt que sur une évolution d'ObjC.
Tout ce que tu es en train de dire c'est que Swift est à Objective-C ce qu'iOS est au Mac, une version amoindri qui fait joli, semble plus pratique mais qui limite la personne qui s'en sert.
Autant j'accepte cette vision pour les end-user, autant cette envie de tout renforcer pour les dev est une connerie à mon sens. Tout ce que ça apporte c'est un lot de développeur de plus en plus incompétents, incapable de comprendre comment ça marche en bas niveau.
J'ai commencé par de l'ASM et du C, même si je n'écris plus d'ASM je le lis toujours et je m'en sert toujours dès que j'ai du reverse à faire ou du debug trop poussé. Quand je vois le nombre de dev qui ne comprennent même pas ce que c'est, perso ça me fait peur. Et cette mode de s'éloigner du C et de la machine me fait de plus en plus peur, on va finir avec une ribambelle de développeur débile qui ne comprenne pas qu'il faut faire attention à tout quand on code et par soi-même...
Je sais que je fait vieux con, mais c'est contre nature pour moi c'est langage et environnement où le dev est pris pour un end-user débile.
Je ne vois pas pourquoi les outils de "développement" (pour être plus générique, je dirais "génie logiciel") ne devraient pas évoluer vers plus de simplicité. C'est même une nécessité vu la complexité croissante des développements.
Sans vouloir faire du mauvais esprit ni remettre en cause tes compétences en développement, en tant qu'admin sys. (ce qui est me semble-t-il ta principale activité), tu n'as sans doute jamais été confronté à des projets logiciels ultra complexes de plusieurs millions de lignes de code, ni travaillé avec des dizaines de personnes sur les mêmes sources. Dans ces conditions, les évolutions des langages, notamment au niveau de la gestion mémoire et du typage fort, sont une nécessité pour que les phases de développement et mise au point ne fassent pas exploser les budgets.
Moi aussi j'ai commencé par l'ASM. Moi aussi j'ai ensuite fait du C. D'ailleurs pourquoi ? Puisque finalement en ASM on fait mieux qu'en C. Simplement parce que l'augmentation de la complexité nécessite des outils plus évolués. Beaucoup de softs critiques sont écrits depuis bien longtemps en langages fortement typés, notamment ADA (Thales, Airbus, etc...).
Ce n'est pas le langage qui fait un bon ou un mauvais developpeur. C'est sa capacité à créer et mettre en oeuvre des algorithmes de plus en plus complexes. S'affranchir des "détails" (après tout je conduis une voiture sans savoir comment l'injection électronique fonctionne) permet d'être plus performant.
Après, je ne dis pas non plus que Swift est parfait, surtout en ce qui concerne l'interopérabilité avec les frameworks existants. Loin de là . Mais ça évoluera.
Je ne vois pas pourquoi les outils de "développement" (pour être plus générique, je dirais "génie logiciel") ne devraient pas évoluer vers plus de simplicité. C'est même une nécessité vu la complexité croissante des développements.
Sans vouloir faire du mauvais esprit ni remettre en cause tes compétences en développement, en tant qu'admin sys. (ce qui est me semble-t-il ta principale activité), tu n'as sans doute jamais été confronté à des projets logiciels ultra complexes de plusieurs millions de lignes de code, ni travaillé avec des dizaines de personnes sur les mêmes sources. Dans ces conditions, les évolutions des langages, notamment au niveau de la gestion mémoire et du typage fort, sont une nécessité pour que les phases de développement et mise au point ne fassent pas exploser les budgets.
Moi aussi j'ai commencé par l'ASM. Moi aussi j'ai ensuite fait du C. D'ailleurs pourquoi ? Puisque finalement en ASM on fait mieux qu'en C. Simplement parce que l'augmentation de la complexité nécessite des outils plus évolués. Beaucoup de softs critiques sont écrits depuis bien longtemps en langages fortement typés, notamment ADA (Thales, Airbus, etc...).
Ce n'est pas le langage qui fait un bon ou un mauvais developpeur. C'est sa capacité à créer et mettre en oeuvre des algorithmes de plus en plus complexes. S'affranchir des "détails" (après tout je conduis une voiture sans savoir comment l'injection électronique fonctionne) permet d'être plus performant.
Après, je ne dis pas non plus que Swift est parfait, surtout en ce qui concerne l'interopérabilité avec les frameworks existants. Loin de là . Mais ça évoluera.
Je ne dis pas que ce ne doit pas évoluer, mais que ça doit évoluer dans le bon sens. La simplicité et l'efficacité oui, l'infantilisation, non. Et il est quand même nécessaire de rappeler sur quelle plateforme on est... iOS voire OS X, ce n'est pas un A380 !
Faire chier pour passer du typage faible au typage fort, je trouve ça con. ça fait des années que des soft somme toute complexe autour de la vidéo, du son ou des sciences sont fait sous Mac avec l'existant et ça fonctionne.
Balancer Swift pour palier au manque de rigueur d'un petit subset de dev, c'est juste déprimant.
Je suis d'accord ça ne changera presque rien pour la plupart des dev une fois cette syntaxe dégueulasse apprise et quelques années de stabilisation du langage passé. Presque rien hormis la perte du KVO et des bindings qui sont obligatoire pour toute application lourde sous Mac et la perte de toute l'historique de code existant.
Vu la cote des produits Apple aujourd'hui, on a franchement pas besoin d'un truc de merde au milieu qu'il va falloir déboguer en plus du reste. Les conneries de blur et de sandbox suffisent largement à ralentir et limiter l'activité de tout le monde...
La simplicité et l'efficacité oui, l'infantilisation, non.
Je pense que c'est là que nos avis diffèrent. Moi je vois ça comme de la sécurité supplémentaire et du type-safety. C'est pas de l'infantilisation, c'est de la sécurité.
J'ai jamais aimé les langages à typage faible (c'est un des plus gros reproches que je ferais à des langages comme Ruby par exemple, malgré tout l'amour que je lui porte, bien qu'étant un langage de scripting il a une excuse).
Je viens de lire tous vos messages, d'ailleurs je trouve ce post vraiment intéressant !! Là ou je rejoins AliGator et Yoann (et oui, on peut être d'accord avec les deux :-p ) c'est qu'il faut que les nouveaux développeurs (un peu comme moi, seulement 4 ans d'xp -> Encore un peu jeune par rapport à vous, et encore bcp de chose à apprendre ;-) ) s'intéressent un peu plus au fonctionnement du language utilisée !
Même si vous avez quelque divergence sur l'utilisation de Swift, je pense que la leçon principale c'est celle là : Quelque que soit le langage utilisée dans les applications iOS ou OSX (et autre), le développeur doit absolument savoir ce qu'il fait et doit être capable de justifier chaque ligne de code (Dans la pratique c'est moins vrai, on est d'accord ^^)
Sur Swift, je serais plus pour AliGator dans le sens où, j'ai commencé iOS sans ARC et l'analogie entre l'évolution de ARC et l'apparition de Swift est bonne je pense. Je suis sûr que bcp de monde vont critiquer Swift (je peux le faire aussi, mais c'est un peu tôt je trouve car ce n'est pas une beta mais une ALPHA) mais je pense que dans 2 ou 3 ans, la plus part des personnes auront adoptés Swift et on aura une keynote Apple disant -> "Tant de % de nouveaux développeurs cette année grâce à Swift et tant de % d'ancien développeurs ont migré vers Swift" avec des nombres pharaonique :-)
Mais comme je conseille souvent aux nouveaux développeurs (sur iOS en tout cas) -> "Commencez sans les outils comme ARC et avec objective c pour bien comprendre le fonctionnement et après commencez à regarder comment on utilise les outils". Je fais de même avec la programmation des IHM "Commencez avec la programmation pure et après utilisez les .xib et les .storyboard", on remarque après que les développeurs savent déjà qu'elle option choisir pour les Outlets et ils ont simplement à savoir où là cocher, c'est plus sympa que de cocher à tout va pour avoir l'effet désiré :-p
Les paris sont ouverts. Moi je dis 3 ans pas plus.
Non, je ne pense pas. Ca n'a aucun intérêt pour Apple, hormis se mettre à dos les développeurs qui ont déjà des centaines de milliers de lignes de code en ObjC qu'ils n'ont pas le temps ni l'envie de porter en Swift. Même en interne, je doute qu'ils réécrivent Cocoa/CocoaTouch en swift.
Par contre il est évident qu' ObjC n'évoluera plus.
Xcode 6 Beta 4 est de sortie, et entre autres nouveautés, l'arrivée des Access Control, c'est à dire la possibilité de définir une déclaration "private" ou "public" ou "internal" !!
Réponses
Les optionals et les Generics c'est gentil, mais les cas d'usage réels sont particulièrement rare. L'absence des KVC et des Bindings, c'est chiant, ça en fait pour moi un langage totalement inutile sous Mac. Aucune grosse application Mac ne peut se passer des bidnings.
Mais pour le reste, c'est la même chose. Dans mon cas j'ai du virer les bindings oui, c'est tout. Les Generics et les Optionals ne me servent à rien. Par contre les choses qui servent ne fonctionnent pas.
Tu refait ton archi si les nouveautés ont une utilité, c'est très loin d'être le cas ici. Les optionals avec nil on les avait déjà sur toute archi objet. Swift ne fait que complexifié leur usage. Et les generics, le cas réel de gain par rapport à un NSArray sont assez restreint.
Mais ce qui est intéressant dans les Generics c'est pas juste les Array dont le contenu est typé, ça c'est juste une petite partie de ce que permettent les Generics.
Et les nil et les Optional c'est pas pareil, en Swift c'est explicite et c'est du Opt-In (tout en permettant avec l'optional chaining de faire test et appel d'un coup) donc ça évite bien des erreurs (sur une appli récente j'ai vu pas mal de bugs à cause du fait que les devs ne pensaient pas au cas nil genre "if ([string isEmptyOrWhitespace]) ..." qui vaut NO si string est nil contrairement à ce que la première lecture du code peut laisser penser... donc moi je trouve ça bien d'expliciter exactement quand une String peut être nil ou quand elle ne peut pas l'être. Sans parler de la possibilité d'avoir des Int ou des BOOL qui sont nil si on en a besoin.
Ah oui c'est sur avec Swift ça falloir un peu plus réfléchir, ouh la la c'est dur... va falloir penser est ce que ma variable peut être nil ou pas et si oui qu'est ce que je veux comme comportement (tout en ayant l'Optional Chaining pour l'utiliser avec une syntaxe concise). Pauvres petits devs.
Sauf que moi je trouve que c'est pour l'instant le meilleur compromis que j'ai pu voir dans un langage de prog :
- l'appel d'une méthode sur nil en ObjC qui ne plante pas mais en même temps ne fait rien du tout, c'est risqué car on peut tomber dans des mauvais car par inattention (isEmptyOrWhitespace).
- l'appel sur NULL en C/C++ qui fait un crash (NULL pointer dereference) c'est aussi violent et on ne le voit que si on passe par le cas au Runtime. Pas beaucoup mieux.
- En Swift c'est à la compilation qu'il te dit "non c'est bon ce truc peut jamais être nil vas-y tu peux appeler la méthode ou faire ton truc" ou "fais gaffe ce truc peut potentiellement être nil pense à gérer le cas". Beaucoup + sécurisant et sûr
Avant en ObjC à la limite on avait __attribute__((nonnull)) avec GCC qui pouvait faire 2-3 verifs et encore... sauf que personne ne l'utilisait en pratique. Et du coup ça donne vite des misbehaviors.
Je crois qu'on est vraiment pas d'accord sur Swift ^^
Concernant les Generics, le pauvre tableau typé ça sert à rien, et c'est facile de faire un wrapper sur NSArray pour le simuler.
Ce qui est intéressant avec les Generics c'est de faire des classes abstraites, jusqu'à présent je me suis dit une seule fois que ça pourrait m'être utile pour un truc et je sais même plus pour quoi. C'est puissant mais ça ne justifie pas un switch de langage juste pour ça. L'apport aurait pu être fait sur ObjC directement.
Quand aux optionals, c'est exactement la même logique et les mêmes tests que pour nil qu'il y a à faire. La seule et unique différence c'est que c'est renforcé par le compilo.
L'appel à nil qui renvois nil c'est extrêmement puissant, ça te permet de faire plusieurs test en même temps. C'est particulièrement rare les API de tests qui ne sont pas compatible avec un test sur le retour à nil.
Exactement comme en Swift. Tant avec le protocole LogicValue auquel se conforme Optional<T> que via le Optional Chaining. C'est même beaucoup plus puissant qu'en ObjC.
- En ObjC tu peux faire [obj foo] et ça retourne nil tant si obj était nil que si obj était non-nil et foo retournait nil... sauf que beaucoup de gens même s'ils le savaient car ils l'ont après, ne pensaient pas toujours, à force de pisser du code, à vérifier que ce double-test implicite était effectivement ce qu'ils voulaient, cf mon exemple avec isEmptyOrWhitespace plus haut mais j'en ai des tonnes dans le même genre vu tous les projets sur lesquels j'ai fait de l'archi et du CodeReview, crois moi).
- En Swift tu peux faire "obj?.foo()" c'est pareil, t'appelle la méthode foo sur obj que si obj existe. Si obj est nil ça va retourner nil. Si obj n'est pas nil mais que foo retourne nil, bah ça va faire pareil. Donc c'est exactement pareil qu'en ObjC. Sauf que c'est explicite, quand un dev écrit ça ça lui fait prendre conscience que obj peut potentiellement être nil dans ce cas car il a été déclaré comme un Optional
- Sauf qu'en Swift tu peux aussi faire "obj.foo?()" pour tester à la fois si la fonction foo existe sur obj ET l'appeler seulement si elle existe. Alors qu'en ObjC t'es obligé de faire un truc tordu comme faire appel à respondsToSelector: explicitement avec le @selector (= le nom de la méthode sans les paramètres) avant d'appeler ensuite la méthode (= exactement le même nom de méthode mais avec les paramètres cette fois pour l'appel). Et c'est vite fait ensuite, soit suite à un copier/coller rapide, soit suite à un refactoring où on aurait remplacé l'appel à la méthode mais où on aurait oublié de changer le @selector qui va avec, de se retrouver avec des incohérences, du style je vérifie si mon objet répond à une méthode A et si oui j'appelle une méthode B...
J'ai déjà donné des exemples variés, comme la syntaxe lourde en ObjC concernant l'appel d'une méthode optionnelle d'un @protocol en ObjC d'un côté, et son équivalent en Swift, à la fois plus compact, plus explicite sur le fait que chacun des éléments puisse être nil, sans pour autant compliquer la syntaxe ("tableView.delegate?.didSelectRowAtIndexPath?(indexPath)" contre un truc en 3 lignes avec de la répétition partout en ObjC que j'ai même la flemme de réécrire ici...) mais permettant aux gens de réaliser que le résultat peut être un appel de méthode non fait du fait que l'objet soit nil (donc comme en ObjC mais rendu explicite).Autre exemple, en ObjC, si tu imagines une méthode "indexOfSubstring:" sur NSString qui te retourne la position de la chaà®ne passé en paramètre dans la chaà®ne cible... (ah, oui, ou bien cette valeur tordue et bizarre qu'est NSNotFound sinon parce qu'ObjC n'a rien d'autre à proposer et qu'on est obligé de bidouiller :-S). Si tu écris [str indexOfSubstring:@foo] et que tu utilises la valeur de retour, bien souvent tu ne vas pas penser sur le coup au cas "si str est nil alors ça va me retourner 0... ce qui est aussi la réponse voulant dire que la chaà®ne str contient "foo" dès le premier caractère".
--> En Swift, str?.indexOfSubstring("foo") te retourne clairement nil si soit str est lui-même nil ou si foo n'a pas été trouvé dans str (plutôt qu'une valeur bizarroà¯de comme (NSUInteger)(-1)!) et ne retourne 0 que si str existe et que "foo" est trouvé dedans dès le tout début.
Au moins c'est clair, sans ambiguà¯té, et quand tu écris la ligne tu as conscience que str peut aussi être nil. Tout en gardant un comportement cohérent (et même + cohérent qu'en ObjC).
Tout ce que tu es en train de dire c'est que Swift est à Objective-C ce qu'iOS est au Mac, une version amoindri qui fait joli, semble plus pratique mais qui limite la personne qui s'en sert.
Autant j'accepte cette vision pour les end-user, autant cette envie de tout renforcer pour les dev est une connerie à mon sens. Tout ce que ça apporte c'est un lot de développeur de plus en plus incompétents, incapable de comprendre comment ça marche en bas niveau.
J'ai commencé par de l'ASM et du C, même si je n'écris plus d'ASM je le lis toujours et je m'en sert toujours dès que j'ai du reverse à faire ou du debug trop poussé. Quand je vois le nombre de dev qui ne comprennent même pas ce que c'est, perso ça me fait peur. Et cette mode de s'éloigner du C et de la machine me fait de plus en plus peur, on va finir avec une ribambelle de développeur débile qui ne comprenne pas qu'il faut faire attention à tout quand on code et par soi-même...
Je sais que je fait vieux con, mais c'est contre nature pour moi c'est langage et environnement où le dev est pris pour un end-user débile.
Je te rejoins sur le fait que les devs de maintenant ne comprennent plus trop ce qui se passe sous le capot, mais honnêtement, cette tendance m'a bien + choqué quand il y a eu le passage à ARC. J'ai longtemps dit d'ailleurs que je ne migrerai pas à ARC de sitôt, car je préférais faire la gestion de la mémoire moi-même, non seulement parce que je préférais comprendre ce que je faisais de ce côté et parce que ça me paraissait mieux. Et je voyais (et j'en vois encore) des gens qui ne comprennent pas trop ces problématiques de Retain Cycle et gestion mémoire parce qu'ils n'ont connu que ARC et jamais le Manual-Retain-Release, et qui du coup n'ont jamais eu à se demander ce qui se passait sous le capot au final ni à comprendre pourquoi ni comment ça marchait.
Là Swift au contraire de toi j'ai l'impression qu'au contraire d'avoir une version amoindrie, c'est une versionion plus safe et plus stricte. Certains aimerons moins ce côté strict car "pfff faut réfléchir à ce qu'on fait sinon le compilateur nous engueule". C'est pour ça que je disais plus haut "oh là là pauvres petits ils vont devoir réfléchir maintenant".
Bah ouais mais moi désolé je trouve ça mieux de les forcer un peu à réfléchir à savoir si leur variable peut être nil ou pas et à les forcer à se poser la question, plutôt que de ne pas trop y réfléchir et de faire des erreurs (comme ne pas réaliser que [str indexOfSubstring:@foo] quand str est nil ça renverra zéro) mais de ne pas s'en rendre compte (parce que quand ils feront mumuse avec leur programme ça marchera car ils penseront jamais à faire le test qui tombe pile sur ce cas).
De ce côté là donc je trouve que Swift à la fois donne plus de flexibilité au sens du langage (Generics, Optionals) tout en étant safe et fortement typé et obligeant les devs à faire gaffe à ce qu'ils font sinon c'est le compilo qui pourra gueuler au plus tôt.
D'autant que soyons honnêtes, même si nous on sait ce qu'on fait et qu'on connaà®t ces écueils dans lesquels on peut tomber comme le coup d'appeler une méthode sur nil et que ça renvoie 0==nil==NULL==NO en retour, ça ne nous empêche pas de risquer de tomber dedans quand même, surtout quand un code devient compliqué et qu'on peut passer à côté d'un de ces cas.
C'est comme le cas où tu appelles [super init] au tout début de la méthode "init" au lieu d'à la fin, les problèmes que ça peut causer sous le capot (encore + si tu utilises du KVO d'ailleurs, mais pas que), problèmes dont peu de gens ont conscience, et que même si toi tu as conscience des cas où ça peut poser problème, tu n'as pas envie d'avoir à te prendre la tête avec à chaque init et surtout il peut t'arriver de manquer un de ces cas (surtout qu'ils peuvent être assez tricky). Alors que là le compilo va savoir te le signaler au plus tôt, là où tu l'aurais peut-être loupé même si tu connais le problème, que tu es expérimenté, et que tu fais gaffe.
Le seul regret qu'on peut avoir avec Swift c'est que c'est pas fait pour faire du très bas niveau comme le C, à manipuler les pointeurs et la mémoire et tout. Et je te rejoins, là dessus c'est pas fait pour, et ça va pas inciter les nouveaux arrivants à comprendre comment ça marche sous le capot (sauf ceux qui ont fait des études et pour qui ça fait partie des cours).
Mais Swift est un langage objet après tout, c'est pas sa vocation de faire du bas niveau. Si c'est ça que tu cherches à faire avec Swift je comprends que tu sois déçu. D'ailleurs rien ne t'empêche de continuer à faire du C là où tu en as besoin (algorithmes à optimiser, bidouilles bas niveau...) ; mais pour les applis de tous les jours dont l'architecture est orientée POO et haut niveau, un vrai langage POO qui ne s'embête plus avec les pointeurs et les trucs risqués auxquels peuvent mener des manipulations bas niveau, c'est quand même plus adapté.
En bref, je te rejoins sur le fait que plus on avance (ARC, Swift, ...) plus on s'éloigne du langage machine et plus on va dans des langages POO avec une couche d'abstraction pour simplifier la syntaxe et sécuriser le code. Mais est-ce une mauvaise chose ? Si tu aimes mettre les mains dans le cambouis, c'est sûr, c'est pas le truc qu'il te faut, mais si tu veux faire une appli bien architecturée et sans risque de coups fourrés ou de bugs difficiles à traquer, autant utiliser les outils haut niveau pour le faire. C'est comme si tu continuais à faire des threads avec pthread alors que tu as maintenant NSOperationQueue & GCD. Certes les pthread c'est plus bas niveau et alors ?
Ca va peut-être apporter son lot de devs de plus en plus incompétents exactement au même titre qu'ARC a déjà eu exactement ce même effet, avec les gens qui ne savent plus comment marche la mémoire sous le capot et les concepts de Reference Counting et tout. Mais d'un autre côté, avec sa syntaxe renforcée et son typage + fort qu'ObjC, ça va aussi forcer les nouveaux devs en Swift à + réfléchir sur d'autres points, là où avant ils auraient dû sans doute y réfléchir par eux-même ("est-ce que ma variable sur laquelle j'appelle cette méthode peut potentiellement être nil ? Et si oui quelle conséquence sur mon codeflow ?") là ils vont être obligés d'y réfléchir. Ca va peut-être au contraire se faire poser des questions à certains.
J'ai fusionné les 2 sujets qui parlaient de Swift (le général de Yoann et celui sur les tris) car les 2 étaient devenus des points de vue.
Je suis franchement pas convaincu, ceux qui ne se posaient déjà pas la question se la poseront n'importe comment et ne gèreront quand même pas leur erreur. Ce n'est pas par ce que le langage impose de faire un truc que les gens ne vont pas le contourner. Pour les boulets, pas de changement.
Pour les autres, ça casse les couilles pour rien vu que le système t'oblige à coder comme lui l'entend, même si tu sais ce que tu fais...
Sinon, ton commentaire sur le init m'interpèle. Je suis curieux de voir comment tu fait tes constructeurs avec un init qui n'est pas au début (et BTW, pour éviter le KVC dans les init, tu es censé faire des assignations d'ivar, pas des appels de properties).
Tel qu'ObjC est prévu avec le init qui retourne un instancetype on ne peut pas l'appeler avant. Et du coup faut être extra careful justement pour tous les effets de bord.
Donc déjà oui il faut utiliser les ivar dans les init, et les setters/getters dans le reste du code. Sauf que si dans ton init tu appelles une autre méthode parce que tu as du code commun à exécuter... et que cette méthode elle appelle une autre méthode qui... au final utilise le setter, bah tu as fini par appeler du KVC pour dans le init si tu fais pas gaffe. Mais y'a bien plus que ça, comme les valeurs non encore initialisées ou les init croisés quand certains sont overridés et pas d'autres. Ils parlent de 2-3 cas comme ça d'ailleurs dans les confs, même s'il en existe quelques autres aussi alambiqués. Bref y'a de quoi faire pour se faire avoir, même si t'es expérimenté et même si tu utilises des ivar dans ton init.
Et en passant avec Swift impossible d'avoir le problème puisqu'il impose l'ordre d'appel, qu'il empêche le KVO, qu'il impose que toutes les ivars soient initialisées, et qui fait ainsi tout ce qu'il faut pour éviter de tomber dans tous les ecueils possibles qu'ObjC permet, même aux plus expérimentés.
Je pense surtout que Yoann veut dire également que Swift n'apporte pas assez de nouveautés par rapport aux problèmes d'intégration qu'il peut susciter sur une app existante. Il faudra vraiment peser le pour et le contre avant de migrer son code.
Mon app fait 55k de code, et il faut vraiment être motivé pour se lancer dans une migration, même dans quelques mois quand Swift sera plus stable et mûr.
Pour les nouveaux projets, c'est différent, on peut partir de zéro: mais on ne fait pas des nouveaux projets sans arrêt (sauf si on est prestataire, et pas éditeur).
Bah surtout il n'y a strictement rien qui justifie de casser les couilles avec un nouveau langage. Les trois conneries apportés auraient pu l'être dans ObjC, évitant ainsi de perdre des dizaines d'années de code. Car, que vous le vouliez ou non, si Swift est l'avenir, il faudra impérativement tout réécrire un jour où l'autre. Quand on voit le temps que ça a pris pour Carbon dont on sort à peine plus de dix ans après...
C'est vraiment un mauvais signal et une mauvaise stratégie pour moi au moment où l'environnement s'étend comme pas possible. Remettre à zéro l'historique des savoirs et des codes existants pour une lubie de pseudo performance de l'équipe LLVM et de sécurité pour prendre par la main les développeur, c'est con. Renforcer ObjC comme ils l'ont fait avec clang static analyzer et avec ARC aurait été bien plus intelligent.
J'espère qu'Apple n'interdira pas de publier des apps ou des maj d'apps en Obj-C sur l'AppStore dans 3 ou 5 ans...
C'est pas ce que je dis exactement.
Je dis que même dans 2 ans, ça n'aura sûrement pas plus d'intérêt.
Et puis faut avoir envie de faire du neuf pour trouver un intérêt !
Vu tout ce qui a été dit ici, je vais surseoir un certain temps à l'utilisation de Swift. J'ai commencé à lire, et cela va probablement vous sembler curieux, j'ai l'impression de trouver des petits bouts de Pascal, de Basic et même d'AppleScipt Studio. Dit autrement, je n'arrive pas à en saisir clairement la philosophie.
Moi aussi je suis d'accord !
Mais était-ce possible techniquement sur la base du C ?
Tiens, j'ai une question (bête ?) : est-ce que ce serait plus facile de porter du Swift vers Java ou bien du Objective-C vers Java ?
Certes, la syntaxe pointée peut faciliter la chose, mais ça ne fait pas tout... Il y a tous les autres concepts.
Pour ma part, je trouverais ça super qu'ils autorisent la notation [myObject myMethodWithArg1: with Arg2:] en swift.
Je ne vois pas pourquoi les outils de "développement" (pour être plus générique, je dirais "génie logiciel") ne devraient pas évoluer vers plus de simplicité. C'est même une nécessité vu la complexité croissante des développements.
Sans vouloir faire du mauvais esprit ni remettre en cause tes compétences en développement, en tant qu'admin sys. (ce qui est me semble-t-il ta principale activité), tu n'as sans doute jamais été confronté à des projets logiciels ultra complexes de plusieurs millions de lignes de code, ni travaillé avec des dizaines de personnes sur les mêmes sources. Dans ces conditions, les évolutions des langages, notamment au niveau de la gestion mémoire et du typage fort, sont une nécessité pour que les phases de développement et mise au point ne fassent pas exploser les budgets.
Moi aussi j'ai commencé par l'ASM. Moi aussi j'ai ensuite fait du C. D'ailleurs pourquoi ? Puisque finalement en ASM on fait mieux qu'en C. Simplement parce que l'augmentation de la complexité nécessite des outils plus évolués. Beaucoup de softs critiques sont écrits depuis bien longtemps en langages fortement typés, notamment ADA (Thales, Airbus, etc...).
Ce n'est pas le langage qui fait un bon ou un mauvais developpeur. C'est sa capacité à créer et mettre en oeuvre des algorithmes de plus en plus complexes. S'affranchir des "détails" (après tout je conduis une voiture sans savoir comment l'injection électronique fonctionne) permet d'être plus performant.
Après, je ne dis pas non plus que Swift est parfait, surtout en ce qui concerne l'interopérabilité avec les frameworks existants. Loin de là . Mais ça évoluera.
Genre :
Oui bien sûr.
On pourrait imaginer qu'Apple offre la possibilité des deux syntaxes
pourrait aussi s'écrire
Je ne dis pas que ce ne doit pas évoluer, mais que ça doit évoluer dans le bon sens. La simplicité et l'efficacité oui, l'infantilisation, non. Et il est quand même nécessaire de rappeler sur quelle plateforme on est... iOS voire OS X, ce n'est pas un A380 !
Faire chier pour passer du typage faible au typage fort, je trouve ça con. ça fait des années que des soft somme toute complexe autour de la vidéo, du son ou des sciences sont fait sous Mac avec l'existant et ça fonctionne.
Balancer Swift pour palier au manque de rigueur d'un petit subset de dev, c'est juste déprimant.
Je suis d'accord ça ne changera presque rien pour la plupart des dev une fois cette syntaxe dégueulasse apprise et quelques années de stabilisation du langage passé. Presque rien hormis la perte du KVO et des bindings qui sont obligatoire pour toute application lourde sous Mac et la perte de toute l'historique de code existant.
Vu la cote des produits Apple aujourd'hui, on a franchement pas besoin d'un truc de merde au milieu qu'il va falloir déboguer en plus du reste. Les conneries de blur et de sandbox suffisent largement à ralentir et limiter l'activité de tout le monde...
Les paris sont ouverts. Moi je dis 3 ans pas plus.
J'ai jamais aimé les langages à typage faible (c'est un des plus gros reproches que je ferais à des langages comme Ruby par exemple, malgré tout l'amour que je lui porte, bien qu'étant un langage de scripting il a une excuse).
Je viens de lire tous vos messages, d'ailleurs je trouve ce post vraiment intéressant !! Là ou je rejoins AliGator et Yoann (et oui, on peut être d'accord avec les deux :-p ) c'est qu'il faut que les nouveaux développeurs (un peu comme moi, seulement 4 ans d'xp -> Encore un peu jeune par rapport à vous, et encore bcp de chose à apprendre ;-) ) s'intéressent un peu plus au fonctionnement du language utilisée !
Même si vous avez quelque divergence sur l'utilisation de Swift, je pense que la leçon principale c'est celle là : Quelque que soit le langage utilisée dans les applications iOS ou OSX (et autre), le développeur doit absolument savoir ce qu'il fait et doit être capable de justifier chaque ligne de code (Dans la pratique c'est moins vrai, on est d'accord ^^)
Sur Swift, je serais plus pour AliGator dans le sens où, j'ai commencé iOS sans ARC et l'analogie entre l'évolution de ARC et l'apparition de Swift est bonne je pense. Je suis sûr que bcp de monde vont critiquer Swift (je peux le faire aussi, mais c'est un peu tôt je trouve car ce n'est pas une beta mais une ALPHA) mais je pense que dans 2 ou 3 ans, la plus part des personnes auront adoptés Swift et on aura une keynote Apple disant -> "Tant de % de nouveaux développeurs cette année grâce à Swift et tant de % d'ancien développeurs ont migré vers Swift" avec des nombres pharaonique :-)
Mais comme je conseille souvent aux nouveaux développeurs (sur iOS en tout cas) -> "Commencez sans les outils comme ARC et avec objective c pour bien comprendre le fonctionnement et après commencez à regarder comment on utilise les outils". Je fais de même avec la programmation des IHM "Commencez avec la programmation pure et après utilisez les .xib et les .storyboard", on remarque après que les développeurs savent déjà qu'elle option choisir pour les Outlets et ils ont simplement à savoir où là cocher, c'est plus sympa que de cocher à tout va pour avoir l'effet désiré :-p
Non, je ne pense pas. Ca n'a aucun intérêt pour Apple, hormis se mettre à dos les développeurs qui ont déjà des centaines de milliers de lignes de code en ObjC qu'ils n'ont pas le temps ni l'envie de porter en Swift. Même en interne, je doute qu'ils réécrivent Cocoa/CocoaTouch en swift.
Par contre il est évident qu' ObjC n'évoluera plus.