Joanna : Ouais en même temps j'ai de lointaines origines irlandaises (1600 et quelques), j'ai une belle soe“ur et des nièces irlandaises, je suis fan de séries anglaises, et en particulier de Sherlock et Doctor Who... comment pourrais-je ne pas boire du thé ?!
Draken : mais non t'as rien compris, il me faut juste une tasse 16x plus grande, comme dans le film, c'est tout ;-)
Je n'ai pas vu le film ! Par contre j'ai un frère qui prend un peu de steak avec sa moutarde. A tel point que je lui ai offert un seau de 25 kg de moutarde à un anniversaire (modèle industriel acheté chez un grossiste pour restaurateur).
Je bois aussi du thé! Un de mes meilleurs amis est natif de la région de Hull (le coin d'Angleterre qui est tellement humide qu'on n'y met jamais le linge à sécher dehors! c'est lui qui le dit.) Il m'a appris à apprécier le bon whisky et le thé. J'ai essayé le mélange, mais ce n'est pas fameux!
Donc, thé très fort et sucré ou whisky nature sans glace et sans eau. Non Draken, pas de bulles!
Je vais casser un peu l'ambiance mais du coup, quels sont ceux parmi vous qui vont développer leurs prochaines applications sur Swift ? Ou bien vous comptez attendre quelques années avant d'envisager à développer avec Swift, le temps que ça devienne stable ?
J'aimerais bien connaà®tre la stratégie des agences de développement mobiles. Vont-ils se mettre le plus vite possible sur Swift ou patienter ?
Nous avons un app qui dépende sur un "engin de calcul" qui est, actuellement, écrit en Free Pascal comme lib statique.
Depuis 18 mois, nous avons écrit le plupart du code UI en Objective-C et nous n'anticipons pas le réécrire seulement parce que Swift est "sexy".
En revanche, l'engin de calcul a été "ported" (importé ?) d'un app Delphi pour Windows et le code est bien loin d'être "beau" avec tous ses variables globales, le tableaux statiques, beaucoup de drapeaux conditionnels, etc. et ça nous prévoyons réécrire totalement neuf en Swift.
Puis, nous anticipons adopter, après la sortie officielle de Swift, de l'utiliser de plus en plus.
Pour l'instant, j'ai voulu simplement recoder une application que je donne comme exercice dans ma formation au développement Cocoa Touch en Swift. Je connais l'exercice presque par coe“ur, et la seule difficulté est le nouveau langage. J'ai bien sûr un peu buté sur les optionals, mais le gros problème, c'est cette foutue auto-complétion de Xcode qui ne me suggère rien en rapport avec ce que je cherche, et qui m'empêche de taper ce que je veux vraiment écrire. Alors, déjà , l'outil n'est pas encore prêt. Toutefois, ça peut s'arranger d'ici septembre.
Ensuite, il y a encore plein de petits problèmes de fonctionnement du bridge Objective-C. ça va foutre plus ou moins la zone selon le code ou le projet, mais pendant quelques mois, on va souvent se demander si ça ne marche pas à cause du bridge, et donc parfois réécrire son code Swift en Objective-C pour en être sûr. Dans un contexte professionnel où les temps de dev sont serrés, on va préférer Objective-C...
Enfin, ce n'est pas une solution tout ou rien. Il y a des cas où Swift va apporter une réelle plus-value, je pense notamment au code asynchrone. Et d'autres ou Objective-C restera plus adapté, notamment tout ce qui concerne Foundation.
Dans tous les cas, une société a besoin de travailler avec des outils fiables, et avant un bon moment, ce ne sera pas le cas.
Enfin, il faut former les gens, alors tout le monde ne va pas basculer à Swift du jour au lendemain, parce que c'est l'avenir. Il faut déjà assurer le présent.
Joanna : Ouais en même temps j'ai de lointaines origines irlandaises (1600 et quelques), j'ai une belle soe“ur et des nièces irlandaises, je suis fan de séries anglaises, et en particulier de Sherlock et Doctor Who... comment pourrais-je ne pas boire du thé ?!
Intéressant. Je viens de découvrir (il y a quelques mois) que le nom de jeune fille de ma mère est Trigance, qui est lié au village de Trigance dans le Var. Ses ancêtres travaillaient en la fonderie (en faisant les cloches, etc) et ils sont arrivés en Angleterre par l'isle de Malte pendant la première moitié du XIX siècle.
Je vais casser un peu l'ambiance mais du coup, quels sont ceux parmi vous qui vont développer leurs prochaines applications sur Swift ? Ou bien vous comptez attendre quelques années avant d'envisager à développer avec Swift, le temps que ça devienne stable ?
J'aimerais bien connaà®tre la stratégie des agences de développement mobiles. Vont-ils se mettre le plus vite possible sur Swift ou patienter ?
Mes apps en Swift ce n'est pas pour tout de suite. Mais je m'y intéresse, je joue avec les playground, je regarde la documentation, etc. Mais quand Swift sera stable, je pense que je m'y mettrais oui.
Mon grand-père maternel est le fils illégitime d'un homme politique au sang bleu, du début du XXe siècle, qui courais après les jolies domestiques à 60 ans. Et mon père, le fils illégitime d'un ouvrier musulman et d'une femme mariée d'origine belge/allemande. Les gènes n'ont souvent rien à voir avec les noms de famille.
J'ai déjà essayé de commencer une application test avec Xcode 6 beta 4 en Swift, j'ai abandonné tellement Xcode était instable avec Swift... De plus les unwind segue ne sont pas encore reconnu et n'utilisant que ça pour effectuer un retour vers une autre vue, c'est vite gênant.
Pour apprendre davantage Swift je me suis également mis sur une application à partir de 0 mais je me demandais quelle été la réelle plus-value aujourd'hui de s'y mettre quand on sait le temps qu'il faut pour bien maà®triser un langage.
À un peu plus de 24h de la prochaine Keynote qui devrait annoncer le départ officiel de Swift et au bout d'un peu près 2 mois de joujous dessus, pour ceux qui ont testé, vous en pensez quoi ?
Devrais-je y jeter un oe“il (pour ma culture, parce qu'on ne sait jamais si cela pourrait s'avérer utile), ou m'y intéresser un peu plus quand même ? Notez, que je ne compte pas lâcher mes crochets adorés, alors bon
De mon point de vue externe en traà®nant sur StackOverflow, je remarque que, au moins dans le sens où on veut faire de l'iOS/Mac OSX, avoir des bases en Objective-C, rien que sur la syntaxe de cette dernière est un grand plus.
Parce qu'au final, Swift, c'est quand même à utiliser avec Cocoa(Touch), et quand je vois les questions sur SO de personnes qui demandent comment faire tel ou tel truc, alors que cela a déjà été posé au moins 1024 fois sur SO en version Objective-C, et qu'il suffirait juste de traduire, c'est un grand atout de pouvoir lire de l'Objective-C.
Donc là , mon plus grand conseil aux nouveaux développeur Swift serait de pouvoir lire de l'Objective-C.
Pour moi avec la sortie imminente de Xcode6 GM Swift va commencer à être utilisable, ça peut donc valoir le coup de commencer a s'y mettre.
En tout cas s'y intéresser, pour être au courant de la syntaxe et des possibilités qu'il offre. Choses que je présenterai d'ailleurs au prochain CocoaHeads Rennes #pub
Après, il faudra de toute façon toujours continuer à utiliser Objective-C et les applications en pur Swift sans ObjC ce n'est pas pour demain, vu que toutes les API Cocoa existantes ainsi que la plupart des composants externes sont encore en Objective-C.
Mais en tout cas pour ta culture c'est toujours intéressant de commencer à t'y mettre maintenant que c'est + stable et déjà + figé qu'au début. Ca à le temps de changer un peu sur des petits détails d'ici à l'adoption grande échelle dans un an mais ça devrait être mineur.
ma première réaction a été de comparer cela à une sorte de remise à zero, un peu comme une dévaluation brutale des développeurs Objective-C, mais j'ai fini par me dire que l'on peu penser un peu le contraire dans le sens où les nouveaux entrants risquent de faire l'impasse sur Objective-C et avoir un backgroud Objective-C gardera probablement une certaine valeur.
Quand c'est passé de NeXT à Apple le gros inconvénient était que l'on est passé d'un environnement où l'on faisait tout en Objective-C (même les drivers) à un autre ou il fallait se tapper "Carbon" pour accéder à certaines fonctionnalités, ce qui était loins d'être évident et surtout pas motivant (puis que c'était voué à disparaitre).
Par contre quand WebObjects est passé à Java, du fait que les API n'avaient pas changé, c'était bien plus simple, quoique quand on aime le crochet (et les langages faiblement typés) Java ca n'était pas très attirant et ceux qui s'y sont mis "franchement" en on profité pour changer de Frameworks, pour aller où les offres d'emploi étaient bien plus nombreuses...
Quand Microsoft est passé de C++/MFC/Win32 et VB6 à .NET / Winforms, le langage C# est sorti en même temps qu'une première version assez complète des APIs .NET. On pouvait donc s'y mettre tout de suite sauf que les applis produites étaient beaucoup plus lentes qu'en C++.
Chaque transition est différente avec ses avantages et inconvénients.
J'ai l'impression que la faiblesse de la transition vers swift réside dans le fait de devoir s'interfacer avec les "anciennes" library cocoa via des objects AnyObject?.
Autrement dit de ne pas avoir de library swift qui pourrait tirer parti des spécificités du langage.
J'ai l'impression que la faiblesse de la transition vers swift réside dans le fait de devoir s'interfacer avec les "anciennes" library cocoa via des objects AnyObject?.
Heu ?
Les APIs Cocoa écrites à la base en Objective-C sont automatiquement traduites en Swift (suffit de regarder la doc Swift de toutes les classes du framework Cocoa), avec un type-casting automatique. Le seul drawback c'est que tout est en implicitly-unwrapped-optional, ce qui est logique puisque les NSObject* en Objective-C peuvent être nil, mais il n'y a pas à les unwrapper explicitement pour avoir leur valeur. Alors qu'en Swift tout objet est forcément non-nil s'il n'est pas wrappé dans un Optional, et si on veut sa valeur il faut l'unwrapper (ce qui permet d'avoir des Bool? et des Int? etc, ce qu'ObjC ne permet pas), mais du coup faut avoir compris le principe et les risques d'utilisation d'un implicitly-unwrapped-optional (en particulier ne pas l'utiliser sans avoir testé s'il n'était pas nil auparavant)
Mais sinon, là où en Objective-C l'API attend une NSString, en Swift elle attend une String!. Là où l'API ObjC attend un NSArray (tableau qui, en ObjC, peut contenir n'importe quel type d'objet), l'API Swift attend un Array<AnyObject!>. De même là où ObjC attend un NSDictionary, Swift attend un [Hashable:AnyObject]. Là où l'API ObjC attend un int, l'API Swift attend un Int. etc, etc.
Bref, normalement toute l'API ObjC est traduite à la volée dans les types correspondants Swift s'ils existent. Y'a pas besoin de remplacer tout en "AnyObject?" partout, les types peuvent rester assez explicites et proches des types correspondants attendus dans l'autre langage.
Justement AliGator il est là le problème soulevé par FKDEV.
En Objective-C, il n'y a aucune contrainte à travailler avec des NAArray ou des NSDictionary non typés.
Mais en Swift, avec la puissance du typage, se retrouver à manipuler des Array<AnyObject!> plutôt que des Array<UIView> c'est un bon en arrière dans le langage.
Par exemple la classe UIView, possède un méthode "subviews", on sait très bien que cette méthode ne contient que des UIView non nil, alors pourquoi s'embêter avec des Array<AnyObject!> ? Alors oui c'est la traduction automatique, mais ils pourraient faire en sorte d'améliorer tout ça, pour qu'on puisse enfin profiter de toute la puissance de Swift, même avec les api de cocoa.
Par exemple la classe UIView, possède un méthode "subviews", on sait très bien que cette méthode ne contient que des UIView non nil, alors pourquoi s'embêter avec des Array<AnyObject!> ? Alors oui c'est la traduction automatique, mais ils pourraient faire en sorte d'améliorer tout ça, pour qu'on puisse enfin profiter de toute la puissance de Swift, même avec les api de cocoa.
Bah heu c'est prévu, un peu de patience !
Certaines APIs ont déjà été spécialisées, avec une adaptation des types Swift pour mieux coller à la réalité, mais ils ont pas encore eu le temps de traduire les centaines de milliers de classes de tous les frameworks Cocoa, faut être patient ^^
Comme on a déjà dit et répété, Swift est très jeune encore (il n'a, aux yeux du grand public, que 2 mois, et encore en phase Beta), et Apple lui-même annonce sur son blog qu'ils font l'améliorer (stabilisation de l'ABI, conversion des APIs Cocoa, ...) dans l'année qui va venir.
Il est important de ne pas se voiler la face et de reconnaà®tre où sont les faiblesses potentielles pour décider si cela vaut le coup d'y aller ou pas dès maintenant.
Pour quelqu'un qui aime et qui y passe ses nuits, la question ne se pose pas, et tant mieux.
J'ai lu l'eBook sur swift et j'ai trouvé ça bien dans l'ensemble, similaire à C# mais en plus concis.
Mais dès que je vois un exemple réel en lien avec cocoa touch, je trouve ça moche. C'est peutetre juste un manque de pratique.
Oui clairement actuellement Swift étant toujours à ses débuts (y compris en terme de librairies tierces dispos sur le net et du au fait que les APIs Cocoa ne sont pas encore adaptées au mieux au cas par cas) c'est pour l'instant je dirais plutôt expérimental : maintenant ça marche bien mais faut avoir en tête que c'est un bébé tout nouveau né. Si vous êtes curieux et voulez expérimenter avec des nouveaux langages ou profiter des concepts qu'apporte Swift que ObjC n'a pas, genre que vous êtes touche-à -tout, alors foncez.
Si vous avez des contraintes temps ou qualité sur un projet alors c'est encore trop tôt (non que Swift ne soit pas gage de qualité mais le manque de libs et de sujets et docs sur le net à son sujet par rapport à ObjC vous ferait perdre du temps ce qu'on ne peut pas se permettre sur un projet industriel avec planning fixe, surtout si vous avez un bug, le temps de comprendre pourquoi comme en Swift on manque encore d'expérience et de retours sur les bugs classiques ou les questions SO, vous allez passer + de temps ou alors être moins carres sur la qualité au final que si vous aviez quartier libre sur le planning)
Pour moi pour l'instant je vois ça comme du fun, le plaisir d'apprendre un nouveau langage et mon petit plaisir d'architecte logiciel d'imaginer des nouvelles API et architectures de composants et de systèmes qui profitent des nouveaux concepts de Swift. Mais je fais ça en mode curieux façon "chercheur". Pour les applis des clients, pour lesquelles il y a un planning serré et où utiliser des technos et langages qu'on maà®trise déjà permet d'aller plus vite, je vais attendre facile 6 mois avant de mettre du Swift dedans je pense, le temps que ça s'étoffe sur le net et que je maitrise Swift de mon côté.
Réponses
Draken : mais non t'as rien compris, il me faut juste une tasse 16x plus grande, comme dans le film, c'est tout ;-)
Je bois aussi du thé! Un de mes meilleurs amis est natif de la région de Hull (le coin d'Angleterre qui est tellement humide qu'on n'y met jamais le linge à sécher dehors! c'est lui qui le dit.) Il m'a appris à apprécier le bon whisky et le thé. J'ai essayé le mélange, mais ce n'est pas fameux!
Donc, thé très fort et sucré ou whisky nature sans glace et sans eau. Non Draken, pas de bulles!
Vous êtes le pape qui attend sa soe“ur ?
C'est la base de l'humour ce film !
C'est même une référence incontournable.
Je vais casser un peu l'ambiance mais du coup, quels sont ceux parmi vous qui vont développer leurs prochaines applications sur Swift ? Ou bien vous comptez attendre quelques années avant d'envisager à développer avec Swift, le temps que ça devienne stable ?
J'aimerais bien connaà®tre la stratégie des agences de développement mobiles. Vont-ils se mettre le plus vite possible sur Swift ou patienter ?
Nous avons un app qui dépende sur un "engin de calcul" qui est, actuellement, écrit en Free Pascal comme lib statique.
Depuis 18 mois, nous avons écrit le plupart du code UI en Objective-C et nous n'anticipons pas le réécrire seulement parce que Swift est "sexy".
En revanche, l'engin de calcul a été "ported" (importé ?) d'un app Delphi pour Windows et le code est bien loin d'être "beau" avec tous ses variables globales, le tableaux statiques, beaucoup de drapeaux conditionnels, etc. et ça nous prévoyons réécrire totalement neuf en Swift.
Puis, nous anticipons adopter, après la sortie officielle de Swift, de l'utiliser de plus en plus.
Pour l'instant, j'ai voulu simplement recoder une application que je donne comme exercice dans ma formation au développement Cocoa Touch en Swift. Je connais l'exercice presque par coe“ur, et la seule difficulté est le nouveau langage. J'ai bien sûr un peu buté sur les optionals, mais le gros problème, c'est cette foutue auto-complétion de Xcode qui ne me suggère rien en rapport avec ce que je cherche, et qui m'empêche de taper ce que je veux vraiment écrire. Alors, déjà , l'outil n'est pas encore prêt. Toutefois, ça peut s'arranger d'ici septembre.
Ensuite, il y a encore plein de petits problèmes de fonctionnement du bridge Objective-C. ça va foutre plus ou moins la zone selon le code ou le projet, mais pendant quelques mois, on va souvent se demander si ça ne marche pas à cause du bridge, et donc parfois réécrire son code Swift en Objective-C pour en être sûr. Dans un contexte professionnel où les temps de dev sont serrés, on va préférer Objective-C...
Enfin, ce n'est pas une solution tout ou rien. Il y a des cas où Swift va apporter une réelle plus-value, je pense notamment au code asynchrone. Et d'autres ou Objective-C restera plus adapté, notamment tout ce qui concerne Foundation.
Dans tous les cas, une société a besoin de travailler avec des outils fiables, et avant un bon moment, ce ne sera pas le cas.
Enfin, il faut former les gens, alors tout le monde ne va pas basculer à Swift du jour au lendemain, parce que c'est l'avenir. Il faut déjà assurer le présent.
Intéressant. Je viens de découvrir (il y a quelques mois) que le nom de jeune fille de ma mère est Trigance, qui est lié au village de Trigance dans le Var. Ses ancêtres travaillaient en la fonderie (en faisant les cloches, etc) et ils sont arrivés en Angleterre par l'isle de Malte pendant la première moitié du XIX siècle.
Mes apps en Swift ce n'est pas pour tout de suite. Mais je m'y intéresse, je joue avec les playground, je regarde la documentation, etc. Mais quand Swift sera stable, je pense que je m'y mettrais oui.
J'ai déjà essayé de commencer une application test avec Xcode 6 beta 4 en Swift, j'ai abandonné tellement Xcode était instable avec Swift... De plus les unwind segue ne sont pas encore reconnu et n'utilisant que ça pour effectuer un retour vers une autre vue, c'est vite gênant.
Ok. Merci pour ces retours.
Pour apprendre davantage Swift je me suis également mis sur une application à partir de 0 mais je me demandais quelle été la réelle plus-value aujourd'hui de s'y mettre quand on sait le temps qu'il faut pour bien maà®triser un langage.
Je viens de combiner les 2 sujets principaux sur Swift dans celui-ci, plus généraliste, où l'on donne son point de vue et l'on expose les avancées.
Je viens à la pêche aux infos...
À un peu plus de 24h de la prochaine Keynote qui devrait annoncer le départ officiel de Swift et au bout d'un peu près 2 mois de joujous dessus, pour ceux qui ont testé, vous en pensez quoi ?
Devrais-je y jeter un oe“il (pour ma culture, parce qu'on ne sait jamais si cela pourrait s'avérer utile), ou m'y intéresser un peu plus quand même ? Notez, que je ne compte pas lâcher mes crochets adorés, alors bon
De mon point de vue externe en traà®nant sur StackOverflow, je remarque que, au moins dans le sens où on veut faire de l'iOS/Mac OSX, avoir des bases en Objective-C, rien que sur la syntaxe de cette dernière est un grand plus.
Parce qu'au final, Swift, c'est quand même à utiliser avec Cocoa(Touch), et quand je vois les questions sur SO de personnes qui demandent comment faire tel ou tel truc, alors que cela a déjà été posé au moins 1024 fois sur SO en version Objective-C, et qu'il suffirait juste de traduire, c'est un grand atout de pouvoir lire de l'Objective-C.
Donc là , mon plus grand conseil aux nouveaux développeur Swift serait de pouvoir lire de l'Objective-C.
Mais est-ce un mauvaise conjoncture ?
En tout cas s'y intéresser, pour être au courant de la syntaxe et des possibilités qu'il offre. Choses que je présenterai d'ailleurs au prochain CocoaHeads Rennes #pub
Après, il faudra de toute façon toujours continuer à utiliser Objective-C et les applications en pur Swift sans ObjC ce n'est pas pour demain, vu que toutes les API Cocoa existantes ainsi que la plupart des composants externes sont encore en Objective-C.
Mais en tout cas pour ta culture c'est toujours intéressant de commencer à t'y mettre maintenant que c'est + stable et déjà + figé qu'au début. Ca à le temps de changer un peu sur des petits détails d'ici à l'adoption grande échelle dans un an mais ça devrait être mineur.
ma première réaction a été de comparer cela à une sorte de remise à zero, un peu comme une dévaluation brutale des développeurs Objective-C, mais j'ai fini par me dire que l'on peu penser un peu le contraire dans le sens où les nouveaux entrants risquent de faire l'impasse sur Objective-C et avoir un backgroud Objective-C gardera probablement une certaine valeur.
Quand c'est passé de NeXT à Apple le gros inconvénient était que l'on est passé d'un environnement où l'on faisait tout en Objective-C (même les drivers) à un autre ou il fallait se tapper "Carbon" pour accéder à certaines fonctionnalités, ce qui était loins d'être évident et surtout pas motivant (puis que c'était voué à disparaitre).
Par contre quand WebObjects est passé à Java, du fait que les API n'avaient pas changé, c'était bien plus simple, quoique quand on aime le crochet (et les langages faiblement typés) Java ca n'était pas très attirant et ceux qui s'y sont mis "franchement" en on profité pour changer de Frameworks, pour aller où les offres d'emploi étaient bien plus nombreuses...
Quand Microsoft est passé de C++/MFC/Win32 et VB6 à .NET / Winforms, le langage C# est sorti en même temps qu'une première version assez complète des APIs .NET. On pouvait donc s'y mettre tout de suite sauf que les applis produites étaient beaucoup plus lentes qu'en C++.
Chaque transition est différente avec ses avantages et inconvénients.
J'ai l'impression que la faiblesse de la transition vers swift réside dans le fait de devoir s'interfacer avec les "anciennes" library cocoa via des objects AnyObject?.
Autrement dit de ne pas avoir de library swift qui pourrait tirer parti des spécificités du langage.
Les APIs Cocoa écrites à la base en Objective-C sont automatiquement traduites en Swift (suffit de regarder la doc Swift de toutes les classes du framework Cocoa), avec un type-casting automatique.
Le seul drawback c'est que tout est en implicitly-unwrapped-optional, ce qui est logique puisque les NSObject* en Objective-C peuvent être nil, mais il n'y a pas à les unwrapper explicitement pour avoir leur valeur. Alors qu'en Swift tout objet est forcément non-nil s'il n'est pas wrappé dans un Optional, et si on veut sa valeur il faut l'unwrapper (ce qui permet d'avoir des Bool? et des Int? etc, ce qu'ObjC ne permet pas), mais du coup faut avoir compris le principe et les risques d'utilisation d'un implicitly-unwrapped-optional (en particulier ne pas l'utiliser sans avoir testé s'il n'était pas nil auparavant)
Mais sinon, là où en Objective-C l'API attend une NSString, en Swift elle attend une String!.
Là où l'API ObjC attend un NSArray (tableau qui, en ObjC, peut contenir n'importe quel type d'objet), l'API Swift attend un Array<AnyObject!>. De même là où ObjC attend un NSDictionary, Swift attend un [Hashable:AnyObject].
Là où l'API ObjC attend un int, l'API Swift attend un Int.
etc, etc.
Bref, normalement toute l'API ObjC est traduite à la volée dans les types correspondants Swift s'ils existent. Y'a pas besoin de remplacer tout en "AnyObject?" partout, les types peuvent rester assez explicites et proches des types correspondants attendus dans l'autre langage.
Justement AliGator il est là le problème soulevé par FKDEV.
En Objective-C, il n'y a aucune contrainte à travailler avec des NAArray ou des NSDictionary non typés.
Mais en Swift, avec la puissance du typage, se retrouver à manipuler des Array<AnyObject!> plutôt que des Array<UIView> c'est un bon en arrière dans le langage.
Par exemple la classe UIView, possède un méthode "subviews", on sait très bien que cette méthode ne contient que des UIView non nil, alors pourquoi s'embêter avec des Array<AnyObject!> ? Alors oui c'est la traduction automatique, mais ils pourraient faire en sorte d'améliorer tout ça, pour qu'on puisse enfin profiter de toute la puissance de Swift, même avec les api de cocoa.
Certaines APIs ont déjà été spécialisées, avec une adaptation des types Swift pour mieux coller à la réalité, mais ils ont pas encore eu le temps de traduire les centaines de milliers de classes de tous les frameworks Cocoa, faut être patient ^^
Comme on a déjà dit et répété, Swift est très jeune encore (il n'a, aux yeux du grand public, que 2 mois, et encore en phase Beta), et Apple lui-même annonce sur son blog qu'ils font l'améliorer (stabilisation de l'ABI, conversion des APIs Cocoa, ...) dans l'année qui va venir.
Je suis d'accord, mais c'était juste pour appuyer ce que dit FKDev.
Certes c'est amener à évoluer, mais pour l'instant faut faire avec.
Pour quelqu'un qui aime et qui y passe ses nuits, la question ne se pose pas, et tant mieux.
J'ai lu l'eBook sur swift et j'ai trouvé ça bien dans l'ensemble, similaire à C# mais en plus concis.
Mais dès que je vois un exemple réel en lien avec cocoa touch, je trouve ça moche. C'est peutetre juste un manque de pratique.
Si vous avez des contraintes temps ou qualité sur un projet alors c'est encore trop tôt (non que Swift ne soit pas gage de qualité mais le manque de libs et de sujets et docs sur le net à son sujet par rapport à ObjC vous ferait perdre du temps ce qu'on ne peut pas se permettre sur un projet industriel avec planning fixe, surtout si vous avez un bug, le temps de comprendre pourquoi comme en Swift on manque encore d'expérience et de retours sur les bugs classiques ou les questions SO, vous allez passer + de temps ou alors être moins carres sur la qualité au final que si vous aviez quartier libre sur le planning)
Pour moi pour l'instant je vois ça comme du fun, le plaisir d'apprendre un nouveau langage et mon petit plaisir d'architecte logiciel d'imaginer des nouvelles API et architectures de composants et de systèmes qui profitent des nouveaux concepts de Swift. Mais je fais ça en mode curieux façon "chercheur". Pour les applis des clients, pour lesquelles il y a un planning serré et où utiliser des technos et langages qu'on maà®trise déjà permet d'aller plus vite, je vais attendre facile 6 mois avant de mettre du Swift dedans je pense, le temps que ça s'étoffe sur le net et que je maitrise Swift de mon côté.