Chris Lattner garde un pied dans le développement de Swift

Nicolas Furno |

Chris Lattner est celui qui a inventé Swift, le nouveau langage de développement d’Apple. En début d’année, il quittait l’entreprise de Cupertino pour aller travailler chez Tesla avant de démissionner à nouveau il y a une semaine. En attendant de savoir ce qui attend ce développeur brillant qui aime manifestement les défis, il était présent au début du mois de juin dans une table-ronde sur Swift en parallèle de la WWDC. À cette occasion, il s’est exprimé sur son départ d’Apple et sur le futur de son langage.

Chris Lattner, troisième en partant de la gauche. Cliquer pour agrandir

Le développeur Ole Begemann a transcrit les passages les plus intéressants de cette apparition en public. Puisqu’il s’agit d’une conférence dédiée aux développeurs, les propos sont très vite techniques et nous n’allons pas évoquer le point de vue de Chris Lattner sur les fonctions dynamiques ou la programmation concurrente. En revanche, point essentiel, il a donné son avis sur le débat entre tabulation et espace.

Le développeur est revenu sur son départ d’Apple, une décision qui a été très difficile à prendre, explique Chris Lattner. Tout en indiquant que c’était la bonne décision pour lui et qu’il n’était plus indispensable dans l’entreprise. Avant même son départ, il ne se chargeait plus vraiment du développement de Swift et son équipe tournait toute seule, et c’est toujours le cas aujourd'hui. Il félicite à nouveau Ted Kremenek qui lui a succédé chez Apple et qui l’avait fait bien avant son départ.

Néanmoins, il ne quitte pas totalement Swift, ce langage qu’il a créé et qu’il aime toujours, assure-t-il. Puisque c’est aussi un langage open-source et que son développement se poursuit en public, il garde un œil sur le projet et participe même quelques fois aux débats. Interrogé sur l’intérêt de la planification des fonctions en public, Chris Lattner reconnaît que ce n’est pas toujours une bonne idée, parce que les retours négatifs peuvent parfois frustrer les développeurs et bloquer les évolutions.

Cela étant, annoncer publiquement les évolutions est le meilleur compromis pour un langage de développement. Il y aura toujours des compromis à faire et il vaut mieux les expliquer en public, justifie Chris Lattner. On sait que le développeur était le principal moteur pour pousser Apple à ouvrir le langage, ce n’est donc pas vraiment une surprise. Au sujet des évolutions de Swift, il salue le changement d’objectif en cours de route pour la quatrième version, celle qui sera finalisée cette année.

Un tout petit bout de notre app iOS, entièrement codée en Swift. Cliquer pour agrandir

Apple voulait à l’origine stabiliser complètement le langage, mais l’entreprise s’est ensuite concentrée sur la stabilité du code source (pour des explications plus complètes, lire : La stabilité, principal enjeu de Swift 4). Un choix logique, face à la quantité de lignes de Swift qui sont écrites chaque jour, la priorité est d’éviter à tous ces développeurs le coût élevé d’une transition. Le passage de Swift 2 à Swift 3 en particulier a été très douloureux et cela devrait aller mieux pour Swift 4, même s’il y aura encore un petit peu de travail.

Chris Lattner a aussi évoqué les origines de Swift, rappelant que c’était un projet personnel, intégré à Apple assez tard et seulement après avoir essayé d’améliorer Objective-C. Dans un premier temps, le développeur cherchait surtout à se changer les idées après avoir écrit un compilateur pour C++ utilisé en interne. Inventer un tout nouveau langage en partant de zéro était une idée plus fun pour lui, et c’est ainsi que tout a commencé.

Les deux objectifs de Swift

Dès le départ, il avait deux ambitions pour Swift : être facile à apprendre, et devenir potentiellement un langage universel. Le premier point explique la création des Playgrounds, ces bacs-à-sable où l’on peut écrire quelques lignes de Swift et voir immédiatement le résultat. Pensée d’abord pour l’iPad, cette fonction a en fait vu le jour côté Mac, mais Swift Playgrounds a permis de concrétiser ce rêve.

Swift Playgrounds permet d’apprendre les bases de Swift sur un iPad, en jouant. Un outil pensé pour les enfants, mais qui peut servir à tout le monde. Cliquer pour agrandir

