Google, Facebook et Uber envisagent l'utilisation de Swift

Mickaël Bazoge |

Google pourrait bien adopter Swift comme un des langages pour Android, en plus de Java, le langage de prédilection pour le système d’exploitation mobile du moteur de recherche. La structure ouverte de Swift, qui est open-source, et les bisbilles judiciaires avec Oracle sont de nature à faire pencher la balance vers le langage orienté objets d’Apple.

Google aura évidemment du pain sur la planche pour s’appuyer sur Swift : le langage devra être pris en charge par les API et le SDK d’Android, sans oublier de mettre à niveau toutes les bibliothèques de l’OS compatibles Swift. Des interfaces de programmation bas niveau sont en C++, pour lequel il n’existe aucune passerelle avec Swift. Mais le travail est déjà en cours, indépendamment d’Apple et de Google (lire : Swift en route vers Android, avec la bénédiction d’Apple).

Et Google n’est pas seul à s’intéresser de près à Swift. Lors d’une rencontre à Londres, des représentants du moteur de recherche, de Facebook et d’Uber ont discuté de l’opportunité d’intégrer le langage d’Apple à leurs produits, rapporte The Next Web. Chez Facebook, le travail d’intégration aurait déjà commencé, d’après les sources du site, même si pour le moment c’est encore assez discret. Uber a de son côté un exemple tout prêt où puiser l’inspiration : celui de Lyft, passé avec armes et bagages à Swift (lire : Lyft raconte le voyage en Swift de son app iOS).

Swift est un des langages qui intéresse le plus les développeurs actuellement, depuis son passage en open-source. D’après les stats de GitHub, le bébé d’Apple est le 11e langage le plus populaire ; il est aussi utilisé par IBM pour propulser son cloud. Il faudra du temps et beaucoup de ressources chez Google, Facebook, Uber et les autres pour intégrer Swift dans leurs process. Pour le moment, c’est Google qui doit porter l’effort, les autres éditeurs s’appuyant ensuite sur ce travail pour adapter leurs apps et services au langage (en particulier pour tout ce qui concerne la gestion serveur). C’est pourquoi aucune annonce officielle ne devrait émerger avant un petit moment.

avatar BeePotato | 

@ robrob : « Il y a des raisons au fork de Google pour Webkit et ca facilite aussi le travail sur Webkit. »

En effet. Je prenais ce fork comme exemple de déroulement des événements (participation au projet le temps d’avoir un gros succès, puis fork une fois le succès acquis), plutôt que comme exemple d’impact négatif.

« Si a un moment il y a des raisons de faire un fork sur Swift je vois pas en quoi ce serait un probleme. Mais honnetement les forks de langage c'est plus rare et souvent moins justifie techniquement. »

Un désaccord sur la direction d’évolution de la bibliothèque standard, ça arrive facilement (surtout quand il s’agit d’adopter un langage comme langage de développement principal d’un OS déjà existant).
Ou un désaccord sur d’autres aspects plus fondamentaux du langage — il n’y a qu’à voir certaines des propositions sur Swift-evolution, avec des gars qui proposent des modifications qui transformeraient Swift en une sorte de clone de C++.

Et si un fork se produit pour une de ces deux raisons après qu’une grosse partie des développeurs Android seront passés à Swift, ils suivront naturellement la version Google et on perdra alors l’avantage d’un langage unifié.

Ce qui, en soi, n’est pas dramatique, je l’admets : après tout, on a très bien survécu jusque là avec un Objective C utilisé exclusivement sur les plateformes Apple ; on devrait donc s’en sortir sans réel problème avec un Swift version Apple (mais avec juste un poil de frustration en plus quand on tombera sur un joli morceau de code partagé en Swift version Google et qu’il faudra le réécrire en partie pour pouvoir l’utiliser).

À la réflexion, finalement, je me dis que je crains peut-être plus l’absence de fork, dans l’hypothèse du poids d’Android amenant à intégrer au langage des évolutions que je n’aimerais pas. :-)

