Pour Craig Federighi, Swift peut remplacer le langage C à terme

Nicolas Furno |

Dans sa tournée médiatique effectuée à l’occasion de l’ouverture de Swift, Craig Federighi est passé chez John Gruber. Le célèbre blogueur tient aussi un podcast hebdomadaire, simplement nommé The Talk Show, et c’est à l’occasion de l’épisode 139 que le senior vice-président en charge du software chez Apple a répondu à ses questions. Une trentaine de minutes d’entretien, avec quelques considérations générales, mais aussi des points plus techniques.

Craig Federighi, lors d’un keynote de WWDC
Craig Federighi, lors d’un keynote de WWDC

Craig Federighi est revenu au cours de cette interview sur la naissance du langage chez Apple. On sait que le projet était à la base l’œuvre d’un seul homme, Chris Lattner, avant d’être adopté par l’entreprise et développé pour devenir le langage de programmation qu’il est aujourd’hui. L’histoire complète de ce développement est disponible sur GitHub, mais le SVP indique que le désir de le rendre open-source a toujours été présent chez Apple.

Il y a bien eu des débats en interne, mais plutôt pour choisir la date de l’ouverture, pas pour savoir si Swift allait être un langage propriétaire ou non. Craig Federighi peut très bien arranger la réalité sur ce point, mais il fait remarquer qu’il y avait déjà plusieurs projets open-sources menés par Apple, de WebKit (moteur d’affichage de Safari) à Clang et LLVM (compilateur de code). Par ailleurs, il n’y avait aucun inconvénient majeur à ouvrir le code source du langage : Swift sera utilisé sur des produits qui ne sont pas vendus par Apple, c’est aussi tout l’intérêt. Et peut-être même qu’il y aura des projets qui mèneront Swift loin des intérêts d’Apple, mais ça n’est pas gênant.

Il rappelle par ailleurs tous les avantages liés à cette ouverture. Ils ont déjà été évoqués à plusieurs reprises, mais Craig Federighi insiste sur deux d’entre eux : l’utilisation possible dans les serveurs et l’éducation. Pour le premier point, l’inspiration est venue d’IBM qui a adopté Swift pour ses applications mobiles et qui a très vite demandé une solution pour utiliser ce code sur les serveurs. Mais en interne aussi, les équipes en charge d’iCloud ont cherché à exploiter le langage pas seulement dans iOS et OS X, mais aussi sur les serveurs. Qui, comme partout ailleurs, tournent sous Linux chez Apple.

IBM propose déjà une fonction similaire au « Playground » de Xcode, mais dans un navigateur. Un projet impossible sans l’ouverture de Swift à Linux.
IBM propose déjà une fonction similaire au « Playground » de Xcode, mais dans un navigateur. Un projet impossible sans l’ouverture de Swift à Linux.

Avoir le même langage dans son application mobile et sur le serveur, composant souvent essentiel d’une app aujourd’hui, est un avantage indéniable. Le patron du logiciel chez Apple évoque l’obligation, jusque-là, de maîtriser deux langages totalement différents (Objective-C et Java, par exemple) pour couvrir tous les besoins. En apprenant uniquement Swift, un développeur devrait désormais pouvoir s’en sortir partout, du client à l’arrière-boutique sur le serveur.

Cette aptitude à servir à des fins très différentes est un autre élément clé pour comprendre Swift. Dès le départ, Apple a donné un objectif extrêmement ambitieux : proposer un langage capable de développer le noyau d’un système d’exploitation, une application ou même un script. Swift n’y est pas encore, mais l’interview permet de comprendre en quoi cela devrait être possible. La réponse de Craig Federighi est assez technique, mais on peut la résumer ainsi : la syntaxe est suffisamment simple pour être utilisée pour un script, mais ses bases sont suffisamment solides pour offrir la même performance qu’un langage de bas niveau, comme C.

D’ailleurs, Apple espère à terme remplacer totalement C ou C++ et n’utiliser que du Swift. Le blogueur et son invité rappellent que ce n’est pas possible avec Objective-C : pour les fonctions les plus gourmandes, il est souvent nécessaire de repasser à C ou C++ si l’on veut bénéficier des meilleures performances. La différence est que le nouveau langage d’Apple est moins dynamique que son prédécesseur et tout se fait, pour Swift, au moment de compiler le code source, pas quand l’application tourne. Ce côté statique permet d’optimiser au mieux le code final et de gagner en performances, mais aussi en stabilité.