Lorsque Chris Lattner a commencé à réfléchir à la syntaxe utilisée par Swift, il a également cherché à simplifier au maximum le « Hello World! », ce bout de code qui est utilisé par tous les langages comme point de départ. En Swift, une seule ligne suffit à afficher un message, et elle est extrêmement simple :

print("Hello, world!")

Le deuxième objectif est l’ambition folle de Swift. Dès la présentation du langage, Apple a indiqué qu’il pouvait servir au développement d’apps, mais aussi à l’écriture du noyau d’un système d’exploitation jusqu’aux scripts bricolés par l’utilisateur final. On n’en est pas encore là, mais Chris Lattner maintient cette ambition, précisant que ce sera sûrement dans un futur lointain :

Mon ambition pour Swift a toujours été et est toujours une domination mondiale totale. C’est un objectif modeste. Mais on ne parle pas de Swift 5. C’est un objectif à 10, 15 ou 20 ans.

En attendant, Swift n’a plus besoin de faire ses preuves côté apps, des centaines de milliers de développeurs utilisent déjà le langage et les nouveaux-venus apprennent en général directement à travailler en Swift, sans passer par la case Objective-C. L’autre succès de Swift, c’est du côté des serveurs qu’il faut le chercher.

Apple a rapidement proposé une version compatible Linux de Swift et le succès est au rendez-vous, désormais soutenu par le constructeur. De multiples frameworks existent déjà pour permettre aux développeurs d’apps iOS et macOS de créer des modules nécessaires sur les serveurs en utilisant le même langage que pour leurs apps. Et au-delà de la simplicité, Chris Lattner rappelle que Swift a des arguments à faire valoir en soi, en particulier sa rapidité face à ses concurrents (lire : Sur le serveur, Swift est nettement plus rapide que Node.js).

Vapor, l’un des frameworks qui permettent d’écrire des apps en Swift sur le serveur. Cliquer pour agrandir

Le prochain défi que Chris Lattner aimerait pour Swift ? Remplacer C++, un langage plutôt bas niveau qui date des années 1980 et qui reste largement utilisé pour les fondations des systèmes d’exploitation. Là encore, Swift n’est pas prêt à assumer ce rôle, mais c’est l’un de ses objectifs et son concepteur espère qu’Apple essaiera de l’atteindre.

Il y a encore beaucoup d’informations dans cette transcription de l’intervention de Chris Lattner. Si le sujet vous intéresse, n’hésitez pas à la lire, voire à regarder la conférence en vidéo à cette adresse.

avatar IceWizard | 

@oomu

Tu as raison, l’exemple du print (« Hello, world!) de l’article est particulièrement mal choisi. Un microprogramme de quelques lignes avec des tupples et des dictionnaires aurait été plus convaincant, du moins pour des informaticiens.

avatar oomu | 

"aussi à l’écriture du noyau d’un système d’exploitation jusqu’aux scripts bricolés par l’utilisateur final"

ceci est peu crédible.

Ce n'est pas par nullité que les ingénieurs précédents depuis les années 60 (voir avant théoriquement) ont développés de multiples langages.

ou sinon bien sur on peut jouer sur les mots, en créant des dérivés de swift qu'on nommera tout le temps swift en clignant des yeux

swift.script
swift.rt
etc

avatar C1rc3@0rc | 

«Ce n'est pas par nullité que les ingénieurs précédents depuis les années 60 (voir avant théoriquement) ont développés de multiples langages.»

Par nullité: de temps a autres.
Pour ne pas avoir a gerer des licence: tres souvent.
Par syndrome "not invented here": une bonne majorité du temps.
Par ignorance et non maitrise d'un langage precedent: assez souvent.
Pour une question d'ego: y a des exemples.

En fait on developpe un langage dans 2 cas:
- processus formel scientifique permettant de traduire en instructions executable un modele mathematique.
- bidouillage a partir d'un ou plusieurs langages existants pour faire tourner rapidement des programmes sur un systeme en développement, ce qui permet de tester des trucs ponctuels sans rentrer dans un processus global et analytque.

la premiere categorie est rare, mais extremement robuste et durable (Lisp, ADA).
La seconde c'est la majorité des cas.