Bref, juste des réflexions très préliminaires basées sur le fait que l’adoption d’un langage par un acteur d’un tel poids peut avoir des effets non anodins.

avatar robrob | 

@BeePotato
J'avoue m'etre interesse au Swift que de loin pour l'instant mais j'aime beaucoup ce que j'ai vu.
J'espere que malgre le cote open source, le controle de la direction du langage est assure par Apple. Tout comme Linux est tres controle malgre son cote open source (on peut reprocher certaines decisions mais elles sont generalement coherentes avec une idee maitresse).

avatar BeePotato | 

@ robrob : « J'espere que malgre le cote open source, le controle de la direction du langage est assure par Apple. »

Oui, c’est le cas pour l’instant.
D’où, en cas de future divergence de point de vue de Google au sujet de l’évolution du langage, une probabilité de fork qui me semble plus élevée que la probabilité d’arriver à imposer son point de vue.

avatar Khleo | 

Faudrait que l'on puisse developper des App Windows 10 en Swift et ça serait la fête

avatar patrick86 | 

"Faudrait que l'on puisse developper des App Windows 10 en Swift et ça serait la fête"

Oui, et on invitera Taylor pour chanter !

avatar Mike Mac | 

Taylor pour chanter ?

Et pourquoi pas David et Jonathan ?

avatar Armaniac | 

En ce qui me concerne, je m'étais intéressé à l'Objective C, juste par curiosité, il y a quelques années. J'avais fait joujou, suivi quelques tutos, mais je m'étais arrêté la. Je trouvais la syntaxe pas très sexy. Notamment l'usage à outrance des crochets me gonflait, sachant que sur un clavier Mac, il faut appuyer sur pas moins de trois touches en même temps pour l'obtenir...

J'ai vraiment découvert Swift il y a trois ou quatre mois. Et personnellement, sans être un développeur professionnel, je le trouve 100 fois plus lisible, et beaucoup plus facile à appréhender que l'Objective C. Quelques notions sont encore floues pour moi (les optionnels avec les ? Et !, notamment), mais j'ai réussi à coder une application complète et relativement complexe en deux mois sur Xcode, chose que je n'arrivais pas à faire avec l'Objective C. Cela dit c'est peut être aussi dû au fait que j'ai mûri certains concepts et méthodes de codage entre temps. Et niveau documentation, celle d'Apple est déjà pas mal foutue (ça manque quand même cruellement d'exemples concrets pour chaque fonction ; Microsoft a fait ca pour le VBA par exemple, c'est vraiment très pratique), et Internet fourmille de forums et tutos pour le Swift. Signe que le langage est en pleine expansion.

Si en plus il devient vraiment multi-plateforme, il va gagner énormément en attractivité. C'est toujours chiant de devoir switcher entre les langages dans une même appli.

avatar C1rc3@0rc | 

Euh si tu veux programmer prends un clavier qwerty sinon tu trouveras aucun langage "sexy" ;)
Et pour les crochets d'OJC, mets toi a Lisp avant, je te jure que ça va t'aider avec les crochets ;)

Mais bon si tu veux vraiment te mettre a la programmation commence avec Python et attaque avec le site Openclassroom et lis au moins un bouquin d'algorithmique de base

https://openclassrooms.com/courses/algorithmique-pour-l-apprenti-program...
N'hesite pas a explorer ce site et a en suivre les cours ils sont bons et abordables.

Surtout il y a des bouquins de références chez McGraw Hill dont au moins ces 3 la:

Data Structures and algorithms - concepts, techniques and applications de G.A.V. Pai

Schaum's Outline of Theory and Problems of Data Structures

Schaum's Outline of Essential Computer Mathematics

Apres y a des bouquins comme Analyse de données en Python de WMcKinney chez Eyrolles, mais c'est pour un niveau plus avancé.

avatar BeePotato | 

