Swift en route vers Android, avec la bénédiction d’Apple
Swift est un langage open-source, ce qui signifie que l’on peut en faire ce que l’on veut. Y compris l’adapter sur des plateformes où Apple n’est pas présente, et où l’entreprise n’avait pas prévu d’y porter le langage. Ainsi, le constructeur réservait jusque-là Swift à iOS et OS X, mais aussi aux systèmes Unix, avec une version prête à l’emploi pour Ubuntu, très populaire côté serveurs.
Néanmoins, d’autres développeurs sont en train d’adapter Swift à Android, avec la bénédiction d’Apple et même l’aide de ses ingénieurs. On est encore loin de parler d’un langage multiplateforme, mais le travail a commencé sur GitHub depuis quelques jours. Cette extension a pris la forme d’une « pull-request », c’est-à-dire d’une proposition d’amélioration soumise par un tiers, en l’occurrence par un développeur qui travaille actuellement pour Facebook.
Pour que cette proposition soit intégrée au projet, elle doit respecter certains critères et ce n’est pas encore le cas. Mais cela n’a pas empêché au moins un développeur d’Apple d’intervenir pour suggérer des modifications et améliorations. Dans les échanges qui suivent, on note aussi un commentaire de Chris Lattner, le créateur de Swift qui a porté le projet chez Apple et qui continue de participer à son développement.
L’ajout d’Android est ainsi un travail collectif, ce qui est logique étant donné que Swift est un projet open-source. C’est peut-être la première fois toutefois, que l’on assiste ainsi à l’ouverture du langage au-delà de ce qui avait été prévu par Apple.
Bien, l’émancipation en dehors du cercle des plateformes logicielles d'Apple est un élément essentiel pour la pérennisation et le succès de ce langage.
@ lmouillart : « Bien, l’émancipation en dehors du cercle des plateformes logicielles d'Apple est un élément essentiel pour la pérennisation et le succès de ce langage. »
Pas d’accord. La pérennisation et le succès étaient déjà quasiment garantis avec les plateformes d’Apple, qui fournissent suffisament de débouchés (il n’y a qu’à voir le cas d’Objective C, qui ne souffre pas vraiment du fait de ne pas être utilisé sur d’autres plateformes).
Là, ça permettra simplement de viser un autre type de succès (une utilisation multiplateformes à large échelle). Mais il n’est pas sûr que le langage n’en pâtisse pas. Quand on voit déjà certaines propositions délirantes qui passent sur swift-evolution, moins de trois mois après son ouverture, ça fait peur…
"Là, ça permettra simplement de viser un autre type de succès (une utilisation multiplateformes à large échelle)"
Je pense que c'est ca qu'il voulait dire par "pérenniser".
Aujourd'hui si Apple abandonne Objective-C, qui va l'utiliser, à part 3 clampins sur GnuStep ?
@ françois bayrou : « Je pense que c'est ca qu'il voulait dire par "pérenniser". »
Oui, j’imagine. J’avoue que je me suis surtout focalisé sur la notion de succès.
@BeePotato
+1
La pérennité d'un langage dépend de sa popularité et de la vitesse a laquelle les lignes de code s'accumulent...
Un langage ne s'est jamais développé parce qu'il est bon, mais parce qu'il:
- est accessible,
- capable de se mixer avec l'existant
- permet de coder plus vite que ce qui précède
- est peu contraignant
- s'apprend vite (au moins un sous ensemble fonctionnel)
- est choisi par l'industrie
- est polyvalent
C et BASIC sont des langages épouvantables, mais étaient les seuls disponibles sur toutes les plateformes, s'apprenant très vite, très permissifs et permettant de coder plus vite qu'en assembleur.
Les C a objet restent du C auquel on a ajouté une couche objet, donc l'acquisition s'est faite très vite. Ils sont horriblement compliqués, mais la majorité des gens n'en utilisent qu'un sous ensemble qui se compose d'un C simplifié et de la couche objet minimale.
A l'inverse ADA est un langage contraignant, efficace, peu accessible, nécessitant un long temps d'apprentissage, mais c'est le le langage industriel des qu'on parle de sécurité.
Eiffel est un très bon langage, novateur mais contraignant, demandant un long apprentissage. Il a été longtemps inaccessible et n'a pas été choisi par l'industrie.
Swift est un bon langage, peu contraignant offrant l'expressivité(procédural, fonctionnelle, objet) et la securité. Il est concis et tres polyvalent.
Apple vise avec Swift a remplacer le C et la myriade de langages approximatifs qui pullulent dans les différents secteurs. Swift peut servir a de l'applicatif, du systeme, mais aussi du script et du WEB. On peut même l'utiliser en science...
Si Apple veut que Swift remplace donc C, Perl, PHP, Java, Javascript,... il fallait le mettre en opensource et l'insérer dans l'industrie: IBM le place dans le WEB.
Avec Android il va occuper 100% du dev mobile (serait étonnant que Google conserve Java avec les pbs avec Oracle). On l'attend maintenant pour le scripting.
Dans quelle mesure est-ce compliqué d'apprendre Swift si on a de solides bases en Java et en Python ? Le langage m'intéresse vraiment.
C'est vraiment tres simple à apprendre.
La syntaxe est assez facile à comprendre.
Je fais beaucoup de C++ et C# et il m'a fallu que quelques heures pour l'utiliser correctement.
Apres, tu decouvrira les API au fur et a mesure (sauf si tu connais l'Objective-c)
Il existe un livre fourni par apple (gratuit) pour survoler l'ensemble du langage.
Tres bon point de depart
Faut oublier tout Java (beaucoup de pièges, faux amis, faux semblants) et c'est moins rigoureux (syntaxe) que Python.
Pas d'heritage multiple comme en Python mais il y a un ensemble de mécanismes qui permettent d'obtenir des possibilités similaires (protocol de l'Objective C) et y a aussi une intégration du mécanisme des langages de prototype (Javascript, DyLan),... Donc en fait la gestion de type qui semble relativement simple au debut est en fait complexe, progressive et très puissante.
Le plus complexe pour ceux qui viennent du C est des langages procéduraux orientés objets c'est la partie fonctionnelle.
Un des pièges c'est l'ordre de déclaration inversé par rapport au C (et derivés) mais qui est plus logique (identifiant type). Y a aussi tout le coté restriction semantique auquel il faut faire attention en venant de Java.
Sinon, en y allant progressivement et en expérimentant les possibilités ( gros avantage du bac a sable, ça ressemble a un langage interprété) c'est un langage tres abordable. Et surtout le langage est tres bien documenté.
Aprés faut comprendre que c'est une langage tres puissant dont le champ d'application est tres large (script -> programmation systeme) et qui empile les concepts le tout avec une syntaxe heritée de l'objet et du fonctionnel et qui contient aussi des anomalies de cohérence ( comme la boucle "for" du C, qu'il vaut mieux oublier et qui aurait du etre calqué sur le modele de python) probablement résolue dans une prochaine révision du langage.
@ C1rc3@0rc : « Faut oublier tout Java (beaucoup de pièges, faux amis, faux semblants) »
Très bon conseil, un des plus gros problèmes posés par Swift (par rapport à Objective C) étant sa syntaxe qui ressemble beaucoup plus à tout ce qui se fait ailleurs, et qui du coup peut induire les nouveaux arrivants en erreur en leur faisant croire qu’il pourront écrire quasiment le même code.
« qui contient aussi des anomalies de cohérence ( comme la boucle "for" du C, qu'il vaut mieux oublier »
Hé ! Il est très bien, le for du C ! :-)
Mais en effet, mieux vaut l’oublier, car il va être supprimé de Swift.
«Hé ! Il est très bien, le for du C ! :-)»
Attends, tu parles du truc responsable de la moitié des overflow et des boucle infinies (ou ne commençant jamais)?
Une autre horreur c'est le switch du C... La version de Swift, bien qu'horriblement proche abandonne heureusement son fonctionnement calamiteux.
«Mais en effet, mieux vaut l’oublier, car il va être supprimé de Swift.»
Effectivement j'avais loupé l'annonce officielle Remove C-style for-loops with conditions and incrementers
c'est tellement mieux Array(0.stride(to: 10, by: 2))
@ C1rc3@0rc : « Attends, tu parles du truc responsable de la moitié des overflow et des boucle infinies (ou ne commençant jamais)? »
« NRA-style » : Ce n’est pas le fling… euh… le for qui crée les problèmes, mais l’usage qu’on en fait. Le coupable, c’est bien le développeur. ;-)
Oui, je parle bien de ce for qui permet d’écrire en une seule ligne le genre d’horreurs qu’on peut écrire en deux lignes avec un while (que ce soit en C ou… en Swift), mais qui pour des boucles « normales » permet de regrouper de manière simple et facilement lisible toutes les caractéristiques de la boucle.
Franchement, les boucles for susceptibles d’être remplacées par un « for in » + stride, ce ne sont pas celles qui étaient susceptibles d’aboutir à des dépassements ou à des boucles infinies.
Les boucles problématiques, ce sont les autres, les compliquées (ou tordues, selon que c’est nécessairement ou inutilement compliqué), qu’on ne pourra pas remplacer facilement par un machin comme ça et qui seront donc reformulées à l’arrache en utilisant un while, et aboutiront au même résultat.
La seule différence, c’est que dans la plupart des cas en Swift, un dépassement sera détecté — mais ça, c’est quelque chose qu’on avait déjà avec le for du C.
« Une autre horreur c'est le switch du C... La version de Swift, bien qu'horriblement proche abandonne heureusement son fonctionnement calamiteux. »
Ah, là, en revanche, je suis on ne peut plus d’accord ! Ce fonctionnement du switch (enfin, du case, en fait) est tordu, complètement non intuitif, générateur d’erreurs, le tout sans qu’il y ait vraiment beaucoup de cas où il sert à quelque chose. Bon débarras.
« c'est tellement mieux Array(0.stride(to: 10, by: 2)) »
Beurk !
Heureusement, on n’a pas besoin du « Array », mais beurk quand même. Nettement moins souple et, surtout, terriblement moins lisible (et du coup, j’en prends le pari, encore plus susceptible de faire faire des erreurs).
Etant donné la dépendance d'Android à Java et l'état des relations entre Google et Oracle, il semblerait logique que Google souhaite, voire encourage, l'initiative.
En second lieu, une des raisons pour laquelle Google avait choisi Java était sa popularité parmi les développeurs et l'existence d'une communauté importante. Là encore, l'ouverture de Swift à d'autres plateformes servirait les intérêts de toute l'industrie, pas uniquement ceux d'Apple ...
D'une certaine manière, l'adoption de Swift sur un ensemble de plateformes ressemblerait aux tentatives récentes de définition d'un standard vidéo ouvert : éliminer les problèmes de licences et de royalties.
Je ne pense pas.
Il existera toujours un pont vers la plateforme Java.
La c'est juste que le developpeur pourra ecrire son code en Swift, mais en arriere, la VM java sera toujours la
La machine virtuelle n'est pas spécifique au langage, c'est une machine virtuelle.
Java est un langage, il doit passer par un compilateur pour etre executé sur la VM. Qu'on remplace Java par Python ou Swift, la VM ne verra pas la différence, faudra toujours un compilateur entre le langage et la VM. Donc Java peut être éliminé très vite de ce point de vu. C'est d'ailleurs l'approche de Jython ou de Scala
Apres, on peut avoir des VM comme LLVM a la place... A terme ça devrait d'ailleurs aboutir a des processeurs disposant d'une couche VM.
Le problème de l'évacuation de Java c'est que Java c'est une énorme part des soft serveur. Et la on préfère la stabilité même si on est sous le joug de licences contraignantes et d'incohérences...
"Le problème de l'évacuation de Java c'est que Java c'est une énorme part des soft serveur. Et la on préfère la stabilité même si on est sous le joug de licences contraignantes et d'incohérences..."
la stabilité de java côté serveur ?! tu rigoles ?! on a pas du vivre la même expérience.
Java côté serveur (ou client d'ailleurs) est une vraie plaie:
entre les conflits potentiels d'imports et les collisions lors du classloading, la "presque toujours" nécessité de redémarrer quelque chose pour appliquer un changement (webapp, serveur,...), la performance médiocre en montée en charge, la gestion chaotique de la mémoire et du recyclage des objets, les freezes cpu ou garbage collector, la gestion infâme des exceptions et des logs qui en résultent, les contraintes liées à la gestion de la mémoire/multicores/multithreading pour une même jvm, la sécurité (failles, reverse engineering facilité) et bien sûr la lourdeur et la complexité des environnements de développements.
Java est une contrainte pour les utilisateurs, les développeurs, les fonctionnels métier et les exploitants.
Bonne nouvelle ça !
@ Darcel : « Bonne nouvelle ça ! »
Pas si sûr, car ensuite la tentation d’utiliser des frameworks multiplateformes n’en sera que plus grande pour certains développeurs — et ça, ce n’est jamais une bonne chose.
Seul le temps nous dira si Swift va réussir son pari...
Mais pour l'instant, quand on parle de langage multiplateforme, on pense d’abord à Java, C# (au travers de Xamarin et .net Core) et on a le bon dernier Swift qui commence son exploration en dehors de son berceau.
Enfin bref... les choses commencent à bouger pas mal ces derniers temps dans le domaines.
C# multiplateforme????
C# est un succédané déficient de Java (les exceptions ne sont même pas vérifiées) et spécifiquement adapté a la plateforme .NET. C# a ete créé car Microsoft ne pouvait pas être dépendante de Sun puis d'Oracle. d'ailleurs au debut Microsoft voulait, comme a son habitude, "adapter" Java a sa sauce avant d'etre contraint de changer toute la syntaxe suite au procès avec Sun.
Swift vient tout juste d'apparaitre et la version opensource pompeusement nommée 2.0 n'est en realité qu'une V1 et encore. Le langage n'est pas encore complet ni stabilisé. On va dire qu'il est en v2 Apple et en beta opensource.
Il y a encore pas mal de choses a finir dont 2 gros morceaux
- la gestion du parallélisme (type SIMD débutant, générateur mais pas de encore de coroutines ni de process ou threads, callback natifs) qui est essentiel avec les processeur multicore et les unités de traitement vectoriel.
-les vérification de contraintes d'état: precondition mais aussi postcondition et certification d'intégrité d'etat de sortie.
Pour l'instant on a "assert" (exception handling) qui se mélange a la fonction "precondition" alors qu'il s'agit de 2 choses différentes et qu'une contrainte est une structure de contrôle de flux et pas une fonction.
Si Apple veut que Swift satisfasse les objectifs de sécurité, d'efficacité et s'installe dans la durée il faut absolument finaliser et stabiliser ces elements.
@ C1rc3@0rc : « - la gestion du parallélisme (type SIMD débutant, générateur mais pas de encore de coroutines ni de process ou threads, callback natifs) qui est essentiel avec les processeur multicore et les unités de traitement vectoriel. »
Améliorer l’accès au SIMD, ok. Mais pour le reste, je trouve qu’on s’en sort très bien avec GCD. Je trouve qu’il serait dommage d’alourdir encore ce langage (qui l’est déjà pas mal, comparé à un Objective C) pour y intégrer des trucs qui ne feront pas une grosse différence.
M’enfin, ça ne dépend évidemment pas de moi et apparemment c’est bien parti pour une grosse vague d’ajouts liés au parallélisme.
On verra bien ce que ça donnera.
Swift très populaire surtout Ubuntu ? Ha bon ? Quelques projets peut-être mais rien de bien fou.
Enfin dans le cadre d'android, le choix du Java était motivé par la possibilité d'exécution sur un matériel hétérogène. Donc à moins que le Swift produise un bytecode adéquat...
"Swift très populaire surtout Ubuntu ? Ha bon ? Quelques projets peut-être mais rien de bien fou."
L'article dit qu'Ubuntu est populaire sur serveurs, pas que Swift est populaire sur Ubuntu.
J'espère que Swift finira par devenir le langage majoritaire sur les plateformes mobiles, ce portage pour Android est un bon premier pas.
My Swift is rich indeed.