Le probleme c'est que les bidouillages temporaires s'accumulants, on arrive a un point ou ça marche tant bien que mal et qu'il faudrait reecrire une masse de programmes, a partir de l'existant. Vu que la plupart du temps ces bidouillage sont incomprehensibles (langage write only), le temps d'analyse et de reecriture depasse les moyens disponibles... alors on normalise la bidouille, puis on la complique pour eviter que les successeurs fassent les memes horreurs et qu'on arrive par les joies de l'entropie a une faille qui de temps a autres produit un resultat satisfaisant.

C'est le principe du C, du Javascript, du PHP, du Perl, du Basic,... et de Swift.

En fait on devrait interdire en phase de développement tout autre langage que Ada, Lisp, Prolog, CaML, C++, Java ou... bash. Pourquoi bash, parce qu'arrivé a plus de 200 lignes le taux de plantages est trop important pour que ça fonctionne, donc faut reecrire souvent dans un des precedents. Et les autres? Parce qu'ils demandent de reflechir avant d'ecrire et surtout de les connaire a fond.

avatar IceWizard | 

@leTroll

"En fait on devrait interdire en phase de développement tout autre langage que Ada, Lisp, Prolog, CaML, C++, Java ou... bash. »

Ada, Lisp ou Prolog pour faire du développement iOS.. Tu portes bien ton nom, toi .. En plus t’es même pas cohérent dans tes incohérences puisque ton fantasme habituel c’est Python. Et là, tu ne cite même pas .. Faut-il croire l’orc claironnant « Python c’est LA solution » ou l’orc affirmant « Ada, Lisp, Prolog » c’est LA solution ?

C’est quand même curieux de voir que les développeurs iOS n’utilisent absolument aucune des solutions que tu préconise aussi largement ..

avatar C1rc3@0rc | 

@IceWizard

Contrairement a toi je ne suis pas dogmatique et maniaque, ni fanatique.
J'ai jamais ecrit que que Python était la panacée ou la perfection; il excelle dans l'education, le scripting et les datasciences et fait du bon boulot dans pas mal de secteurs.
Mais comme a ton habitude tu pars dans des delires ou les propos que tu fais tenir aux uns et aux autres se confondent dans ta tete et tu crois que c'est la realité. C'est un delire et associé a ta megalo et c'est plus qu'inquietant.

Ensuite expliques moi pourquoi techniquement on peut pas produire du code pour iOS avec un langage comme Ada, Lisp ou Prolog ? Tous se compilent, produisent du code C intermédiaire donc compatible avec Objective-C et Swift, tous ont un niveau d’abstraction suffisant pour être indépendant d'une machine particulière...
C'est pas une question de gestion de la memoire, Swift repose sur un garbage-collector.

Je te dirai aussi que Ada et Lisp permettent de programmer des systemes embarqués jusqu'au supercalculateur en passant par a peu pres tous les etages de l'informatique. Il y a meme des framework Lisp pour produire des sites Web (coté serveur).

Sinon, au lieu de faire le troll de reference, (re)lis ce qu'ecrit @oomu et auquel je reponds, tu comprendra peut etre que le propos ne se limite pas a iOS (d'ailleurs Swift ne se limite pas a iOS, au cas ou tu aurais manqué l'info) et que c'est la volonté d’universalité pour Swift qui est critiquée .
Enfin, bon ton propos n'est pas cohérent ni même une question de cohérence c'est un discours haineux et maniaque.

avatar patchoulol | 

@C1rc3@0rc

FYI Swift n'utilise pas de garbage collector. C'est assez énorme d'écrire ça. ?

avatar C1rc3@0rc | 

@patchoulol
Le comptage de reference est une forme de garbage collector, dire que ARC n'est pas un GC est techniquement un non sens. Apres on peut discuter des avantages et inconvenient d'un GC simple comme ARC et d'un plus complexe qui rajoute le "tracing" mais c'est une question d'implementation.

Mais ok, le terme est peut etre trop generique et pas assez precis dans une discussion technique, mais mon propos etait pas d'alller dans la subtilité de realisation du systeme de gestion automatique des attributions memoires mais de dire que la gestion de la memoire en Swift repose sur un systeme automatique comme le fait Lisp, Prolog, etc et que la gestion de la memoire n'est donc pas un obstacle pour programmer iOS avec un langage qui utilise un systeme de gestion automatique de la memoire (donc un GC d'une forme ou d'une autre.)

