Interview de Larry Wall

Larry Wall est un homme fascinant. Il est le créateur du Perl, un langage de programmation largement considéré comme le ciment qui maintient Internet, mais raillé par certains comme étant un langage « en écriture seule », en raison de sa densité et de l'utilisation abondante de caractères non alphanumériques. Larry a aussi une formation en linguistique et il est bien connu pour ses présentations divertissantes sur l'avenir de Perl, connues sous le nom de « State of the Onion » (« L'état de l'oignon ») (1).

Au FOSDEM 2015 de Bruxelles, nous avons discuté avec Larry afin de lui demander pourquoi Perl 6 a pris autant de temps (Perl 5 est sorti en 1994), combien il est difficile de gérer un projet où tout le monde a des opinions fortes et tirant dans des directions différentes, mais aussi comment son expérience en linguistique a influencé la conception de Perl dès le départ. Préparez-vous à des digressions fascinantes…

LinuxVoice : Vous avez eu jadis l'idée d'aller chercher quelque part dans le monde une langue non documentée et de créer un système d'écriture pour elle, mais vous n'avez jamais eu la possibilité de réaliser ce plan. Est-ce quelque chose que vous souhaitez reprendre et faire maintenant ?

Larry Wall : Il faut être plutôt jeune pour réussir à accomplir une telle tâche ! Cela implique effectivement beaucoup de travail acharné et les organisations qui s'en occupent n'ont pas tendance à prendre des gens qui ont un certain âge. En partie, parce que la santé et la vigueur de ceux-ci sont en train de diminuer, mais aussi parce que les gens apprennent beaucoup plus facilement de nouvelles langues quand ils sont plus jeunes, et il faut apprendre la langue avant de créer un système d'écriture pour elle.

J'ai commencé à essayer d'apprendre le japonais il y a environ 10 ans et je pourrais le parler assez bien, grâce à ma formation en phonologie et en phonétique, mais j'ai beaucoup de mal à comprendre ce que l'on me dit. Je peux donc aller au Japon et demander mon chemin, mais je ne comprendrai pas vraiment les réponses !

« Avec Perl 6, nous avons trouvé certaines façons de rendre l'ordinateur plus sûr de ce que l'utilisateur veut dire. »

Donc généralement, apprendre une langue assez bien pour développer un système d'écriture, et arriver à maîtriser cette langue, au moins au niveau conversationnel, prend un certain nombre d'années avant d'en arriver au point où vous pouvez réellement faire de l'alphabétisation et commencer à éduquer les gens au sujet de leur propre culture, pour ainsi dire. Ensuite, vous leur enseignez à écrire aussi au sujet de leur propre culture.