John Gruber a interrogé son interlocuteur sur l’adoption de Swift en interne, et la réponse de Craig Federighi n’évacue pas les résistances qu'il y a. Certains développeurs conservent leur attachement à l’Objective-C, quand d’autres s’y intéressent de plus en plus. Et puis même ceux qui veulent faire du Swift ne le peuvent pas toujours : la compatibilité avec les applications 32 bits, toujours assurée dans OS X, oblige des pans entiers à rester en Objective-C, puisque Swift n’est prévu que pour du 64 bits. En passant, c’est peut-être une manière d’annoncer l’arrêt du 32 bits sur Mac… pour OS X 10.12 ?

Quand c’est possible, Apple développe en Swift plutôt qu’en Objective-C. Outre l’équipe d’iCloud, une partie d’OS X El Capitan a été écrite en Swift, en l’occurence toutes les nouvelles fonctions liées à la gestion des fenêtres, comme Split View. Les développeurs ont commencé par coder uniquement ces fonctions en Swift et ils ont ensuite entrepris un gros chantier pour convertir tout le code Objective-C.

C’est la force de Swift, rappelée au cours de l’interview : on peut l’utiliser en même temps qu’Objective-C. Ce qui permet à de gros projets de se mettre au nouveau langage, tout en continuant à accéder et modifier le reste du projet, resté avec l’ancien langage de programmation. Craig Federighi glisse même que certaines équipes n’utilisent Swift que pour des tests unitaires, ce qui montre bien qu’on est encore loin d’un passage complet à la nouveauté, mais plutôt à un déploiement très progressif.

Au-delà de ses propres besoins, Apple espère que Swift deviendra le langage de référence pour l’éducation. C’est un point que le SVP avait déjà soulevé lors des premières interviews données à la presse et il insiste à nouveau sur ce sujet avec John Gruber. Il y a déjà de nombreux cours basés sur Swift, mais ce sont des cours spécialisés pour apprendre à développer des applications mobiles. Ce qu’espère le constructeur, c’est que Swift pourra devenir un langage de référence pour apprendre à coder tout court. Et pour cela, il doit être open-source : voilà un argument de plus, glissé par Craig Federighi.

Le Playground de Xcode, une interface parfaite pour apprendre le Swift. Depuis le début, Apple a beaucoup insisté sur l’aspect pédagogique de son langage.
Le Playground de Xcode, une interface parfaite pour apprendre le Swift. Depuis le début, Apple a beaucoup insisté sur l’aspect pédagogique de son langage.

Si les questions les plus techniques, sur les différences entre Objective-C et Swift notamment, vous intéressent, l’interview est disponible intégralement en audio ou en texte.

avatar capitainenemo | 

Lol. Très long terme alors.

avatar sapropelet (non vérifié) | 

À Terme peut-être mais pas ici...

avatar Lonesome Boy | 

Swift me semble également parfait pour l'éducation: très simple et "syntaxiquement" léger pour apprendre les bases, puissant pour les choses plus complexes, "polymorphe" en ce sens qu'on peut très bien programmer en procédural ou en orienté objet (et même en "orienté protocole", concept on ne peut plus intéressant: quasiment la puissance de l'objet sans la lourdeur et la complexité inutiles de l'objet pour 90% des tâches), performant et open source.

Bref, si je devais enseigner la programmation en général aujourd'hui à quelqu'un, je choisirais Swift.

Le seul défaut réel que je lui vois est son dictionnaire, que je trouve plutôt épais, et certaines subtilités associées: difficile de connaître par cœur l'ensemble des règles derrière chacun des mots du langage. Mais bon, tant qu'on peut se contenter d'en utiliser qu'une petite partie pour arriver à réaliser proprement et élégamment ce que l'on souhaite, ce n'est pas si grave.

avatar MacTHEgenius | 

L'orientée protocole consiste en quoi ? Je suis curieux...

avatar BeePotato | 

@ MacTHEgenius : « L'orientée protocole consiste en quoi ? Je suis curieux... »

