Phoenix, une version open source de Swift

Stéphane Moussie |

Une petite équipe de développeurs travaille sur une implémentation open source de Swift, le langage de programmation d'Apple lancé lors de la dernière WWDC. Dénommé Phoenix, ce projet est supervisé par Greg Casamento, un développeur Objective-C qui gère également GNUstep, une version open source d'OpenStep (le jeu d'API du système d'exploitation de NeXT, qui a évolué ensuite en Cocoa).

Logo de Swift. Photo Yuko Honda CC BY-SA

L'objectif de Phoenix est en fait d'inciter Apple à rendre Swift open source. Dans une lettre ouverte adressée à Tim Cook, les membres d'ind.ie rappellent l'importance de l'open source dans l'histoire d'Apple : « Que se serait-il passé si Chris Lattner (qui chapeaute Swift, ndr), n'avait pas rendu open source LLVM (un compilateur très performant utilisé par Apple) ? »

D'après ind.ie, ne pas rendre open source Swift, ainsi que Metal, revient à « compliquer le portage des applications sur Android, et au bout du compte à devoir choisir entre les deux plateformes. » « Ayez la confiance de publier Swift sous une licence libre et ouverte. Permettez à Swift d'épauler Apple comme l'ont fait les autres logiciels open source. »

Un autre projet a été lancé peu de temps après l'annonce de Swift. Silver doit permettre d'utiliser le nouveau langage de programmation d'Apple avec Java (Android) et .NET (Windows).

Tags
avatar Darth Philou (non vérifié) | 

C'est une excellente initiative, mais en même temps, je pense qu'il faut laisser le temps au langage de faire ses preuves et de monter en maturité avant de le laisser totalement à une communauté libre.
Donc oui, mais pas tout de suite, pas trop vite.

avatar C1rc3@0rc | 

Apple a une politique assez claire sur l'open source: libérer les sources une fois que le projet est juge suffisamment abouti. Swift vient juste de sortir de version beta officiellement et il est fort probable qu'Apple libère les sources comme c'est le cas pour Webkit. C'est plus une question de temps que de volonté selon toute vraisemblance.

Apple a de toute façon intérêt a rendre Swift open source.
Si on prend le cas des langages propriétaires ils ont une diffusion très restreinte et ne sont pas enseignés. On peut prendre l'exemple de l'excellent langage Eiffel, qui a été libéré tardivement et qui reste confidentiel malgré sa très grande supériorité sur les autres langages utilises dans l'industrie…

Un autre pribleme se pose aujourd'hui et qui attend la fin du procès Google/Oracle par rapport a Java. Si la jurisprudence va dans le sens d'Oracle, alors Swift aura intérêt a rester ferme. Dans le sens ou la justice donne raison a Google, alors Apple aura les garanties nécessaires pour libérer Swift, voir Cocoa...

avatar Wolf | 

Quel intérêt de faciliter la vie des développeurs Android ?

avatar rondex8002 (non vérifié) | 

@Wolf :
Faciliter la vie des développeurs d'une façon générale ?! Ça peut aussi encourager les développeurs qui ne choisissent qu'une plateforme, de développer pour les deux.
Mais bon, ça serait très étonnant venant d'Apple, de faire ce « cadeau ».

avatar joneskind | 

J'aime plutôt bien l'idée.

Swift open source deviendrait un langage universel qui pourrait bien promouvoir le Mac comme machine ultime de développement.

Malheureusement, j'y crois pas trop.

Content d'apprendre que GNUstep existe toujours et qu'un groupe se penche sur la question d'un Swift open source.

avatar nova313 | 

Cela reste une bonne idée, car le risque avec Swift, c'est que tôt ou tard, Apple peut arrêter le support objective-c, et proclamer que les applications soient full-swift.

Étant donné qu'il s'agit d'un programme développé par Apple, certains craignent (comme moi) cette imposition, car on connaît Apple et son culte sectaire de la sécurité.