@ C1rc3@0rc : « Euh si tu veux programmer prends un clavier qwerty sinon tu trouveras aucun langage "sexy" ;) »

C’est une remarque que j’ai souvent lue, mais avec laquelle je n’ai jamais été d’accord (bien qu’utilisant tous les jours des claviers qwerty et azerty).

Oui, le clavier qwerty US donne un accès plus rapide aux crochets, aux accolades et au point.
Mais en échange, on se retrouve avec un accès plus lent qu’en azerty pour les parenthèses, les guillemets, le point d’exclamation, les deux points, ainsi que pour les @, &, ^ et $.

Il ne s’agit donc en rien d’une solution miraculeuse ou encore obligatoire pour développer. J’ai l’impression que cette réputation lui vient d’une comparaison avec la disposition azerty PC, effectivement bien peu agréable à utiliser (et pas juste pour programmer). Mais la disposition azerty Mac, notamment avec son regroupement logique des parenthèses, accolades et crochets sur les mêmes touches, est pour moi un plaisir à utiliser pour la programmation.

Évitons donc de présenter cette idée du « clavier qwerty pour la programmation sinon rien » comme s’il s’agissait d’une véritée absolue et indiscutable.

avatar Lio70 | 

@Armaniac
Quand on veut coder a l'aise et de manière professionnelle, on se munit du materiel adéquat, c'est a dire d'un clavier Qwerty. Aucun problème a taper des crochets avec un Qwerty. L'Objective-C abonde de crochets, ce qui le rend justement plus lisible. Swift est fait pour les debutants, de la meme manière qu'on a invente Windev pour des developpeurs franchouillards que ca emmerdait de devoir apprendre l'anglais. Argument de Swift, en resume: on peut taper comme on veut. Bref, un langage pour les amateurs qui ne parviennent pas a coder dans un environnement des que celui-ci exige d'eux de l'ordre et de la structure. Sans compter l'immaturité du langage et les nombreux bugs d'analyseur et compilateur.

Ca va être chouette, les applications en Swift. Bonjour le partage de code, les reprises de code fait par quelqu'un d'autre en milieu professionnel, etc... Parce qu'évidemment, meme dans des milieux prétendument hautement professionnels, on finira par adopter Swift parce qu'un code multi-plateforme revient moins cher. Quelque soit le domaine, quand plusieurs choses du meme acabit sont en competition, c'est la moins bonne qui triomphe car elle est en general aussi la moins couteuse.

Ce qu'Apple aurait du faire pour continuer d'être une plateforme de qualité, c'est a dire qui ne se soumet pas a la loi du grand nombre: obliger l'utilisation d'Xcode avec C, C++ et Obj-C point final, rejeter Swift, rejeter iAd, interdire la publicité dans les apps tournant sur OSX et iOS, interdire Java depuis toujours, ne pas permettre la gratuite des applications, obliger les developpeurs a être ages de 21 ans révolus pour s'enregistrer et distribuer leurs apps. Le monde des apps OSX/iOS se serait dégraissé de lui-meme pour privilégier le meilleur.

avatar alderaan | 

@Lio70 :
A la lecture de ce commentaire, mon bullshitomètre est monté dans le rouge, y est resté trop longtemps et a explosé.

avatar C1rc3@0rc | 

@Lio70

C'est du second degré?

Swift c'est pas Ada, on est d'accord mais c'est un langage jeune qui évolue et offre un cadre et des outils qui servent autant le développeur pro que l'étudiant ou l'amateur.
Le fait d'avoir des langage multiplateforme c'est pas une indication de nullité, au contraire, un langage spécifique a une plateforme c'est même inquiétant.