Bien sûr, si vous avez des assistants de langue (et l'on nous a dit de ne pas les appeler « informateurs de langue », sinon tout le monde penserait que nous travaillions pour la CIA !), si vous avez ces personnes, vous pouvez les faire venir pour vous aider à apprendre la langue étrangère. Ils ne sont pas des enseignants, mais il y a moyen d'apprendre des choses de quelqu'un qui n'est pourtant pas un professeur de langue — ils peuvent quand même vous apprendre à parler. Ils peuvent prendre un bâton, vous le montrer et dire « c'est un bâton », puis le lâcher et dire « le bâton tombe ». Ensuite, vous commencez à écrire et à systématiser les choses.

La motivation de la plupart des gens qui participent à ces groupes est de traduire la Bible dans ces langues. Mais il y a un autre objectif : préserver leur culture. Les missionnaires ont plutôt mauvaise réputation à ce sujet, parce que les anthropologues pensent qu'il faudrait laisser ces gens tranquilles dans leur propre culture. Mais quelqu'un va probablement changer leur culture de toute façon — en général, il s'agit de l'armée, ou des entreprises qui s'y installent, comme Coca-Cola ou ateliers de confection, ou des missionnaires. Et parmi ces trois, les missionnaires sont les moins dommageables, s'ils font leur travail correctement.

LinuxVoice : Plusieurs systèmes d'écriture sont basés sur des alphabets existants, et vous avez aussi ceux qui ont été inventés, comme le groenlandais…

Larry Wall : Les Cherokee ont inventé leur propre système d'écriture juste en copiant des lettres, et ça ne correspond pas vraiment à ce que nous pensons de ces lettres, et ceci est assez arbitraire dans ce sens. Cela représente juste le concept que les gens ont de la langue, et suffisamment bien pour communiquer. Il y aura souvent des variations par rapport à l'orthographe occidentale, en utilisant des caractères latins lorsque c'est possible. Les langues tonales doivent marquer les tonalités d'une manière ou d'une autre, en utilisant des accents ou des nombres.

Dès que vous commencez à pencher vers une représentation phonétique ou phonologique, vous commencez également à perdre les différences dialectiques, ou vous devez écrire les différences dialectales. Ou alors vous avez l'orthographe conventionnelle, comme nous l'avons en anglais, mais la prononciation qui ne correspond pas vraiment.

LinuxVoice : Lorsque vous avez commencé à travailler sur Perl, qu'avez-vous pris de votre formation linguistique qui vous a fait penser : « ceci est vraiment important dans un langage de programmation » ?

Larry Wall : J'ai beaucoup réfléchi à la façon dont les gens utilisent les langues. Dans les langues réelles, vous disposez d'un système de noms, de verbes et d'adjectifs, et vous savez plus ou moins quels mots correspondent à quel type. Et dans les langues naturelles réelles, vous avez beaucoup d'occasions d'insérer un mot dans un endroit différent. La théorie linguistique que j'ai étudiée a été appelée tagmémique et décrit ce fonctionnement dans une langue naturelle — où vous pouvez avoir un mot que vous considérez comme un substantif, mais vous pouvez le transformer en verbe, et les gens font cela tout le temps.

Vous pouvez très bien insérer n'importe quel mot dans n'importe quel emplacement et vous pouvez communiquer. Un de mes exemples préférés montre l'insertion d'une phrase entière comme adjectif. Il s'agit de : « Je n'aime pas votre attitude Je-peux-utiliser-tout-comme-un-adjectif » !

Ainsi, une langue naturelle devient très flexible, parce que vous avez un auditeur très intelligent (au moins, par rapport à un ordinateur), qui comprendra en cas d'ambiguïté ce que vous avez voulu exprimer. Bien sûr, dans un langage informatique, vous devez gérer l'ambiguïté beaucoup plus rigoureusement.

Sans doute n'avons-nous pas toujours géré tout cela suffisamment bien dans les versions 1 à 5 de Perl. Parfois, l'ordinateur était confus quand il ne devrait vraiment pas l'être. Avec Perl 6, nous avons trouvé certaines façons de rendre l'ordinateur plus sûr de ce que l'utilisateur veut dire, même si l'utilisateur ne sait lui-même pas très bien si une variable est en fait une chaîne de caractères ou un nombre. L'ordinateur connaît le type exact de celle-ci. Nous avons imaginé des façons d'avoir un typage plus fort en interne, mais gardons l'esprit allomorphe « vous pouvez utiliser ceci comme étant cela ».

LinuxVoice : Pendant longtemps, Perl a été considéré comme le langage « liant » de l'Internet, pour en conserver tous les éléments ensemble. Voyez-vous Perl 6 comme une version pour satisfaire les besoins des utilisateurs existants, ou comme un moyen d'attirer de nouveaux utilisateurs et de susciter un regain du langage ?

Larry Wall : Le but initial était d'offrir un langage Perl meilleur aux programmeurs Perl. Mais en examinant certaines déficiences de Perl 5, il est devenu évident que si nous corrigeons ces déficiences, Perl 6 serait beaucoup plus applicable, comme je le disais dans mon exposé - dans le sens du mot applicabilité dont parlait J. R. R. Tolkien [voir http://tinyurl.com/nhpr8g2].

L'idée que « les choses faciles doivent être faciles et les choses difficiles doivent être possibles » remonte à loin, à la transition entre Perl 2 et Perl 3. En Perl 2, nous ne pouvions pas gérer des données binaires ou des valeurs ASCII 0 — il y avait juste des chaînes du style du C. Je disais alors : « Perl est juste un langage de traitement de texte — vous n'avez pas besoin de ces choses dans un langage de traitement de texte ».

Mais je me suis aperçu à l'époque qu'il y avait un grand nombre de problèmes dus principalement au texte qui contenait un peu de données binaires — des adresses réseau et des choses de ce genre. Vous utilisez des données binaires pour ouvrir le socket, mais du texte pour le traiter. Donc, l'applicabilité du langage a plus que doublé en lui permettant de traiter des données binaires.

Cela a démarré un compromis à propos de ce qui devrait être facile dans un langage. À présent, nous avons dans Perl un principe, et pour cela nous avons volé l'expression « codage Huffman » des systèmes de codage binaires où vous avez des tailles différentes pour les caractères. Les caractères communs sont encodés sur un nombre plus petit de bits et les caractères les plus rares sont encodés sur un nombre plus élevé de bits.

« Cela devait être un exercice d'équilibre très prudent. Il y avait tellement de bonnes idées au début. »

Nous avons volé cette idée comme un principe général de Perl, pour des choses qui sont couramment utilisées, ou lorsque vous avez à les taper très souvent — les choses communes doivent être plus courtes ou plus succinctes. Un autre aspect, cependant, c'est qu'il leur est permis à être plus irrégulières. Dans les langues naturelles, ce sont en fait les verbes les plus couramment utilisés qui ont tendance à être les plus irréguliers.

Et il y a une raison à cela, parce que vous avez besoin de mieux les différencier. Un de mes livres préférés est « La recherche de la langue parfaite dans la culture européenne » par Umberto Eco, et il ne concerne pas les langages informatiques ; il est au sujet de langues philosophiques, et l'idée globale c'est que peut-être une certaine langue ancienne était la langue parfaite et nous devrions revenir à celle-ci.

Tous ces langages font l'erreur de penser que les choses similaires doivent toujours être encodées de manière similaire. Mais ce n'est pas ainsi que vous communiquez. Si vous avez plusieurs animaux de basse-cour, et ils ont tous des noms similaires, et vous dites « allez tuer le Blerfoo », mais en fait vous voulez qu'ils tuent le Blerfee, vous pourriez vous retrouver avec une vache tuée, alors que vous souhaitiez qu'on tue un poulet.

Donc, dans de tels domaines, il est effectivement préférable de différencier les mots, pour ajouter de la redondance dans le canal de communication. Les mots courants doivent être plus distincts. Il s'agit de communiquer efficacement, et puis il y a aussi cette idée de synchronisation automatique des codes. Si vous regardez une étiquette UPC sur un produit (un code à barres), c'est en fait un code autosynchronisé, où chaque paire de barres et d'espaces se trouve toujours dans une unité d'une largeur de sept colonnes. Vous pouvez compter là-dessus — vous savez que la largeur des barres remontera toujours jusqu'à cette valeur. Donc, c'est de l'autosynchronisation.

Il existe d'autres codes autosynchronisés utilisés en électronique. Dans les vieux protocoles de transmission en série, il y avait des bits d'arrêt et de démarrage, ainsi vous pouviez garder les choses synchronisées. Les langues naturelles font cela aussi. Par exemple, dans l'écriture du japonais on n'utilise pas des espaces. Parce que, de la façon dont ils écrivent, ils auront au début de chaque phrase un caractère chinois Kanji, puis les terminaisons sont écrites dans un syllabaire.

LinuxVoice : Hiragana, non?

Larry Wall : Oui, Hiragana. Alors, naturellement, le début de chaque phrase se démarque vraiment grâce à ce système. De même, en grec ancien, la plupart des verbes étaient déclinés ou conjugués. Ainsi ils avaient des terminaisons standard, qui représentaient une sorte de mécanisme de synchronisation. Les espaces aussi étaient facultatives dans leur système d'écriture — cela a été une invention plus moderne de mettre des espaces.

Donc, de façon similaire, dans les langages informatiques il est utile d'avoir un code autosynchronisé. Nous comptons beaucoup sur cela en Perl et même plus fortement avec Perl 6 que dans les versions précédentes. L'idée de départ c'est que, lorsque vous analysez une expression, vous attendez soit un terme, soit un opérateur infixé. Lorsque vous attendez un terme, vous pourriez également obtenir un opérateur préfixé (qui se trouve plus ou moins dans le même créneau d'attente) et quand vous vous attendez à un infixé, vous pourriez également obtenir un postfixé du terme précédent.