D'ailleurs, je ne suis pas totalement fan de Swift, car il s'agit d'un énième langage qui tente d'imposer sa nomenclature, comme la disparition des point-virgules, pour ne citer que ça. Or les langages les plus utilisé respecte les préceptes de C (en même temps, tout est dérivé du C), et ces langages, bien que différents, respecte les mêmes bases (variable, fonctions, ...).

Tout ça pour dire, que Swift tente de changer les méthodes des Devs, ce qui ne me plait pas, mais je suis prêt à me convertir, si ce langage devient open source, et pourra être utilisé sur différentes plateformes autre qu'apple.

avatar Darth Philou (non vérifié) | 

@nova313 :
Les devs n'ont pas attendu Swift pour faire évoluer leurs méthodes.

Au contraire, Swift apporte enfin toute la modernité qu'on attend d'un langage aujourd'hui.

Objective-C étant très limité en comparaison des langages actuels, le risque pour Apple aurait été un désintéressement progressif des devs pour iOS.

avatar stiflou | 

@nova313
« (en même temps, tout est dérivé du C) »

Connais-tu Haskell ou Lisp ? pour ne citer qu'eux. Lisp, ça reste tout un pan entier de la programmation (fonctionnelle et non impérative comme le C) qui s'est développé sans le C et qui est encore aujourd'hui bien utilisé, avec ses dérivés. Connais-tu Emacs ? (je n'aime pas Emacs) C'est du Lisp :)
Alors que l'impératif s'est imposé comme « mainstream » avec le C et ses dérivés — C++ et Java notamment — on peut avoir tendance à oublier que le fonctionnel existe, et redevient tendance même ! on peut prendre le très bon exemple de Scala, paru assez récemment (une petite bombe de l'EPFL). Un autre exemple ?
Swift. Et oui, Swift, même s'il n'est pas vraiment purement fonctionnel (plus générique), a suivi la tendance de la « modernité », et a donc récolté un peu de fonctionnel. Parce que, le langage machine, c'est bien, mais les maths, c'est vraiment cool aussi ! Si tu ne connais pas, je t'invite à te renseigner dessus, j'ai trouvé ce site un jour, j'ai bien aimé : http://robnapier.net (alias Cocoaphony), tu pourras lire ce qui est dit sur Swift notamment.

C'est bien de garder ses habitudes, mais évoluer quand celle-ci sont un frein, ça peut être mieux. Pourquoi est-on encore sur ce clavier totalement à ch*** qu'est le QWERTY (ou dérivés) ? Parce que quand on est passé de la machine à écrire au clavier, personne n'a voulu changer la disposition, et aujourd'hui on le paye. Les points virgules en bout de ligne ? pourquoi faire ? il y a déjà un caractère de fin d'instruction (le retour à la ligne), pourquoi en mettre deux ? C'est tellement plus cool de bricoler un petit plug-in pour te les ajouter automatiquement, plus d'oubli, et une touche seulement pour terminer une instruction ! Crois-moi, c'est le progrès, enfin non, le vrai progrès est de ne pas avoir besoin d'en mettre si c'est inutile. Alors oui, si les méthodes de dev sont archaïques (comme ce bon vieux QWERTY, qui datent de 1870), et n'ont plus de raison d'être, mieux vaut les remplacer.

avatar BeePotato | 

@ stiflou : « Les points virgules en bout de ligne ? pourquoi faire ? il y a déjà un caractère de fin d'instruction (le retour à la ligne), pourquoi en mettre deux ? »

Parce que si le compilateur distingue très bien un caractère fin de ligne, le développeur humain a parfois plus de mal à le faire, notamment s’il a activé dans son éditeur le retour à la ligne automatique pour éviter d’avoir à faire du scroll horizontal.
Un point-virgule lui permet de confirmer rapidement, sans réfléchir, qu’il est bien au bout d’une ligne et juste au milieu d’une ligne, et ce même dans un éditeur incapable d’afficher les caractères invisibles (mais de toute façon, qui aime les afficher en permanence ?).
Comme beaucoup de choses dans les langages de haut niveau, c’est donc bien plus destiné à faciliter la vie de l’humain que celle de la machine.

Heureusement, Swift, si je ne m’abuse, permet de conserver un point-virgule en fin de ligne si on le souhaite, ce qui permet de continuer à profiter de cet effet.

Mais le côté non-obligatoire de leur présence ne permet plus d’être facilement sûr, quand on est face à un retour à la ligne, qu’il s’agit bien d’une fin de ligne volontaire ou juste d’une faute de frappe (ou autre erreur de copier-coller). Alors que le point-virgule obligatoire permet un « débugage visuel » facile de ce genre de cas.

avatar stiflou | 

Tu marques un point là-dessus. Avec le « wrapping », il peut y avoir confusion (enfin, ça ne me pose pas de problèmes mais je comprends tout-à-fait ce point de vue).
Le mieux reste pour moi d'automatiser son ajout, notamment par l'utilisation de snippets/autocompletion (quand je vois mes amis coder sans, ça me fait parfois rire ^^) ; le réel problème pour moi n'est pas tant l'utilisation du caractère « ; » — que je trouve bien approprié — mais le fait de devoir utiliser deux touches quand une suffirait amplement. Il est suffisamment aisé pour les développeur d'éditeurs de texte/IDE de rajouter une détection automatique, ça se fait même sur certain avec un message du genre : « un ; a été oublié ligne *** ; appuyé sur Entrée pour l'ajouter » … Bref, le point-virgule comme indicateur de fin de ligne, ok, il a en effet une utilité, mais le fait de le taper (et potentiellement de l'oublier, ce qui est toujours énervant), là je trouve qu'on pourrait/devrait évoluer.

avatar BeePotato | 

@ stiflou : « Avec le « wrapping », il peut y avoir confusion (enfin, ça ne me pose pas de problèmes mais je comprends tout-à-fait ce point de vue). »

Même quand ça semble ne pas poser de problème, ça peut ralentir un chouilla la lecture, en introduisant une très courte hésitation parfois, pour les lignes où on n’est pas forcément sûr au premier coup d’œil d’avoir la bonne interprétation. Faisant, du coup, perdre brièvement un peu de concentration.
Ce n’est pas grand chose, mais puisqu’un caractère ultra simple à taper permet de s’affranchir complètement de ce risque, pourquoi ne pas utiliser cette approche ?

« Le mieux reste pour moi d'automatiser son ajout, notamment par l'utilisation de snippets/autocompletion (quand je vois mes amis coder sans, ça me fait parfois rire ^^) ; le réel problème pour moi n'est pas tant l'utilisation du caractère « ; » — que je trouve bien approprié — mais le fait de devoir utiliser deux touches quand une suffirait amplement. »

Mais l’automatiser comment ? Qu’est-ce qui peut être plus rapide, même pour l’utilisation de snippets, que la frappe d’un seul caractère ?
Au passage, je ne comprends pas ton histoire de deux touches : sur un clavier azerty, comme sur un clavier qwerty, le point-virgule est directement accessible, en une touche (sinon, on peut parier qu’il n’aurait jamais été adopté comme marqueur de fin de ligne par des développeurs C).

« Il est suffisamment aisé pour les développeur d'éditeurs de texte/IDE de rajouter une détection automatique, ça se fait même sur certain avec un message du genre : « un ; a été oublié ligne *** ; appuyé sur Entrée pour l'ajouter » … Bref, le point-virgule comme indicateur de fin de ligne, ok, il a en effet une utilité, mais le fait de le taper (et potentiellement de l'oublier, ce qui est toujours énervant), là je trouve qu'on pourrait/devrait évoluer. »

Tout à fait. Mais ça a déjà évolué : c’est justement fait comme ça dans certains éditeurs.
Mais l’avantage de conserver le point-virgule, c’est qu’on peut continuer à coder de manière efficace même dans des éditeurs n’intégrant pas cette fonction. Et pour qu’il soit pleinement effiace dans ce rôle, il vaut mieux qu’il soit obligatoire.

avatar stiflou | 

Je dois t'avouer que je me repère plus à l'indentation qu'aux point-virgules, d'où mon point de vue. Après, je dois les regarder inconsciemment, mais l'indentation me suffit consciemment ; une ligne « suivante » qui est indentée sans qu'il y ait de mot particulier au début de la ligne (comme un « if », mais ça dépend des langages) , ça veut dire que ce n'est qu'une seule ligne, point. Quand je recule d'une indentation, ça veut dire que je change de ligne, voilà mon point de vue. Après, sur mes éditeurs, lorsqu'une ligne est « wrappée », elle est indentée pour les parties coupées, ce qui n'est peut-être pas le cas de tous les éditeurs, je n'en sais rien — si des éditeurs ne proposent pas ça, c'est très léger … Bref, l'indentation me suffit, du moins j'en ai l'impression, le « ; » m'apparaît seulement comme un « plus » de lecture, mais aussi comme un « moins » d'écriture.

Comment l'automatiser ? Je vois que tu n'as pas très bien compris mon propos, je vais l'éclaircir :) Les deux touches correspondent à : un appuie sur la touche « ; » (en accès direct effectivement sur QWERTY et AZERTY, ce qui n'est pour moi pas vraiment nécessaire mais bon … Serieusement, l'absurdité de l'AZERTY de mettre un point-virgule plus accessible qu'un point lol!!) et un appuie sur la touche « Retour ». Un simple appuie sur la touche « Retour » et un éditeur un tout petit peu compréhensif suffirait amplement. Certes, cela ne vaut que pour l'écriture au fur et à mesure, en ce qui concerne l'insertion d'une ligne, plus besoin d'appuyer sur « Retour », le point-virgule suffit, et on a bien une seule touche, ce qui est mieux (même s'il serait encore mieux de ne pas en avoir selon moi).

Oui, cela a évolué, et j'en suis heureux, mais comme tu le dis, pas partout, et cela, je le déplore. Les interfaces des terminaux sont plus vielles que moi ><' Et elles n'ont pas vraiment évolué depuis … Dans le terminal OS X, si je veux effacer un mot, je ne peux pas appuyer sur Alt + Backspace, mais je peux utiliser Alt pour me déplacer par mot … Si je veux travailler sur un serveur, je suis obligé de passer par SSH et Vim … (je n'aime pas Vim, en premier lieu parce qu'il a été fondé sur l'aberration qu'est le QWERTY aujourd'hui, même si le principe est extrêmement puissant) Et tant soit peu qu'on soit utilisateur de Vim, on se retrouve sans son vimrc … Bref, c'était le petit coup de gueule pour me défouler sur a mauvaise soirée. Effectivement, il y a encore des éditeurs qui ne détectent pas nativement les lignes sans point-virgules, de trouve ça nul, et qu'il faille faire avec, je le comprends et le déplore.
Pour raconter ma vie, j'oublie souvent les point-virgules, et quand je code sur les serveurs de mon école, sans mon vimrc ou autre, je n'ai rien pour me le rappeler, et ça m'énerve. Pour l'examen de première année, on a le choix entre Vim, Emacs et Gedit, configurés au minimum, donc c'est le compilo qui te l'indique, je te laisse imaginer à quel point c'est lourd. Quand je tape en LaTeX, je ne me fatigue pas à encoder mes accents, ils le sont automatiquement, comme ça, je n'ai aucun oubli, aucun problème !
Ce que je souhaiterais, par exemple pour taper une simple ligne comme : « printf("Hello World); », ça serait juste d'appuyer sur : prf + Retour — ou printf( sans autocompletion — + "Hello World" et c'est tout ! et que si j'appuie sur Retour, je n'ai pas de ligne qui s'ouvre au milieu de ma parenthèse parce qu'elle serait fermée automatiquement … mais bon, là, j'en demande peut-être beaucoup, je consent à fermer ma parenthèse si besoin est. Bref, je suis un rêveur.
Et encore une fois, je trouve que l'indentation suffit (en tout cas, me suffit), et j'ajouterai même que je la trouve mieux, car bien plus facilement détectable visuellement qu'un petit caractère en fin de ligne (l'information est directement en début de ligne, ce qui est plus aisé à mon goût). Par ailleurs, on a aussi des numéros aux lignes (obligatoire pour moi), même si c'est vrai que pour 10 indentations, on les associes plus très bien, mais quand même. Merde, quand même ! (Comprenne qui pourra)

Sans rapport mais quand ton commentaire s'affiche dans la page de réponse, il y a une pub EPSON dynamique (javascript) sur le mot « efficace » de ton commentaire, je suis impressionné ! (même si je ne comprends absolument pas d'où ça sort …)