Le mieux est de regarder la vidéo de la session 408 de la WWDC 2015 pour une présentation complète de cette idée.
Mais en gros, il s’agit de se focaliser sur l’héritage de comportements (d’ailleurs, je trouve qu’il aurait été plus pertinent de parler de « programmation orientée comportement » plutôt que de se focaliser sur les protocoles, qui ne sont qu’un détail d’implémentation) plutôt que sur l’héritage d’état. Le tout étant formalisé via l’usage de protocoles et la possibilité, depuis Swift 2, de définir dans un protocole (ou dans une de ses extensions) des implémentations par défaut des méthodes qu’il déclare.
Du coup, dans cette approche, une classe tire sa partie « état » d’une seule source (héritage depuis une autre classe) mais peut enrichir sa partie « comportement » (son jeu de méthodes) en allant puiser dans divers protocoles. Partie « comportement » qui peut même se trouver enrichie après coup via des extensions de ces protocoles.
Et surtout, on est incité à se focaliser bien moins sur le type d’un objet que sur ce qu’il est capable de faire (ses méthodes, vues via les divers protocoles adoptés par l’objet).
Je ne sais pas si mon explication est bien claire. :-)

Quoi qu’il en soit, ce n’est pas une idée fondamentalement nouvelle — ça revient même aux bases de la programmation orientée objet (dans l’esprit du « duck typing »), telles que définies avant qu’on ne s’égare un peu avec le C++.
Et c’est sans doute déjà réalisable dans d’autres langages. Mais Swift, avec ses protocoles, extensions de protocoles, et leurs implémentations par défaut, facilite beaucoup la mise en place de cette approche, ainsi (voire surtout) que son respect (grâce à l’absence d’héritage multiple d’état). La création du terme « programmation orientée protocole » permet surtout de communiquer plus facilement sur le fait que c’est l’approche à privilégier pour le développement en Swift.

avatar heret | 

Super, tu as découvert les interfaces de Java, C# et l'équivalent en Obj-C : les protocoles. Adieu héritage et bonjour duplication de code...

avatar BeePotato | 

@ heret : « Super, tu as découvert les interfaces de Java, C# et l'équivalent en Obj-C : les protocoles. Adieu héritage et bonjour duplication de code... »

Bonjour, M. Je-sais-tout. :-)

Alors, pour remettre dans l’ordre chronologique, ce serait plutôt les protocoles d’Objective C et leurs équivalents en Java et C : les interfaces. :-P
Mais fort heureusement pour moi et pour cette conversation, je ne les ai pas découverts aujourd’hui, ce qui m’a permis de les utiliser depuis une vingtaine d’années (pour la version Java ; j’avoue que j’ai attendu de passer à Mac OS X pour me mettre à Objective C et à ses protocoles). ;-)

D’autre part, la partie que tu as manifestement ratée dans mon explication à MacTHEgenius, c’est cette caractéristique de Swift que tu sembles ne pas connaître : la possibilité de définir, au sein d’un protocole ou via une extension d’un protocole, une implémentation des méthodes déclarées par le protocole.
Implémentation qui servira d’implémentation par défaut pour les types adoptant ce protocole.

C’est ce mécanisme qui permet de définir ce que j’ai appelé un « héritage de comportement » — en ce sens qu’on hérite de méthodes (ou de propriétés calculées), mais pas d’un état (représenté par les propriétés stockées). Il n’y a, du coup, évidemment pas de duplication de code, sinon je n’aurait bien évidemment pas parlé d’héritage.
Il reste bien sûr, comme dans tout héritage, la possibilité de spécialiser ce dont on hérite, en en réimplémentant une partie dans la classe ou la structure.

Enfin, ça facilite aussi l’ajout de code à un type préexistant, en déclarant via une extension l’adoption d’un protocole par ce type. Ce qui permet, là aussi, d’éviter certains cas de duplication de code.

La prochaine fois, merci donc d’essayer de lire complètement ce que j’écris, voire d’aller consulter la documentation que j’ai mentionnée, avant de me répondre en partant de l’a priori que je suis une bille en programmation. ;-)

avatar MacTHEgenius | 

Super merci ! Ça a l'air très intéressant ! Je vais aller voir la vidéo que tu recommandes ;)

avatar sapropelet (non vérifié) | 

3h20 d'interview combien il a dû payer pour avoir ça ?