Mais c'est un va-et-vient. Et si le compilateur sait réellement ce qu'il attend, vous pouvez surcharger cela un peu, et Perl le fait. Donc, une barre oblique lorsqu'il attend un terme introduira une expression régulière, tandis qu'une barre oblique lorsque vous attendez un infixé indiquera une division. En revanche, nous ne voulons pas tout surcharger, car alors vous perdez la redondance de l'autosynchronisation.

La plupart de nos meilleurs messages d'erreur, ceux qui concernent les erreurs de syntaxe, vous indiquent que vous avez deux termes sur une ligne. Et alors nous essayons de comprendre pourquoi il y a deux termes sur une ligne : « oh, vous devez avoir oublié de mettre un point-virgule à la fin de la ligne précédente ». Donc, nous pouvons produire de bien meilleurs messages d'erreur que les analyseurs plus ad hoc.

LinuxVoice : Pourquoi la conception de Perl 6 a-t-elle pris quinze années ? Ce doit être difficile de superviser un langage quand tout le monde a des opinions différentes sur les choses, et il n'y a pas toujours que la bonne et la mauvaise façon de faire les choses.

Larry Wall : Cela devait être un exercice d'équilibre très prudent. Il y avait tellement de bonnes idées au début — bon, je ne veux pas dire qu'elles étaient toutes de bonnes idées. Il y avait tellement de points névralgiques, comme le fait d'avoir 361 RFC [propositions de fonctionnalités nouvelles ou modifiées] quand je m'attendais peut-être à 20. Nous avons dû effectivement les étudier toutes et ignorer les solutions proposées, parce qu'elles allaient dans tous les sens et avaient toutes des visions très étroites. Beaucoup d'entre elles changeaient une seule chose, mais si nous les implémentions toutes, cela aurait été un désordre total.