avatar BeePotato | 

« Serieusement, l'absurdité de l'AZERTY de mettre un point-virgule plus accessible qu'un point lol!! »

Ah, ça… C’est un peu comme l’accès privilégié au « ù », lettre si souvent utilisée en français qu’elle méritait bien un tel traitement. :-)
Enfin, au moins les concepteurs du clavier AZERTY Mac n’ont pas considéré que le préfix µ était plus important que le @. On a plus de chance que d’autres. ;-)

« Un simple appuie sur la touche « Retour » et un éditeur un tout petit peu compréhensif suffirait amplement. »

Oh que non ! Il faut plus qu’un éditeur « un tout petit peu compréhensif » pour être en mesure de déterminer si on veut mettre un point-virgule ou non quand on fait un retour à la ligne. Il faut un éditeur capable d’analyser le code qu’on est en train de taper. Rappelons qu’on peut, en C notamment, mettre des retours à la ligne au milieu d’une ligne d’instructions. On peut vouloir le faire, et on ne souhaite pas du tout, dans ce cas, qu’un éditeur vienne nous coller des points-virgules où il n’en faut pas.

« Certes, cela ne vaut que pour l'écriture au fur et à mesure, en ce qui concerne l'insertion d'une ligne, plus besoin d'appuyer sur « Retour », le point-virgule suffit, et on a bien une seule touche, ce qui est mieux (même s'il serait encore mieux de ne pas en avoir selon moi). »

Là aussi, ce n’est pas forcément souhaitable : on ne veut pas toujours un retour à la ligne après un point-virgule, ne serait-ce que dans un for.

« Dans le terminal OS X, si je veux effacer un mot, je ne peux pas appuyer sur Alt + Backspace, mais je peux utiliser Alt pour me déplacer par mot … »

Pareil : les raccourcis standard de Mac OS, à base d’option et commande, me manquent régulièrement dans le terminal.

« Pour l'examen de première année, on a le choix entre Vim, Emacs et Gedit, configurés au minimum, donc c'est le compilo qui te l'indique, je te laisse imaginer à quel point c'est lourd. »

Ça ne me paraît pas lourd du tout, mais c’est peut-être parce que j’ai grandi dans de telles conditions, avec un éditeur qui ne faisait que permettre d’éditer, sans aller jusqu’à assister, et un compilateur qu’on ne lançait qu’une fois de temps en temps tellement ça prenait de temps. :-)
Du coup, dans ces conditions, les points-virgules étaient bien pratiques.