Si on avait d'un coté un langage comme C ou la gestion de la memoire se fait de maniere explicite et a la main ça pourrait poser un probleme pour programmer un systeme qui repose sur un systeme automatique, encore que. Et inversement. Mais je prends en exemple des langages qui reposent sur des systemes automatiques de gestion de la memoire.

avatar fte | 

@C1rc3@0rc

"Swift repose sur un garbage-collector."

Mvouais. Mais non. Vraiment pas.

Plus haut je parlais des mots compliqués que tu aimes à placer dans ton discours, de façon approximative ou erronée.

Voilà.

On est en plein dedans.

Et donc encore un long discours suspicieux, à relire attentivement en vérifiant chaque affirmation, ou à ignorer entièrement.

avatar fte | 

@C1rc3@0rc

"En fait on developpe un langage dans 2 cas"

Tu oublies au moins 29 autres cas importants.

avatar oomu | 

"Vous pensez qu'il est plus intéressant d'apprendre directement le Swift ou le C/Objective-C ?"

arrêtez de vous formaliser avec le langage !

si vous voulez apprendre la programmation ou développer des applications vous devez apprendre l'ingénierie !

les bonnes pratiques
les paradigmes
les IDE
les méthodes de travail
la programmation objet, fonctionnel, etc
la différence entre pseudo-code, code natif, interprété etc
vous faire une CULTURE.
et oui il vous faudra comprendre la syntaxe de pas 1, ni 2 mais bet et bien des tas et tas de langage
il vous faudra faire du C, parce que le C vous force à vous frotter à la sordide réalité
il vous faudra faire du python ou ruby, perl ou voir php (haha...) parce qu'avoir un truc bien répandu sur serveur vous sera utile pour bricoler un truc client-serveur
il vous faudra faire du javascript, parce 1: c'est simple, 2: c'est basique, 3: c'est très utile pour bricoler un machin web

etc.
il vous faut vous faire un bagage, une boîte à outil.

et surtout Travailler et SOUFFRIR !

avatar fte | 

@oomu

« SOUFFRIR »

Tellement vrai que ça me fait mal d’y penser.

avatar oomu | 

ha et bien sur apprendre objective-C et Swift, vu que l'un est le présent incontournable d'Apple (si votre but est de faire des trucs pour mac et ios bien sur) et l'autre est son avenir.

avatar ovea | 

Un seul langage est important : celui qui est multi paradigmes et dans ce cas, le seul visible est SCALA.

avatar IceWizard | 

@ovea
Non, le seul langage vraiment utile c’est le snorgul 4. Avec ses paradigmes hyperdimensionnels c’est le meilleur outil pour résoudre les interférences quantiques en milieu alcalin. Très rapide à apprendre, en plus, un post-doctorat peut se débrouiller après juste 17 ans de formation. On devrais l’enseigner dés l'école maternelle pour ne pas perturber l’esprit des futurs prix nobels avec des langages de tapettes.

avatar C1rc3@0rc | 

@ovea

«Scala: Object-Oriented Meets Functional»

Moais et Lisp?
Lisp creates FP
Lisp creates OOP
Lisp creates logic programming
Lisp imlements more paradigms, is better, is smarter than successors

Le seul defaut de Lisp: c'est un monde entre parentheses, ou l'infini est un ensemble vide. Seuls les mathematiciens y croient ;)

avatar ovea | 

Difficile d'imaginer comment Apple puisse prétendre s'en sortir en introduisant un kit de dev en IA … sans avoir un langage qui permette d'écrire un «solver» en toute simplicité.

avatar Eurylaime | 

"le développeur cherchait surtout à se changer les idées après avoir écrit un compilateur pour C++ utilisé en interne"

Ca me fait penser à Microsoft qui pousse le C# et qui développe Windows et Office en C++ :-)

avatar ovea | 

Le problème c'est la réécriture à perpétuité d'outils dans tout nouveau langage.

Pour se dire que le problème à résoudre peut l'être par plusieurs méthodes on a besoin de mettre les en concurrence.
Par exemple en décrivant un programme avec des trous (((des variables))) et en essayant de comprendre comment un méta programme peut en trouver les solutions si elles existent.
L'exemple du système d'équations à plusieurs inconnus, dans la plupart des langages demande de partir des possibilité de calcul du langage et de reprendre sa syntaxe pour l'analyser et résoudre ce qu'il est possible de résoudre puis d'étendre le langage avec.