Nous avons donc dû chercher une explication des problèmes que les gens rencontraient en essayant d'utiliser Perl 5. Nous avons commencé à regarder les idées unificatrices, sous-jacentes. Beaucoup de ces RFC étaient basées sur le fait que nous avions un système inadéquat de typage. En introduisant un système de type plus cohérent, nous avons pu résoudre de nombreux problèmes d'une manière saine et d'une façon cohérente.

Et nous avons commencé à remarquer d'autres modalités qui nous offraient la possibilité d'unifier les ensembles de fonctionnalités, et nous avons commencé à réutiliser des idées dans différents domaines. Pas nécessairement qu'il y avait la même chose en dessous. Nous avons un moyen standard d'écriture des paires - eh bien, deux façons en Perl ! Mais la façon d'écrire les paires avec un deux-points peut être réutilisée également pour la notation d'une base, ou pour les nombres littéraux dans n'importe quelle base. Elle pourrait également être utilisée pour diverses autres formes de citation. Nous disons en Perl que c'est « étrangement cohérent ».

« Des gens qui ont fait les premières implémentations de Perl 6 sont venus vers moi, casquette en main, et ont dit « Nous avons vraiment besoin d'un concepteur du langage. » »

Des idées similaires surgissent, et vous dites : « Je suis déjà familier avec la façon dont cette syntaxe fonctionne, mais je vois qu'elle a été utilisée pour autre chose ». Il a fallu donc une certaine unité de vision pour trouver ces unifications. Des gens qui ont eu des idées diverses et qui ont fait les premières implémentations du Perl 6 sont venus vers moi, casquette en main, et ont dit « Nous avons vraiment besoin d'un concepteur du langage. Pourriez-vous être notre dictateur bienveillant ? »

Donc j'ai été le concepteur du langage, mais on m'a dit presque explicitement : « Ne touchez pas à la mise en œuvre ! Nous avons vu ce que vous avez fait de Perl 5, et nous n'aimons pas ! » C'était vraiment drôle, parce que la nouvelle mise en œuvre a pris sa source dans les entrailles de Perl 5, et peut-être c'est pourquoi certaines des premières implémentations ne fonctionnaient pas bien.

Parce que nous étions encore à tâtons dans l'ensemble de la conception, les implémentations ont fait beaucoup de suppositions sur ce que la machine virtuelle devrait faire ou pas, donc nous nous sommes retrouvés avec quelque chose comme un langage assembleur orienté objet. Ce genre de problème était assez répandu au début. Alors les gars de Pugs sont venus et ont dit « Utilisons Haskell, parce qu'il vous fait réfléchir très clairement à ce que vous faites. Clarifions notre modèle sémantique sous-jacent ».

Donc, nous avons figé certains de ces modèles sémantiques, mais encore plus important, nous avons commencé à construire la suite de tests à ce moment, pour être compatibles avec les modèles sémantiques. Puis, la machine virtuelle Parrot a continué le développement, et ensuite une autre implémentation, Niecza, est arrivée et elle a été basée sur .NET. Cela a été fait par un jeune homme très intelligent et qui a mis en œuvre un grand sous-ensemble de Perl 6, mais il était une sorte de solitaire et il n'a pas vraiment trouvé un moyen d'impliquer d'autres personnes dans son projet.