avatar jackhal | 

Ah ouais, ok. Je me suis dit : "tiens ça va faire comme avec Schiller, ça va être un épisode court".
Bon... 3h20... pas ce soir, finalement.

Sinon je me demande qui devrait payer, dans ta question : J Gruber pour faire une interview aussi longue d'un cadre d'Apple, ou Apple pour que l'un des cadres distille le message qu'ils souhaitent concernant ce qu'ils font en ce moment ?

avatar Seccotine | 

Le podcast dure 3h20 mais l'interview de Craig n'est que le premier segment de ce podcast et dure un peu plus de 30 minutes.

avatar occam | 

Quand R me permettra d'utiliser Swift sur OS X au lieu de clang et F77 pour compiler mes packages (tâche presque journalière), alors oui, Swift aura remplacé C.
C'est pas demain la veille.

avatar Nicolas Furno | 

Comme précisé dans l'article, l'interview de Craig ne dure qu'une demi-heure. La suite, c'est avec Siracusa.

avatar iapx | 

Bien sûr, Swift aussi rapide que le C, comme Java :)

avatar capitainenemo | 

@iapx Et comme le python ! ;)

avatar hawker | 

Comme langage simple pour l'education, il y a deja le python qui est tres bien pour ca et qui est tres repandu.
Le mec veux juste creer des apple addicts/dependant en commencant le traitement au plus tot..

Quand a vouloir remplacer C, sachant que osx est base sur Unix, c'est un peu l'hopital qui se fout de la charité..

Enfin s'ils y arrivent, je m'y met direct, mais bonne chance.

avatar MacTHEgenius | 

@hawker :
L'évolution reste en marche même pour l'informatique. Remplacer le C et C++ serait juste logique pour Apple, déjà que ce sont des langages vieillissants avec plusieurs défauts, pour créer une bonne synergie dans l'entièreté de l'écosystème d'Apple.

Garder ces deux vieux langages est une erreur, même s'ils ont fait leurs preuves à long terme.

--

Moi-même ai remarqué que le Swift inclut beaucoup de fonctionnalités bien pratiques de plusieurs langages (Java, Python, C++ pour ne nommer qu'eux). À la longue, quand je reviens en Java ou C++, je me dis que certains bout de codes auraient été plus simples en Swift.

avatar robrob | 

@MacTHEgenius
"Garder ces deux vieux langages est une erreur, même s'ils ont fait leurs preuves à long terme."
Ces "vieux" langages sont des outils qui doivent etre utilises pour les bons problemes.
Il ne sert a rien de coder l'interface graphique d'une app en C. De meme Swift ne permettra pas de faire de l'optimisation bas niveau.
Alors oui dans les API de OS X et iOS il y a beaucoup de code qui n'a plus sa place en C. De meme il y a plein d'APIs qui auraient du etre portees en objective C plutot que garder leurs appels C. C'est donc logique de passer en Swift maintenant mais ca ne montre en aucun cas une faiblesse des langages C ou C++.

avatar marc_os | 

@robrob :
Pardon mais tu a écrit beaucoup de C ou de C++ ?
J'ai pas l'impression...

avatar robrob | 

@marc_os
haha pardon? Je suis dev C++ avec des annees d'experience. En quoi mon message te fait douter que je code en C ou C++?

avatar marc_os | 

@ robrob : Oups, désolé je crois que je n'ai pas répondu au bon commentaire tout à l'heure. (Le petit écran de l'iPhone 4 et la présentation linéaire des commentaires sur l'App n'aident pas).

avatar Sostène Cambrut | 

@hawker

Créer des Apple addicts avec un langage open source ? T'es un petit malin toi dis donc ^_^

avatar melaure | 

@Sostène Cambrut :

Open source mais créé par Apple ... En dehors des leurs produits qui utilise du swift ?

avatar Un Type Vrai | 

PHP + Zend ...
Java + Sun
C + BSD
C# + Microsoft

En dehors de Microsoft, Sun, Berkeley et Zend, je pense trouver quelques exemples de choses faite en C#, PHP, Java, C ...

CQFD.

Next

avatar marc_os | 

@Un Type Vrai :
Ah bon, BSD c'est une entreprise comme Sun, Zend ou Microsoft ?
:-D

Pages

CONNEXION UTILISATEUR