Le choix d'Objective-C semble du au besoin de disposer d'un langage orienté objet a typage dynamique permettant le latebinding nécéssaire a l'architecture du framework de NeXTStep qui s'inspirait fortement de l'environnement Smaltalk et qu'Interface Builder aujourd'hui intégré dans Xcode était développé en Lisp. Et comme le NeXT n'était pas un foudre de guerre fallait un langage compilé qui soit raisonnablement rapide et qui permette facilement de s'interfacer avec la base Unix: Objective C répondait a ces critères étant un preprocesseur C qui se calquait sur une bonne partie des concepts de Smalltalk. Et comme il ne rajoutait qu'un petit runtime au programme C il gardait une bonne vitesse d'exécution.

Et a cette époque il n'y avait pas non plus 36000 possibilités.

Quant a Java il tournait déjà sur NeXT Step et il a permis de rendre accessible le serveur WebObject de NeXT au marché des serveurs qui migrait lui massivement sur Java.
Et Java a l'époque présentait de vraies évolutions et était plus cohérent que l'usine a gas C++ ou l'antédiluvien C avec toutes ses bidouilles pour l'adapter a l'air du temps.

Il y avait bien d'autres langages qui auraient pu devenir pertinents pour prendre la révèle d'Objective C et faire du soft de qualité efficace (Eiffel, Ada 95, Object Pascal, BETA,...) mais soit c'était des langages non libres, soit pas encore assez développés.
De fait Apple a conservé Objective C pour réaliser Mac OS X.
Mais si ce langage a évolué, les concept de programmation aussi, les systèmes informatiques encore plus et l'approche OO et fonctionnelle sont nécéssaires…

avatar Rez2a | 

@Lio70 :
Je sais pas si tu es un dev Obj-C complètement fermé au fait d'utiliser un autre langage ou juste un mec qui n'y connaît rien, mais rien que la comparaison Swift/Windev me fait fortement espérer que tu n'es pas développeur de profession.

avatar Lio70 | 

@alderaan, C1rc3@0rc, Rez2a

Oui, professionnel depuis 20 ans. Et en ayant travaille sur Windows, OSX, Linux, HP-UX, Solaris et VAX/VMS, il y a pas mal d'outils de developpement qui me sont passes dans les mains, du simple langage de scripting au langage de programmation muscle. Je me suis meme fourvoye, a une epoque, dans Pascal/Delphi sous pretexte que c'etait bon et sympa, pour finir par realiser que je perdais mon temps et que l'on perd toujours son temps en sortant des fondamentaux. Idem pour des collegues qui se fourvoyaient avec Clipper.

Je ne suis pas ferme a l'innovation, mais a tout debat technique correspond un debat que je qualifierai de philosophique. Pourquoi inventer une technologie? Pourquoi innover? Quelles sont les considerations techniques, culturelles et commerciales qui orientent le choix d'adoption de telle ou telle technologie? Pourquoi adopter un truc nouveau qui fonctionne a moitie lorsqu'un truc ancien qui fonctionne tres bien est disponible? (je ne vise pas Swift ici, je parle en general, ca s'est vu souvent).

Pour argumenter serieusement, je devrais disserter pendant de nombreuses pages sur l'evolution des langages et, surtout, de ce qu'on en fait, pourquoi et comment. Les reactions aux News ne sont pas l'endroit ideal, et de toute maniere je n'ai pas le temps. Je ne repondrai donc pas davantage. Chacun est libre d'avoir son appreciation.

avatar BeePotato | 

@ Armaniac :
Concernant les crochets en Objective C, je suis d’accord avec Lio70 sur ce point : ils permettent une bonne lisibilité du code.
On a un peu perdu à ce niveau en passant à Swift et son usage des parenthèses qui viennent couper la lecture des noms de méthodes (on peut s’en rendre compte en voyant les discussions autour de l’étiquetage ou non du premier argument des méthodes en Swift). Dommage, ce langage ayant d’autres qualités par ailleurs.

avatar byte_order | 

c'est dommage que dans l'image d'illustration de cet article, le langage affiché n'est pas du Swift mais du CMake...
:-)

Pages

CONNEXION UTILISATEUR