Langage Swift : une version 3.0 presque terminée et un modèle open source qui fonctionne
Brouhaha, brouhaha, brouhaha
Le 01 août 2016 à 14h30
4 min
Logiciel
Logiciel
Apple approche de la version 3.0 de son langage Swift, l’occasion pour l’éditeur de faire le point sur les avancées et l’impact du modèle open source mis en place l’année dernière. Il aborde également les évolutions prévues pour la version 4.0, prévue pour l’année prochaine.
Swift est le langage qui a pris le relai chez Apple de l’Objective-C, même si ce dernier est toujours supporté. Il rencontre un vrai succès, et pour s’assurer que cette courbe continuerait à grimper, Apple a choisi de rendre son produit open source l’année dernière, à l’occasion de la sortie de Swift 2.0. Depuis, la troisième mouture majeure est en développement et doit arriver en même temps qu’iOS 10 et macOS Sierra cet automne.
Une bascule open source positive, avec quelques difficultés
Chris Lattner, en charge chez Apple des outils de développement, indique que le passage à l’open source a été profitable, en dépit d’un certain nombre de soucis. Selon lui, ce modèle prend plus de temps et est moins prévisible, sans doute parce que le nombre d’avis à prendre en compte est nettement supérieur. Swift 3.0 comptait ainsi une liste précise de fonctionnalités prévues, mais certaines ont dû être repoussées.
Même s’il est « impossible de rendre tout le monde heureux », il se félicite par contre d’une communauté si « pleine de vie », avec un bilan positif donc. Il faudra donc pour le responsable renforcer à l'avenir la communication, la transparence dans les décisions et le respect de certains limites temporelles.
Swift 3.0 sera une aussi grande cassure que la version 2.0
Swift 3.0 comportera un grand nombre de changements, dont beaucoup sont incompatibles avec le code utilisé actuellement. En clair, il y a de grandes chances que les applications ne puissent pas être compilées sans que les changements nécessaires aient été faits. Par exemple, tous les paramètres de fonctions comportent des labels, à moins que le développeur ne spécifie explicitement que ce n’est pas le cas.
Autre changement important, le retrait des mots inutiles dans le code. Par exemple, UIColor.blueColor devient simplement UIColor.blue, numbers.minElement devient numbers.min, attributedString.appendAttributedString devient attributedString.append et ainsi de suite. L’importation du code rédigé en C permet en outre de définir des attributs pour les fonctions, simplifiant le travail du développeur. Ainsi, toutes les fonctions débutant par CGContext sont réorientées vers les méthodes d’un objet CGContext.
Swift 4.0 renforcera avant tout la stabilité
L’année prochaine, également en automne, sortiront les versions 3.1 et 4.0. Comme on s’en doute, la mouture 3.1 sera une évolution de la 3.0 – sans cassure dans la compatibilité – tandis que Swift 4.0 introduira des changements plus profonds. L’objectif principal sera une hausse de la stabilité pour le code open source et l’ABI (Application Binary Interface). Ce travail sera prioritaire, excluant d’office toutes les fonctions supplémentaires, pour se concentrer sur celles qui pourraient modifier le fonctionnement de l’ABI. Une réflexion sur l’utilisation de la mémoire est également prévue, pour rendre Swift plus adapté à des cas particuliers, comme du code de traitement audio temps réel.
Après cette étape, et seulement si les développeurs en ont le temps, des apports seront réalisés. Lattner évoque de nouvelles capacités de scripts, une poursuite du travail sur la data reflection commencé dans Swift 3.0, l’arrivée des expressions régulières, le support des sous-modules, l’import d’API C++ ou encore le support renforcé du parallélisme. Mais dans l’immédiat, il est impossible de savoir quels ajouts seront intégrés.
Langage Swift : une version 3.0 presque terminée et un modèle open source qui fonctionne
-
Une bascule open source positive, avec quelques difficultés
-
Swift 3.0 sera une aussi grande cassure que la version 2.0
-
Swift 4.0 renforcera avant tout la stabilité
Commentaires (78)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 01/08/2016 à 14h55
Super, tous les ans, à la moindre mise à jour d’app, on doit passer des heures à la modifier… à “redécouvrir” le code déprécié, ils ne pourraient pas automatiser complètement ces changements?
ça devient lourd… quand on cherche un tutoriel, on doit maintenant préciser la version de swift et trouver la bonne.
Les sources github deviennent obsolètes rapidement et souvent non upgradées… et concrètement, les développeurs gagnent quoi dans tous ces changements? pour gagner 5 minutes de développement pur, on perd 2 heures de recherches.
Swift est beaucoup mieux qu’Objective-C évidemment mais si on casse tout chaque année, y’a plus d’intérêt!
Le 01/08/2016 à 15h03
+1
En 2010, pendant mes loisirs, j’avais commencé une appli pour iPhone assez riche en fonctionnalités. Ça aurait été ma 2e dans l’app store. Je n’ai jamais eu le temps de la finir rien qu’à cause des mise à jour de Cocoa Touch. Certes, je faisais ça pendant mes loisirs et pendant mes loisirs je ne faisais pas que ça.
Swift est certainement très intéressant et objective-C finira par disparaître, je plains les pros qui doivent se mettre à jour chaque année avec le langage et le framework.
Le 01/08/2016 à 15h05
C’est un avis personnel, mais je trouve que chaque constructeur qui veut faire son propre langage associé à son os, c’est une très mauvaise chose pour les programmeurs.
Le 01/08/2016 à 15h10
C’est très chiant.
Le 01/08/2016 à 15h17
C’est pour ça que tu as des solutions type
RubyMotion (anciennement MacRuby)
Xamarin
Go (ils ont des lib pour faire du mobile natif mais je me rappel plus des noms)
Le 01/08/2016 à 15h24
Le 01/08/2016 à 15h33
Chaque année… rien que ça.
C’est la première fois qu’il y a une cassure de compatibilité. Et si tu veux toujours faire du Swift 2 ou de l’Objective-C tu peux.
Tu peux même utiliser Swift et l’Obj-C en même temps. Histoire de migrer lentement et/ou d’utiliser toutes les libs que tu veux.
Comme avec les libs ARC et non-ARC, les deux cohabitent très bien.
Le 01/08/2016 à 20h53
Le 01/08/2016 à 21h19
Le 01/08/2016 à 21h20
Le 01/08/2016 à 21h24
Le 01/08/2016 à 21h31
Le 01/08/2016 à 21h57
Le 01/08/2016 à 22h01
Le 01/08/2016 à 22h13
Le 01/08/2016 à 23h31
Le 02/08/2016 à 01h51
C’est horrible, à vous lire j’ai l’impression que vous bossez tous en SSII et que la plupart des projets sur lesquels vous bossez se résume à pisser du code pour quelqu’un d’autre sans avoir pu prendre part à la conception ni même au thème du projet.
Le 02/08/2016 à 03h57
En lisant le debat sur les bons et mauvais développeurs, ça m’a fait tout de suite penser a ça :
Les inconnus (pour ce qui connaissent)
JOURNALISTE : Mais au fond quelle différence y a t il entre le bon et le mauvais chasseur ?
Tous : (RIRES)
CHASSEUR 3 : Ah j’l’atendais celle là ! J’l’attendais…
Non mais, le mauvais chasseur ? Bon, bah, c’est le gars qui a un fusil, y voit un truc qui bouge, y tire…
JOURNALISTE : Et le bon chasseur ?
CHASSEUR 3 : Le bon chasseur ? C’est un gars, il a un fusil, un fusil, y voit un truc qui bouge, y tire… mais…
CHASSEUR 2 : … c’est pas la même chose : y’a le bon chasseur, et y’a le mauvais chasseur… Y’a le viandard, et y’a le non viandard
CHASSEUR 1 : Bon y faut expliquer : Tu vois : y’a le mauvais chasseur : Y voit un truc qui bouge : y tire, y tire.
Le bon chasseur : y voit un truc : y tire… mais c’est un bon chasseur !!!
CHASSEUR 3 : Voilà ! C’est ça ! On ne peut pas les confondre….
CHASSEUR 2 : Y’a le mauvais chasseur : y voit un truc, y tire, c’est sûr… Alors là on le reconnaît à la ronde !
Mais le bon chasseur : y voit un truc, y tire, mais… c’est un bon chasseur quoi ! Bon, d’toutes façons, c’est des questions à la con ça…
CHASSEUR 1 : Faut leur expliquer aux gens parce qu’ils savent pas faire la différence après.
JOURNALISTE : On dit qu’il y a trop de chasseurs…
CHASSEUR 1 : Ah ça c’est la faute aux mauvais chasseurs ! Le bon chasseur, y’en a pas de trop, hein ?
CHASSEUR 2 + CHASSEUR 3 : Ah bah ça c’est sur hein
CHASSEUR 1 : Tiens, par exemple, le Bouchonnois ce n’est pas grand : 3 hectares, pas plus !
On chasse que la gallinette cendrée, alors on a limité à trois cent chasseurs, ça fait un chasseur au 100m²…
Mais ça, y’a que l’ bon chasseur qui sait s’limiter…
Personnellement, je ne suis ni développeur ni informaticien, mais pour moi, un bon développeur, c’est une personne qui sait surtout gérer son temps (équilibre bouleau/privée) et non pas une question de quel langage elle maîtrise ou pas. Mais ça, c’est valable pour tout les corps de métier finalement.
Le 02/08/2016 à 07h09
Bon déjà, parlons concret, parlons boulot, un développeur qui met 20 langages connus sur son CV, le recruteur/client va certainement l’éviter, il ne cherche pas une personne qui s’adapte/suit la technologie mais une personne experte dans le domaine recherché.
On a beau avoir “connu” beaucoup de langages, on est expert dans très peu, et la majorité des demandes sont très ciblées. Tu peux essayer de mentir au client/recruteur en augmentant la dite expérience, mais cela se verra très vite par la suite… Un expert ne passe pas la moitié de son temps à chercher le nom des fonctions ou des tutoriels sur internet…
Ce n’est pas parce qu’on se débrouille dans un langage qu’on le connait.
Le 02/08/2016 à 07h10
Je suis d’accord. Faut que je provoque les choses, ce ne sont pas mes commerciaux qui vont se bouger pour moi.
Le 02/08/2016 à 07h31
Pour moi ‘coder’, suivant les missions, c’est entre 5 et 20 pourcents du temps.
Le 02/08/2016 à 07h54
sr17, le dinosaure qui t’explique que les mammifères c’est nul, ça sait pas occuper une niche écologique " />
Le 01/08/2016 à 15h35
C++ ça fait le job pour tout depuis des décennies, et il fera toujours le job pour la décennie à venir. Les nouveautés dessus ont aussi le bon goût de ne pas péter le code précédent, une librairie des années 90 compile toujours avec un compilateur de 2016 à quelques ajustements de flags/include près, ce qui fait que la quantité de librairies dispos pour ce langage reste inégalée.
Le 01/08/2016 à 15h36
Le 01/08/2016 à 15h41
Le 01/08/2016 à 15h43
Le 01/08/2016 à 15h58
Le 01/08/2016 à 16h00
Le 01/08/2016 à 16h01
C’est une révolution ! Faut tout recoder.
==> Loin
Le 01/08/2016 à 16h04
Le 01/08/2016 à 16h07
Le 01/08/2016 à 16h07
Le 01/08/2016 à 16h07
Le 01/08/2016 à 16h17
Le 01/08/2016 à 16h20
Le 01/08/2016 à 16h33
Le 01/08/2016 à 16h36
De toute façon à part faire des copier/coller, ça ne sert pas à grand chose un dev, d’autant plus vrai qu’il y a de plus en plus d’outils pour leur mâcher le travail. Et ils sont toujours incapables de sortir des apps sans bugs! Et après ils blâment le marketing ou les commerciaux! Ils ne manquent pas de toupet.
Le 01/08/2016 à 16h48
Le 01/08/2016 à 16h48
Le 01/08/2016 à 16h50
Le 01/08/2016 à 16h55
Le 01/08/2016 à 17h30
Le 01/08/2016 à 17h49
Le 01/08/2016 à 18h14
Personnellement j’ai ouvert mon projet iOS et Xcode 8 m’a demandé si je voulais convertir mon code vers Swift 3 " />
Le popup
Le 01/08/2016 à 18h44
J’ose le parallèle avec les devs web : qui ira apprendre tous les CMS, tous les frameworks, tous les langages, etc. Personne. Pourquoi ? Parce que ça prend tout simplement trop de temps… Même si vous êtes un passionné qui ne compte pas ses heure, à un moment, vous avez des projets sur le feu, et faire de la R&D juste pour le plaisir d’apprendre, ça ne remplit pas la gamelle du foyer en fin de mois !
Hors du monde apple, même si le langage d’apple fonctionne, il n’intéresse tout simplement personne, parce qu’il n’apporte rien de révolutionnaire. Les commentaires plus haut me rappellent java, le “windows killer” de l’époque, qui a mis des années avant de se stabiliser, et dont les applications sont (et de loin…) les plus lentes que je connaisse. Même sous GNU/Linux, la réactivité des versions de Writer ou Calc, recodées en C++, par rapport aux anciennes versions codées en java, démontre à quel point java est une grosse merde.
Quand un langage est merdique, vous passez votre chemin et vous allez voir ailleurs. Et vu les commentaires plus haut, j’imagine que c’est ce qui va arrivera avec swift.
Le 01/08/2016 à 19h07
Je sais, ça converti une petite partie, comme lors du passage de swift 1 à 2, ça change quelques noms de fonctions, variables, mais dès que c’est déprécié, c’est mort, et se retrouver avec des fonctions dépréciés alors qu’elles n’ont qu’un an d’existence… comment dire… " />
Le 01/08/2016 à 19h25
Le 01/08/2016 à 19h45
Ah mais je ne regrette absolument pas Obj-C, il m’a rebuté au développement iOS de longues années ^^ Swift m’y a converti.
Des cassures, il y en a à chaque nouvelle version majeure de Swift, et elles sont mêmes déjà programmées pour Swift 4 par rapport au 3 qui n’est pas encore sorti… lol.
Mais merde, au lieu de sortir des versions à l’emporte pièce tous les ans, ils ne peuvent pas attendre pour sortir telle ou telle fonctionnalité complète au lieu de fonctions de transitions?
Ce n’est ni sérieux, ni professionnel comme démarche, de nombreux développeurs pro obj-c restent encore sur obj-c à cause de cela. Les swifteurs essuient les plâtres.
Le 01/08/2016 à 19h50
Le 01/08/2016 à 20h14
“attributedString.appendAttributedString devient attributedString.append”
Sans déconner, il leur a fallu trois versions pour trouver ça ???
Bon sinon, pour ma part, personnellement et en ce qui me concerne, je connais Ada (83 et 95), C, Fortran (jamais servi), Pascal (servi une fois en 2004), C++ (jamais servi non plus), un chouilla de shell unix, une pincée de Python (pour faire des outils fissa).
Je tiens avec ça depuis 25 ans, alors les 15-20 langages à savoir ou a avoir vu, ça me fait rire doucement.
Bon après, il n’y a pas que les langages, il y a les outils, méthodes et Cie, c’est un autre sujet.
Le 01/08/2016 à 20h15
Le 01/08/2016 à 20h43
Euuuhh comment peux-tu dire que tu connais des langages dont tu ne t’ai jamais servi?
Tu as été formé il y a plusieurs années dessus, c’est ça ta définition de connaitre?
Perso, je “connais” le C++, mais bon n’ai jamais rien fait avec et n’y ai pas touché depuis 13 ans, en résumé, je ne le connais pas beaucoup plus qu’un autre langage que je n’ai jamais vu… si je devais m’y mettre, j’y consacrerai autant de temps.
Toucher/aborder de nombreux langages pour répondre à des besoins ponctuels, oui, ça c’est certain, connaitre de nombreux langages, non. On n’en verra pas tant que cela dans notre vie, ceux avec lesquels on travaillera réellement et durablement.
Une bonne connaissance d’un langage fait qu’on y touche pendant au moins 10 ans (sauf si par exemple t’apprends le Flash 2 ans avant sa disparition et que tu croyais dur comme fer qu’il allait perdurer ^^).
Le 02/08/2016 à 14h28
Le 02/08/2016 à 16h16
Bah non, heureusement. Je ne me reconnais dans aucune de ces 2 catégories.
Le 02/08/2016 à 18h04
Le 02/08/2016 à 18h05
J’imagine que tu travailles dans la finance " />
Le 02/08/2016 à 19h52
Le 02/08/2016 à 21h11
Le 02/08/2016 à 21h35
Le 03/08/2016 à 07h19
Le 03/08/2016 à 12h06
Pareil pour beaucoup de boites. Passé 32 ans, difficile de décrocher ne serait-ce que des rendez-vous pour des offres d’emploi (dans de jeunes entreprises). Trop vieux, trop expérimenté, donc trop cher… on a souvent une réponse négative (quand on a la chance d’en recevoir, ce qui n’est pas le fort des “jeunes” entreprises) du type “vous ne correspondez pas au profil recherché”, malgré correspondre à tous les critères de l’offre…
Mais c’est un mal pour un bien, beaucoup de ces boites ne vivent pas très longtemps et ont une vision très limitée du développement.
Le 04/08/2016 à 00h39
Le 04/08/2016 à 17h09
Le 02/08/2016 à 07h57
Le 02/08/2016 à 08h07
Tout dépend de combien tu peux en couper en une journée de travail de disons 8h … " />
Le 02/08/2016 à 08h15
Le 02/08/2016 à 08h28
Le 02/08/2016 à 09h22
Tu as fait du basic en monde pro ? Nan parce que parlais dans ce scope.
Sinon, ouai, t’es un vieux de la vieille pour avoir fait du pascal et du cobol toi XD (avec tout mon respect hein)
En pro, j’en suis à PHP, C#.net (surtout de l’ASP.net) et Ruby, Javascript, Node (je compte pas HTML CSS ni les truc utilisé en terminal type shell etc), Python (que je conchie)
Le 02/08/2016 à 09h28
Le 02/08/2016 à 09h54
Au passage, Mac OS X étant un Unix, il est possible d’y programmer avec n’importe quel langage. Si on souhaite en rester avec Xcode, le choix est plus limité, mais entre le legacy (Obj-C, C++, Swift) et les plugins tiers (C#, Ruby, Python) il y a de quoi faire.
Le 02/08/2016 à 11h03
En même temps, être un expert d’un language, ça n’apporte pas grand chose…
Le 02/08/2016 à 12h32
Le 02/08/2016 à 12h57
Le 02/08/2016 à 13h34
Évidemment, je voulais dire «VBA est Turing complet ?»
Mais lien proposé montrerait que même sans macro Excel est Turing complet ?
C’est plus " /> mais " />" />" />
Le 02/08/2016 à 14h10
Le 02/08/2016 à 14h12
Le 02/08/2016 à 14h14
Le 02/08/2016 à 14h25
Bof… Angular a quand meme pas mal révolutionné le genre.