Google, Facebook et Uber envisagent l'utilisation de Swift
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.
Le plus gros probleme pour Android c'est la gestion memoire qui est differente du modele de Swift.
Sinon c'est vrai que ca semble etre un tres bon langage qui resout enormement de problemes habituels de C avec le meme niveau de controle bas niveau.
Je vois pas trop le problème, la gestion de la mémoire se fait peu au niveau du langage (déclaration weak dans la construction des classes "chainées") mais c'est surtout le compilateur qui gère ça et le "moteur d'exécution".
Dans le détail, ARC est plus pertinent sur mobile que le GC d'Android qui lui a besoin de 2 a 3 fois plus de mémoire en moyenne, ce qui explique aussi pourquoi les smartphones Android ont plus de RAM.
Apres il est vrai que le RC demande de penser un peu mieux son code et d'anticiper sa gestion de la mémoire, mais cela n'intervient que dans des cas "critiques", le compilateur prenant en charge les situations les plus courantes.
Le passage de Java a Swift dans Android n'est pas un problème pour Google, Swift étant capable de travailler avec les librairie C natives et la traduction des librairies Java en Swift peut de se faire de manière automatisée.
Le plus gros problème va être de motiver les developpeurs Android a se convertir a Swift, mais vu le potentiel du langage et sa courbe d'apprentissage courte ça devrait pas être difficile. D'autant qu'Oracle est depuis trop longtemps une menace et qu'avec leurs comportement stupide ils sont en train de réussir a saborder Java.
Apple a vraiment bien joué sur ce coup et même si Swift n'est pas une innovation en soi, comme ont pu l'etre Clascal ou DyLan, c'est une réalisation importante et bienvenue.
@ C1rc3@0rc : « Je vois pas trop le problème, la gestion de la mémoire ne se fait pas au niveau du langage mais c'est le compilateur qui gère ça et le "moteur d’exécution". »
Une partie se fait aussi, bien évidemment, au niveau du langage. On ne va pas écrire exactement le même code pour de l’ARC que pour un garbage collector (notamment pour la gestion des cycles), et le langage intègre ce qu’il faut pour le modèle de gestion de mémoire pour lequel il est pensé.
« même si Swift n'est pas une innovation en soi, comme ont pu l'etre Clascal ou DyLan, c'est une réalisation importante et bienvenue. »
Tout à fait.
aujourd'hui il est pensé pour ARC, mais demain vers quoi va-t-il evoluer.
Le cadre actuel permet dans Swift de penser la gestion de la mémoire de manière abstraite et logique: le weak est une indication logique, ce n'est pas une instruction d'allocation.
Peut être qu'il aurait ete plus logique de considérer l'inverse ( un strong plutôt pour sécuriser les contingences dans les structures de données).
Par contre lancer le cycle GC de manière manuelle, ça peut être adapté, mais il s'agit de bas niveau et dans ce cas on est plus dans la logique de conception mais dans le programmation de l'exécution, a ce moment on est alors proche du niveau système et autant avoir des outils de ce niveau.
Si on fait de la programmation applicative (des applications...) il faut optimiser la logique du soft, penser fonction et interface (pas que visuelle ;) ) et essayer de rester le plus indépendant du matériel.
L'OS et le compilateur sont la pour gerer l'attribution des ressources alors que l'applicatif lui doit se focaliser sur la logique et l'aspect fonctionnel et le developpeur applicatif n'a pas a compenser les manques et erreurs de l'OS.
On peut d'ailleurs critiquer cet aspect qui manque dans Swift au niveau du parallélisme: il n'y a pas de modele logique dans le langage, il faut passer par des librairies proches de l'OS, et ça c'est une grosse faille pour de la programmation de haut niveau.
En programmation de haut niveau l'adage est : " il ne faut jamais confier la gestion de la mémoire au programmeur, c'est bien trop dangereux et inefficace."
En programmation système l'adage c'est " il ne faut jamais confier la gestion de la mémoire au logiciel, c'est bien trop dangereux et inefficace"
Les deux sont vrais!
Il semble bien qu'Apple soit encore un moteur d'innovation finalement.
Je ne dirai pas qu'Apple est un moteur d'innovation pour les langages de programmation, mais ils ont su le rendre open-source. Vu qu'Apple compte sur les développeurs pour vendre ses iDevices (s'ils n'y avaient pas d'apps, les devices ne se vendraient pas), il est normal que les développeurs s’intéressent au nouveau langage d'Apple.
Cela aurait un gros avantage, celui de n'avoir qu'un langage de programmation à apprendre. Personnellement, je comprend 12 langages de programmations, cela fait beaucoup, mais cela demande aussi ENORMEMENT d'apprentissage. Je dois avouer que Swift 2 m'a séduit (mais pas Swift 1), et j'apprécie sa syntaxe (sauf l’absence de points virgules).
@nova313 :
Swift 1 était plutôt Swift 0.5… c'est d'ailleurs une des raisons pour laquelle ils ne l'ont pas mis Open Source dès la première WWDC : prendre un an pour finir les bases du langage (une vraie version 1… qui se trouve etre Swift 2 ^^)
Et encore tu es bien généreux en disant 0.5...
Swift 2 a encore des "scories" comm la boucle for du C qui est en cours d'évacuation.
Ceci dit, l'approche d'Apple est plutôt pragmatique car même les langages fortement conçus et contrôles ont toujours du être amendés pour satisfaire des cas reportés par les développeur. Je vais prendre 2 exemples de bons langages: Ada et Python.
Ada a été conçu pour le secteur militaire et industriel, avec un cahiers des charge et un comité de normalisation stricte, et avec un objectif de sécurité et d'efficacité. Pourtant, et malgré une réalisation très soignée et novatrice il a connu plusieurs révision, dont la dernière avec la version 2012 qui lui a apporté des outils majeurs absents a l'origine ou des corrections réellement nécessaire.
Python lui même qui est vraiment conçu pour la sécurité et l'efficacité et du faire une gros changement entre la version 2 et la version 3, ou des bizarreries ont été élimine et a permis de le rendre encore plus cohérente. Reste encore des choses étranges comme l'absence de constantes, peut être pour la version 4.
A l'opposé on voit des horreurs initialement cuisinées a la va-vite qui progressivement sous la pression des développeurs s'améliorent considérablement. Javascript est d'ailleurs un cas d'école a ce niveau et sa toute dernière version démontre une rationalisation pragmatique. Y a encore du boulot, notamment avec les ";" qui sont un facteur de bug.
Soit un langage est comme Lisp construit de manière mathématique et minimaliste pour être extensible et réflexif des le départ, soit est construit pour être structurant et normalisé comme Ada, mais dans tous les cas s'il est pertinent il va évoluer. L'approche d'Apple est donc pragmatique et semble attirer beaucoup de monde.
@nova313 :
Ben, si sortir un langage complet et avoir une courbe d'adoption pareille ne qualifie pas de "moteur d'innovation", je me demande bien ce qui rentre dans tes critères...
Courbe d'adoption entre guillemet. Envisager n'est pas faire. Mise à part IBM, d'on le partenariat avec Apple selon moi n'est pas étranger à cette adoption plus ou moins massive, rien n'est fait.
Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas.
@ k43l : « Courbe d'adoption entre guillemet. Envisager n'est pas faire. Mise à part IBM, d'on le partenariat avec Apple selon moi n'est pas étranger à cette adoption plus ou moins massive, rien n'est fait. »
Je pense qu’il parlait de l’adoption dans la communauté des développeurs (dont un gros paquets de petits développeurs, donc), et non d’une adoption par les grosses boîtes.
« Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas. »
Ah ben c’est sûr que ce ne serait pas un projet qui sera réalisable du jour au lendemain en deux coups de cuiller à pot. Et d’ailleurs, il serait idiot pour Google de s’y mettre avec Swift 2 alors que la version 3 amènera encore des changements significatifs de syntaxe.
«Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas.»
Je vois pas pourquoi. En théorie un OS est indépendant d'un langage de programmation. Si ce n'est pas le cas c'est que soit il y a une erreur de conception a la base, soit qu'il y a une volonté de contrôle du propriétaire, ce qui alors implique que l'OS est propriétaire.
Java n'est qu'un langage parmi les autres, conceptuelement et syntaxiquement discutable malgré son succès, et il est de plus construit sur une machine virtuelle. Dans les fait on peut donc remplacer Java par n'importe quoi d'autre qui se base sur la VM et qui reste compatible avec le code "compilé" pour la VM. C'est le cas par exemple de Jython, une version de Python qui tourne sur la VM de Java.
Au pire Google peut donc commencer la transition très vite en gardant la VM et en implementant Swift dessus.
@alderaan :
Je suis assez d'accord... La courbe d'adoption du Swift, notamment sur les plateformes mobiles d'Apple, est quand même pas degueu. Je ne sais pas ce que ça donne sur Mac, en revanche.
@nova313 :
Tu peux mettre des ; si tu le désires.
Ce n'est pas obligatoire mais tu peux.
C'est bien le Swift, j'aime le Swift.
C'est bon ça !
Pourquoi Google n'utiliserait pas Go ? Langage sympathique et produit par Google... Avec de bonnes idées, une bonne polyvalence, il est assez facile à appréhender par tout développeur ayant écrit quelque chose dans un langage cousin (même éloigné) du C.
Parce que c'est un langage qui n'est pas conçu pour de l'application mais de la programmation système. Il demande trop d'attention et un vraie formation d'ingénieur. L'absence volontaire de gestion des exceptions et des assertions est en soit une approche qui se défend, tout comme le choix de ne pas intégrer l'approche objet classique, ou d'intégrer un parallélisme assez particulier, mais ça implique une méthodologie et une discipline de développement qui ne colle pas avec la population qui produit des applications pour smartphone.
Le problème de Go c'est qu'il s'adresse donc a des ingénieurs systèmes, qui vont eux être formés a Ada, Eiffel et des méthodologies de développement pour contrôler le C.
Le developpeur d'application lui a besoin d'un langage qui paraisse abordable, pas trop contraignant (beaucoup viennent du Javascript ou pire du PHP) mais qui dans les fait dispose de forts et nombreux mécanismes de contrôle d'erreur. A ce niveau Swift est une vraie réussite. Et Swift est d'abord un langage applicatif, même s'il a un potentiel pour la programmation système.
Aïe.
Pourquoi aïe ? Parce qu’avec Google, on peut craindre un scénario à la WebKit → Blink, avec la sortie dans quelques années d’un fork de Swift (un « Swiftle » ou un « Gwift », bien que ce dernier nom sonne un peu trop gnomesque) contrôlé par Google et adopté massivement par les développeurs à cause du poids d’Android.
(Et comme le feront probablement remarquer certains : oui, c’est aussi le même genre de scénario que KHTML → WebKit, mais à l’époque je n’ai pas dit « aïe » parce que ce n’était pas sur mes arpions qu’on marchait.)
@BeePotato
Il y a des raisons au fork de Google pour Webkit et ca facilite aussi le travail sur Webkit. 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.
@robrob :
+1
Pour un langage je ne vois pas pourquoi ils voudraient forker. Ce n'est pas similaire à WebKit sur ce point là.
C'est vrai qu'ECMAScript n'a qu'une seule implémentation.
C'est vrai qu'Oracle n'a pas pu faire de procès à Google ou Microsoft sur l'interprétation du langage ...
En fait des fork de langage existent bien, mais ça ne s'appelle pas des forks.
Hacks VS php, Objective-C vs Objective-C 2.0 etc.
Et même sur des langage peu connus :
Eiffel n'est pas (n'etait pas ?) identique à 100% pour le compilateur SmartEiffel et EiffelStudio.
Bref,
Après Applesera tentée de mettre dans Swift des choses propre à Apple... Ce qui pourrait desservir Google qui pourait faire un fork.
N'est pas toujours coupable le plus évident.
Lorsque j'ai commencé mes cours d'informatique, le prof avait mis une "pancarte" ou était écrit en gros "Lisp est plus évolué que ses successeurs et descendants"...
Il y a une notion de conservatisme syntaxique qui fait qu'inévitablement le developpeur veut réaliser des concepts nouveaux avec une syntaxe existante.
Soit le langage est comme Lisp, mathematique, et permet d'integrer les concepts et de s'étendre selon le principe mathématique grâce a une base simple et cohérente
Soit on defini un nouveau langage qui intègre de la manière la plus cohérente un modele conceptuel, comme pour Swift.
Soit il faut greffer des structures grammaticales et syntaxiques construites de toutes pieces dans un langage existant. Le pire exemple de cela c'est le C qui a fini par intégrer (ou au moins tenté) des formes de programmations sécurisés d'Ada et orientées objets qui sont a l'opposé absolu du concept initial du langage (un assembleur de "haut niveau"), ce qui a conduit a des monstres comme le C++.
Tout dépendra de la façon dont Apple voudra normaliser et étendre le langage.
Cela pourra s'apparenter a ECMAScript ou Ada, ou cela pourra aboutir a des incohérences comme l'a vécu le Pascal ou chacun y allait de sa version.
L'approche opensource permet les deux, le comité de normalisation garantit la cohérence s'il sait rester dans lee concepts.
Un des points problématique de Swift c'est la gestion des exceptions qui n'est vraiment pas élégante et tres loin du modele d'Eiffel, alors que tout le permettait.
A ce sujet SmartEiffel n'existe plus. LibertyEiffel bouge encore un peu, mais...
Y a aussi une bizarrerie avec le "Labeled Statements": ça n'a pas plus de justification que le goto et c'est aussi dangereux!
Un autre très gros problème de Swift c'est la programmation parallèle et asynchrone.
Et finalement autre problème c'est qu'il se repose trop sur Cocoa.
Et la il risque d'y avoir des raison fork.
@ C1rc3@0rc : « Y a aussi une bizarrerie avec le "Labeled Statements": ça n'a pas plus de justification que le goto et c'est aussi dangereux! »
Oui, mais après tout, il ne s’agit que d’une extension du break et du continue, qui présentent déjà les dangers du goto (dont ils sont plus ou moins une variante). De ce point de vue, ce n’est pas tellement pire qu’une exception, je trouve.
« Un autre très gros problème de Swift c'est la programmation parallèle et asynchrone. »
Pour ma part, j’apprécie l’usage de GCD pour cette tâche, mais je comprends qu’on puisse préférer quelque chose d’un peu plus discret syntaxiquement parlant. :-)
« Et finalement autre problème c'est qu'il se repose trop sur Cocoa. Et la il risque d'y avoir des raison fork. »
Oui, c’est bien ce qui peut mener à des velléités de fork.
En revanche, du point de vue du développer visant les plateformes Apple, cette proximité avec Cocoa est plus vue comme une force que comme un problème. ;-)
Le probleme de GCD c'est qu'il s'agit d'une librairie propre a l'OS.
Ce n'est pas une construction du langage.
Si on fait de la programmation système, ça va, mais si on fait de la programmation applicative ( donc qui doit être portable et surtout se situe au niveau logique supérieur) c'est une aberration.
On est d'accord que pour developper pour iOS un minimum c'est de connaitre et d'exploiter les ressources de l'OS mais la on parle pas de développement sur iOS ou MacOS, mais du langage Swift et de plus de son portage sur des OS différents comme langage de programmation universel.
Demain on va voir arriver des architectures matérielles multi processeurs, des asymétriques, mêlant du vectoriel, etc... S'il faut considérer qu'a chaque fois que l'on veut faire un calcul matricielle de sélectionner une librairie spécifique par OS, alors Swift ne sera jamais un langage répandu: on va rester aux dérivés du C.
Le break et le continue ne sont pas comparable au goto. Ils sont certes la pour rendre réalisable des malfaçon dans la conception de haut niveau, comme les points de sortie multiple d'une fonction, mais il ne s'agit pas d'un saut arbitraire aussi puissant et dangereux que le goto. Ils restent des altérations pratiques et limités a la boucle en cour, donc même problème que les points de sortie multiples de la fonction.
L'exception, certes est mal comprise et souvent mal utilisé, mais ce n'est pas une instruction de branchement, c'est une gestion de la violation de la logique. Lorsque l'exception se declenche c'est une preuve qu'il y a une erreur de conception dans le logiciel et cela permet de minimiser les degat. C'est ultra puissant associé a la programmation par contrat.
Le labeled statement lui est un branchement du même type que le Goto, ni plus ni moins. Il n'a pas sa place ailleurs qu'en assembleur.
Et les boucles imbriquées devraient être impossibles car elles relèvent d'une erreur de conception ou de réalisation.
@ C1rc3@0rc : « Le probleme de GCD c'est qu'il s'agit d'une librairie propre a l’OS. Ce n'est pas une construction du langage. »
Ce n’est pas une construction du langage, mais ce n’est pas non plus une bibliothèque (et non « librairie ») propre à l’OS. Elle fait partie du jeu de bibliothèques appelé « core libraries » sur swift.org (https://swift.org/core-libraries/), qu’il est prévu de fournir avec Swift sur toutes les plateformes où il sera développé.
Le développeur Swift utilisant des fonctions de Foundation et de GCD ne se retrouvera donc pas dépendant d’un OS.
Il n’y a donc qu’une différence syntaxique avec l’approche consistant à ajouter au langage des bouts de syntaxe dédiés à la gestion deu parallélisme.
« si on fait de la programmation applicative ( donc qui doit être portable et surtout se situe au niveau logique supérieur) »
Non, la programmation applicative n’a pas pour vocation première d’être portable — au contraire. Certes, on a souvent la tentation de faire le maximum de code indépendant de la plateforme pour se faciliter la vie si on sort la même application sur plusieurs plateformes, mais ça ne doit pas être un des objectifs principaux lors du développement. Même pour les parties non directement visibles par l’utilisateur (le modèle, quoi), on peut gagner à utiliser des outils fournis par la plateforme sur laquelle on développe, plutôt qu’à essayer à tout prix de rester générique et portable.
Pages