avatar EBLIS | 

"Parce que si le compilateur distingue très bien un caractère fin de ligne, le développeur humain a parfois plus de mal à le faire, notamment s’il a activé dans son éditeur le retour à la ligne automatique pour éviter d’avoir à faire du scroll horizontal."

je ne connais pas ces éditeurs swift mais pour les languages web le numéro de ligne permet très aisément de repérer si on a passé de ligne ou si on est toujours sur la même avec la fonction retour à la ligne et pas de scroll horizontal.

n'est ce pas pareil ici?

avatar BeePotato | 

@ EBLIS : « je ne connais pas ces éditeurs swift mais pour les languages web le numéro de ligne permet très aisément de repérer si on a passé de ligne ou si on est toujours sur la même avec la fonction retour à la ligne et pas de scroll horizontal. »

Je ne parlais pas de l’utilisation d’un éditeur dédié spécifiquement à tel ou tel langage, mais de la possibilité d’utiliser n’importe quel éditeur, même généraliste, même sans affichage des numéros de lignes (oui, ça se fait encore, parfois).
Cela dit, même dans le cas où on affiche les numéros de lignes, ce que je voulais souligner, c’était qu’avec un point-virgule à la fin de la ligne on est sûr tout de suite qu’on est à la fin d’une ligne, sans avoir à faire revenir les yeux à la marge de gauche pour vérifier s’il y a un changement de numéro.
Et quand on est face à deux lignes distinctes, le point-virgule permet de savoir tout de suite que c’est bien volontaire, et non une erreur de copier-coller ou autre chose du genre.