En même temps, le projet Parrot devenait vraiment trop gros pour que quiconque puisse le gérer, et aussi très difficile à factoriser. À ce moment-là, les collègues travaillant sur Rakudo ont décidé que nous avions probablement besoin de tourner sur plusieurs plates-formes, pas uniquement sur la machine virtuelle Parrot. Alors ils ont inventé une couche de portabilité appelée NQP qui signifie « Not Quite Perl » (« Pas tout à fait Perl »). Ils l'ont porté pour s'exécuter tout d'abord sur la JVM (Java Virtual Machine) et pendant cela ils travaillaient aussi secrètement sur une nouvelle machine virtuelle appelée MoarVM. Cela a été rendu public il y a un peu plus d'un an.

Tant MoarVM que la JVM exécutent un ensemble à peu près équivalent de tests de régression — Parrot est un peu à la traîne dans certains domaines. Donc, cela a été très bon pour débusquer des hypothèses spécifiques aux machines virtuelles, et nous avons commencé à penser à NQP pour cibler d'autres choses. C'était l'année d'un projet Google Summer of Code pour cibler NQP sur JavaScript, ce qui convenait parfaitement, car MoarVM utilise également Node.js pour une grande partie de son traitement plus banal.

Nous devrons probablement nous concentrer sur MoarVM pour le restant de cette année, jusqu'à ce que nous définissions réellement la version 6.0, puis le reste va rattraper le retard.

LinuxVoice : L'année dernière au Royaume-Uni, le gouvernement a lancé l'Année du Code, une tentative d'intéresser les jeunes à la programmation. Il y a beaucoup d'opinions sur la façon dont cela devrait être fait — si vous devez enseigner les langages de bas niveau au début, de sorte que les gens comprennent vraiment l'utilisation de la mémoire, ou un langage de haut niveau. Quel est votre avis à ce sujet ?

Larry Wall : Jusqu'à présent, la communauté Python a fait un bien meilleur travail de pénétration dans les niveaux inférieurs de l'enseignement que nous. Nous aimerions faire aussi quelque chose dans ce domaine, et c'est en partie pourquoi nous avons le logo papillon, parce que ce sera attrayant pour les filles de sept ans !

Mais nous pensons que Perl 6 pourra être appris comme premier langage de programmation. Un certain nombre de personnes nous ont surpris par l'apprentissage de Perl 5 comme premier langage. Et vous savez, il y a un certain nombre de concepts assez puissants, même dans Perl 5, comme les fermetures, la portée lexicale et des fonctionnalités que vous obtenez généralement de la programmation fonctionnelle. Ce sera encore plus le cas en Perl 6.

« Jusqu'à présent, la communauté Python a fait un bien meilleur travail de pénétration dans les niveaux inférieurs de l'enseignement ».

Une partie de la raison pour laquelle Perl 6 a pris tant de temps est que nous avons une cinquantaine de principes différents, auxquels nous essayons de nous tenir, et dans la conception d'un langage, vous finissez par jongler avec tout un tas de choses, et vous vous demandez « quel est vraiment le principe le plus important ici » ? Il y a eu beaucoup de discussions à propos de beaucoup de choses différentes. Parfois, nous prenons une décision, travaillons dans ce sens pendant un moment, puis nous rendons compte que ce n'était pas tout à fait la bonne décision.

Nous n'avons presque rien conçu ou spécifié sur la programmation concurrente jusqu'à ce que quelqu'un d'assez astucieux à ce sujet n'arrive, sachant quels étaient les différents compromis, et cette personne est Jonathan Worthington. Il a mélangé des idées venant d'autres langages tels que Go et C# avec des primitives concurrentes qui se combinent bien. Cette forme de combinaison est importante dans le reste du langage.

Il y a énormément de systèmes de programmation concurrente et parallèle qui ne se combinent pas bien (comme les threads et les verrous) et il y a beaucoup de façons de les concevoir mal. Donc, dans un sens, cela en valait la peine d'attendre ce délai supplémentaire pour voir certains de ces langages comme Go et C# développer vraiment de bonnes primitives de haut niveau (cela peut paraître contradictoire) qui se combinent bien.

Cet interview est issu du magazine Linux Voice dont voici l'original.