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 heret | 

2 pages de commentaires de gars qui n'ont rien compris.
Swift est plus léger qu'Obj-C et par conséquent, alors qu'en Obj-C + Cocoa on ne peut pas se passer du C dans certains cas à cause de la lourdeur d'Obj-C, on pourra s'en passer en Swift. Sous entendu, tous les morceaux des bibliothèques qui sont encore en C pourront être réécrits en Swift.
Pour tout dire, j'ai été plutôt surpris quand dans un développement pour iOS, j'ai du programmer en C natif parce que le sous-sytème utilisé n'avait pas d'API en Obj-C.

Autre remarque : enrichissez votre vocabulaire et votre pensée en arrêtant d'utiliser le mot "code" à tout bout de champ.

avatar marc_os | 

@heret:
Ne te rappelles-tu pas qu'Unix a été écrit en C ?
Et tu proposes quoi pour remplacer le mot "code" ?

avatar BeePotato | 

@ heret : « Pour tout dire, j'ai été plutôt surpris quand dans un développement pour iOS, j'ai du programmer en C natif parce que le sous-sytème utilisé n'avait pas d'API en Obj-C. »

C’est pourtant parfaitement normal et une des forces d’Objective C : c’est une extension du C, qui permet du coup d’utiliser sans aucun problème des bouts de code ou des API en C quand on en a besoin.
Sans aucun problème, mais aussi sans aucun complexe : tout n’a pas besoin d’être développé en orienté objet, et quand il y a quelque chose de déjà très efficace qui est disponible en C, autant pouvoir l’utiliser directement sans avoir à le réécrire ou à écrire une surcouche.

Notons d’ailleurs que les développeurs de Swift ont fait en sorte de faciliter l’appel à des fonctions C depuis Swift (sans que ce soit aussi direct et transparent que depuis Objective C).

avatar robrob | 

@BeePotato
Mouais je suis pas vraiment convaincu que ce soit une force d'Objective C.
Avec ARC les choses se sont beaucoup simplifiees mais quand j'ai commence le dev sur OS X, je me suis retrouve avec du code qui utilisait des bibliotheques C, C++ et des APIs OS X qui utilisaient les CFRetain et CFRelease.
Resultat 4 modeles de gestion memoire: malloc en C, new en C++, CFRetain/CFRelease et retain/release + autorelease pools.

Ca aurait ete une force d'objective C avec la possibilite de tout gerer via la gestion memoire objective C, comme on le fait en C++ avec new. Mais a ce niveau ca ressemblait plus a du bricolage.

avatar BeePotato | 

@ robrob : Rassure-toi, j’ai connu cette époque aussi.
Et ça ne faisait en fait que trois modèles de gestion de mémoire, CFRetain/CFRelease et retain/release fonctionnant suivant le même modèle. ;-)

Et franchement, je n’ai jamais vu là quoi que ce soit de choquant : quand on mélange les langages et les frameworks, on suit ce que chacun fait en la matière. Rien de plus normal.
Ce qui aurait bien plus ressemblé à du bricolage, ça aurait été justement de chercher à masquer tout ça derrière un système unifié qui aurait probablement montré assez vite des faiblesses.

avatar robrob | 

@BeePotato
C'est le meme concept mais ils n'etaient pas interchangeables.
Tu ne pouvais pas faire un release sur un CFRetain.
Sachant qu'Objective C est une surcouche de C il aurait ete logique d'ajouter la possibilite de faire des retain/release sur un array, de la meme maniere que C++ a redefini l'allocation memoire avec new. Ce qui fait qu'on peut utiliser du code C en C++ et seulement utiliser new et ne jamais avoir a utiliser malloc et free.

avatar BeePotato | 

@ robrob : « C'est le meme concept mais ils n'etaient pas interchangeables. Tu ne pouvais pas faire un release sur un CFRetain. Sachant qu'Objective C est une surcouche de C il aurait ete logique d'ajouter la possibilite de faire des retain/release sur un array »

Quand je parlais de modèle, je faisais référence au modèle conceptuel (les principes à apprendre pour savoir gérer la mémoire correctement avec tel ou tel langage ou framework, quoi). De ce point de vue, les comptages de références de CoreFoundation et de Cocoa, reposant bien sur la même logique, ne nécessitent d’apprendre qu’une fois leurs principes de base, qui sont ensuite réutilisés pour les deux frameworks.

Mais en fait, pour les types de CF/Cocoa dit « toll-free bridged », il est bel et bien possible d’utiliser CFRetain/CFRelease et retain/release de manière interchangeable. C’est notamment le cas pour CFArray et NSArray, depuis le tout début de Mac OS X.
On peut tout à fait affecter la valeur d’un CFArrayRef à une variable de type NSArray*, puis envoyer un retain ou un release à cette dernière, au lieu d’appeler CFRetain ou CFRelease avec le CFArrayRef en argument.
C’est bien pratique par moments.

avatar Orus | 

Apple veut même controler le langage de programmation... Big Brother il devient.

avatar BeePotato | 

@ Orus : « Apple veut même controler le langage de programmation... »

Mais encore ?

avatar polaroid62 | 

marc_os 16/12/2015 - 14:49
@ françois bayrou
Ben oui, pour planter des choux, il faut savoir tracer un ligne droite !
Le calcul, donc les maths, la langue, l'histoire, l'art sont à la base des civilisations, de l'humanité elle même.
Par contre la programmation... c'est une technique d'ingénieur, un outil de fabrication.
Pôle emploi a dépensé des fortunes en formations de chômeurs pour en faire par exemple des "web master". La vaste blague ! Des gens formés en quelques mois, venant de domaines n'ayant rien à voir sont sensés se présenter aux mêmes postes que des gens issus d'écoles d'ingénieurs ou venant de la fac. Inutile (j'espère) de dire que leurs chances sont minimes.
Mais en a des instituts tel l'Ifocop que ça ne dérange pas, bien au contraire. Ils encaissent l'argent public pour former des gens à être chômeurs.

Je n'espère pas forcément sur que certains vont droit dans le mur mais j'en connais qui ont réussi dans le dev sans être ingénieur et plus qu'on ne croit ,c'est une maladie française de sous-employer des bac+5 dans certaines entreprises. Sur que former en quelques mois c'est illusoire j'en ai fait l'expérience mais si tu es motivés il y a moyen d'apprendre à coté mais pour certains tu n'auras pas le sacro saint papier alors que tu seras j'ose le dire plus compétant que certains ingénieurs qui n'ont fait que du bachotage et n'ont aucun amour du dev. Une formation en Ruby comme propose "le Wagon" bah je peu certifier que ça marche sur les plus motivés et qu'ils trouvent un poste . Les formations de webmaster peuvent être une perte de temps tout comme elles peuvent être un tremplin , à charge de continuer son apprentissage par un biais communautaire notamment qui permet de se constituer un réseau si vous voyez où je veux ou venir.

Pages

CONNEXION UTILISATEUR