Encore une fois, ce n’est pas grand chose et on peut vivre sans. Mais de là à dire que ça ne sert absolument à rien, je trouve qu’il y a une grosse marge.

avatar Galien | 

Swift est un couche d'abstraction à objective C

avatar C1rc3@0rc | 

Objective-C est un langage qui a beaucoup de qualité, mais qui trainent les défauts intrinsèques du C et notamment sa syntaxe qui favorise les erreurs de programmation les plus courantes et les plus dangereuses.
A ce niveau la syntaxe d'Eiffel ou de Python est une bonne garantie d'élimination des erreurs typiques que provoque le C.

La disparition de la syntaxe du C du monde du développement sera un grand pas en avant pour la sécurité et l'efficacité des programmes

avatar USB09 | 

@joneskind
Swift open source deviendrait un langage universel qui pourrait bien promouvoir le Mac comme machine ultime de développement..

C'est plutôt l'inverse : le Mac n'est fabriqué que par Apple quand un Pc ferait l'affaire.

avatar joneskind | 

@USB09 :

Moi quand je parle d'Apple dans le développement on me rétorque que le problème vient de l'absence de logiciels phare plus que de la machine elle-même. J'ai jamais entendu dire le Mac était un mauvais PC. Donc dans tous les cas le Mac sera toujours un meilleur PC. Les développeurs qui codent aujourd'hui pour iOS et OSX ne se plaignent généralement pas de leur machine. Ce qui me fait dire que beaucoup préfèreraient travailler sur Mac que sur PC.
Personnellement je bosse avec AutoCAD sur Mac. Le logiciel pourrait être 100 fois plus performant sur PC que je quitterai pas mon environnement Mac. Et je pense que ça serait la même chose pour le développement d'app.