On prendra le C pour son fun (((à l'époque un jeu de mots fort sympathique et «functional»))) LeX et Yacc pour l'analyse du lexique et de la syntaxe.
Mais il faudra voir la mauvaise réputation de programme pour mathématiques en pattern matching pour trouver une évaluation plus gourmande dans certain cas mais plus sûr en général (selon la manière de le formuler tout en restant plus prés de la machine … qui devient virtuelle avec Java(((/C#))) et totalement bridé avec la 3D)

Le C++ a longtemps manqué d'une formulation pour donner tout son sens à la programmation objets, une syntaxe simplifiant la description des objets générique indépendant du type de l'objet évitant de repasser par le pointeur ou par une structure de données mutable.
Objective-C a pris un autre paris difficile de se spécialiser dans un style d'écriture pour la programmation d'interface graphique pour palier au manque du générique de C++ naissant, reflétant ainsi le besoin en programmation par acteurs.
Mais le vrai virage qui n'émerge toujours pas dirait-on fut la programmation de MLDonkey en (Caml qui devint objet avec) OCaml (lui-même repris par Microsoft avec F#,) transposé à Java avec Scala.

La première demande concernant un langage devrait être de pouvoir se décrire et de se réécrire lui-même de façon élégante.
Les interfaces graphiques devrait être considéré comme un de ces langages.
La programmation (fonctionnelle) capable de gérer les entrées/sorties par systèmes de réécritures devrait être considéré comme la consécration de l'état de l'art de programmation en générale, avec une gestion des erreurs intégrée pour un accès granulaire et sécuritaire optimum (avec une messagerie/des notifications, sur le portable des responsables ?)

Et on aurait pas besoin d'avoir cette discussion à propos de Swift à l'effigie d'Apple

avatar ovea | 

Le Playgrounds doit rejoindre les possibilités de prototypage* d'app de XCode.

A) Swift n'a plus d'importance car il s'affiche pour décrire les variables d'ajustement qui serait impossible à découvrir sans faire évoluer l'interface pas à pas (mode Trace) et de réévaluer le code.

B) Là où un gros travail doit être fait pour la pédagogie du langage, c'est de (dé)montrer la simplicité de (ré)écriture pour un langage.
Soit de façon générique avec typage* automatique pour l'aspect général de l'algorithme réutilisable.
Soit par héritage (spécialisation) … quoi que ce mécanisme objet ne soit pas très «fun» syntaxiquement*

B) Quel langage permet une écriture des échanges entre acteur simplissime* ?
Note : c'est la base du codage de l' interface utilisateur.

*encore un mot non présent dans le dictionnaire Apple
Comment peut-on utiliser un langage, informatique où pas, si le lexis n'est pas à jour ?

avatar ovea | 

Ça a des relent de discussion avec l'éditeur de la revue les «Topiques Pascal» sur le bien fondé du PASCAL comparé au C.

La clarté comparée à la rapidité … d'écriture.
Le didactique comparé au fun(ctional)
Un débat sans fin sous les clochers … sur la syntaxe quant à la sémantique utilisateur.

Alors parlerons nous ici du COBOL ou du λ-calcul ?

Aucune importance : le seul truc c'est la réécriture et le control de cet réécrire.
Préprocesseur*, compilation, édition de lien, interpréteur*, typage* statistique … réécriture sur les périphériques à effets de bord,
à comparer à la programmation objet.

L'inférence de type rend obsolète le débat sur la gestion prise de tête du polymorphisme en objet.

Swift fait il de l'inférence de type ?
Si oui, il est au top des language rendant obsolète le débat sur les langages en permettant de spécifier le langage le plus à même de décrire et donc de résoudre un problème spécifique.

* absent pour le préprocesseur de correction lexical, dit dictionnaires de la langue pour le français d'Apple.

avatar Nico S | 

Vous êtes rigolos avec vos batailles mais au lieu de vous battre à coup de mots, montrez-nous plutôt ce que vous avez réalisé avec tel ou tel langage.

C'est un peu comme un musicien qui passerait son temps à défendre le mode locrien sans qu'on ne l'entende jamais jouer.

Pages

CONNEXION UTILISATEUR