avatar Galien | 

Absolument aucun intérêt, passer d'un langage à l'autre n'est pas un gros problème pour un développeur. Un écosystème qui fonctionne bien vaut mieux qu'un outils universel qui ne fonctionne nul part et totalement fragmenté.

avatar aspartame | 

http://glaforge.appspot.com/article/apple-s-swift-programming-language-inspired-by-groovy
sans commentaire ...

avoir une idée de l'implémentation du langage est facile, regardons ailleurs ,
mais ici, on parle bien d'une démarche et d'une volonté de l'éditeur , ce qui est une autre affaire.

avatar BeePotato | 

@ joneskind :

Je rejoins l’avis d’USB09. Je ne vois pas vraiment en quoi une version opensource de Swift pourrait « promouvoir le Mac comme machine ultime de développement ». Qu’y aurait-il de plus sur Mac pour convaincre les développeurs qui n’y sont pas déjà ?
Surtout que le but d’une telle version de Swift serait de permettre des développement en Swift pour d’autres plateformes — il serait du coup plus logique pour les développeurs l’utilisant pour ça d’être sur ces mêmes plateformes, notamment pour faciliter le débugage.

En revanche, rendre Swift opensource, c’est prendre le risque qu’il rencontre un succès tel que le Mac et iOS ne soient plus des cibles prioritaires, ou même importantes, de son développement. Et de le voir évoluer, du coup, dans une direction autre que celle qui serait souhaitable pour Apple.
Et s’il ne rencontre pas un tel succès ? Alors l’intérêt de le rendre opensource n’aura pas été flagrant.

avatar Ali Baba | 

Swift sans Cocoa ça ne servirait pas à grand-chose...

CONNEXION UTILISATEUR