CINQ QUESTIONS SUR LA CONCEPTION DES LANGAGES DE PROGRAMMATION

Mai 2001

(Ce sont quelques notes que j'ai prises pour une table ronde sur la conception des langages de programmation au MIT le 10 mai 2001.)

1. Les langages de programmation sont pour les gens.

Les langages de programmation sont la façon dont les gens communiquent avec les ordinateurs. L'ordinateur serait tout aussi heureux de parler n'importe quelle langue qui serait non ambiguë. La raison pour laquelle nous avons des langages de haut niveau est que les gens ne peuvent pas gérer le langage machine. L'objectif des langages de programmation est d'empêcher nos pauvres cerveaux humains fragiles d'être submergés par une masse de détails.

Les architectes savent que certains types de problèmes de conception sont plus personnels que d'autres. L'un des problèmes de conception les plus propres et les plus abstraits est la conception de ponts. Là, votre travail consiste principalement à traverser une distance donnée avec le moins de matériel possible. L'autre extrémité du spectre est la conception de chaises. Les concepteurs de chaises doivent passer leur temps à réfléchir aux fesses humaines.

Le logiciel varie de la même manière. La conception d'algorithmes pour le routage des données à travers un réseau est un beau problème abstrait, comme la conception de ponts. Alors que la conception de langages de programmation est comme la conception de chaises : c'est tout sur la gestion des faiblesses humaines.

La plupart d'entre nous détestent admettre cela. Concevoir des systèmes d'une grande élégance mathématique semble beaucoup plus attrayant pour la plupart d'entre nous que de se plier aux faiblesses humaines. Et il y a un rôle pour l'élégance mathématique : certains types d'élégance rendent les programmes plus faciles à comprendre. Mais l'élégance n'est pas une fin en soi.

Et quand je dis que les langages doivent être conçus pour s'adapter aux faiblesses humaines, je ne veux pas dire que les langages doivent être conçus pour les mauvais programmeurs. En fait, je pense que vous devriez concevoir pour les meilleurs programmeurs, mais même les meilleurs programmeurs ont des limites. Je ne pense pas que quelqu'un aimerait programmer dans un langage où toutes les variables seraient la lettre x avec des indices entiers.

2. Concevez pour vous-même et vos amis.

Si vous regardez l'histoire des langages de programmation, beaucoup des meilleurs d'entre eux étaient des langages conçus pour que leurs propres auteurs les utilisent, et beaucoup des pires d'entre eux étaient conçus pour que d'autres personnes les utilisent.

Lorsque les langages sont conçus pour d'autres personnes, il s'agit toujours d'un groupe spécifique d'autres personnes : des gens moins intelligents que le concepteur du langage. Donc vous obtenez un langage qui vous parle comme à un enfant. Cobol est le cas le plus extrême, mais beaucoup de langages sont imprégnés de cet esprit.

Cela n'a rien à voir avec le niveau d'abstraction du langage. C est assez bas niveau, mais il a été conçu pour que ses auteurs l'utilisent, et c'est pourquoi les hackers l'aiment.

L'argument en faveur de la conception de langages pour les mauvais programmeurs est que il y a plus de mauvais programmeurs que de bons programmeurs. C'est peut-être le cas. Mais ces quelques bons programmeurs écrivent un pourcentage disproportionnément élevé du logiciel.

Je m'intéresse à la question, comment concevez-vous un langage que les meilleurs hackers aimeront ? Je pense que c'est identique à la question, comment concevez-vous un bon langage de programmation ?, mais même si ce n'est pas le cas, c'est au moins une question intéressante.

3. Donnez au programmeur le plus de contrôle possible.

De nombreux langages (surtout ceux conçus pour d'autres personnes) ont l'attitude d'une gouvernante : ils essaient de vous empêcher de faire des choses qu'ils pensent ne pas être bonnes pour vous. J'aime l' approche opposée : donnez au programmeur le plus de contrôle possible.

Quand j'ai appris Lisp pour la première fois, ce que j'ai le plus aimé était qu'il me considérait comme un partenaire égal. Dans les autres langages que j'avais appris jusque-là, il y avait le langage et il y avait mon programme, écrit dans le langage, et les deux étaient très séparés. Mais dans Lisp, les fonctions et les macros que j'ai écrites étaient comme celles qui composaient le langage lui-même. Je pouvais réécrire le langage si je le voulais. Cela avait le même attrait que les logiciels open source.

4. Visez la concision.

La concision est sous-estimée et même méprisée. Mais si vous regardez au fond du cœur des hackers, vous verrez qu'ils l'aiment vraiment. Combien de fois avez-vous entendu des hackers parler avec affection de la façon dont, disons, en APL, ils pouvaient faire des choses étonnantes avec seulement quelques lignes de code ? Je pense que tout ce que les gens vraiment intelligents aiment vraiment vaut la peine d'être pris en compte.

Je pense que presque tout ce que vous pouvez faire pour raccourcir les programmes est bon. Il devrait y avoir beaucoup de fonctions de bibliothèque ; tout ce qui peut être implicite devrait l'être ; la syntaxe devrait être concise à l'excès ; même les noms des choses devraient être courts.

Et ce n'est pas seulement les programmes qui devraient être courts. Le manuel devrait être mince aussi. Une bonne partie des manuels est occupée par des clarifications et des réserves et des avertissements et des cas particuliers. Si vous vous forcez à raccourcir le manuel, dans le meilleur des cas, vous le faites en corrigeant les choses dans le langage qui nécessitaient tant d'explications.

5. Admettre ce qu'est le hacking.

Beaucoup de gens souhaitent que le hacking soit les mathématiques, ou du moins quelque chose comme une science naturelle. Je pense que le hacking est plus comme l'architecture. L'architecture est liée à la physique, dans le sens où les architectes doivent concevoir des bâtiments qui ne s'effondrent pas, mais l'objectif réel des architectes est de faire de grands bâtiments, pas de faire des découvertes sur la statique.

Ce que les hackers aiment à faire, c'est créer de grands programmes. Et je pense, du moins dans notre esprit, que nous devons nous rappeler que c'est une chose admirable d'écrire de grands programmes, même lorsque ce travail ne se traduit pas facilement dans la monnaie intellectuelle conventionnelle des articles de recherche. Intellectuellement, il est tout aussi intéressant de concevoir un langage que les programmeurs aimeront que de concevoir un horrible qui incarne une idée que vous pouvez publier dans un article.

1. Comment organiser les grandes bibliothèques ?

Les bibliothèques deviennent un composant de plus en plus important des langages de programmation. Elles deviennent également plus grandes, et cela peut être dangereux. S'il faut plus de temps pour trouver la fonction de bibliothèque qui fera ce que vous voulez que pour l'écrire vous-même, alors tout ce code ne fait que rendre votre manuel épais. (Les manuels Symbolics en étaient un exemple.) Donc je pense que nous devrons travailler sur des moyens d'organiser les bibliothèques. L'idéal serait de les concevoir de manière à ce que le programmeur puisse deviner quel appel de bibliothèque ferait la bonne chose.

2. Les gens ont-ils vraiment peur de la syntaxe préfixée ?

Voici la traduction en français :

Ceci est un problème ouvert dans le sens où je m'y suis interrogé pendant des années et que je ne connais toujours pas la réponse. La syntaxe préfixée me semble parfaitement naturelle, sauf peut-être pour les mathématiques. Mais il se peut qu'une grande partie de l'impopularité de Lisp soit simplement due à une syntaxe peu familière. S'il faut faire quelque chose à ce sujet, si c'est vrai, est une autre question.

3. De quoi avez-vous besoin pour un logiciel basé sur un serveur ?

Je pense qu'une grande partie des applications les plus passionnantes qui seront écrites au cours des vingt prochaines années seront des applications Web, c'est-à-dire des programmes qui résident sur le serveur et communiquent avec vous via un navigateur Web. Et pour écrire ce type de programmes, nous aurons peut-être besoin de nouvelles choses.

Une chose dont nous aurons besoin est un support pour la nouvelle façon dont les applications basées sur le serveur sont publiées. Au lieu d'avoir une ou deux grandes versions par an, comme pour les logiciels de bureau, les applications basées sur le serveur sont publiées sous forme d'une série de petits changements. Vous pouvez avoir jusqu'à cinq ou dix versions par jour. Et en règle générale, tout le monde utilisera toujours la dernière version.

Vous savez comment on peut concevoir des programmes pour qu'ils soient déboguables ? Eh bien, les logiciels basés sur le serveur doivent également être conçus pour être modifiables. Vous devez pouvoir les modifier facilement, ou au moins savoir ce qui est un petit changement et ce qui est un changement important.

Une autre chose qui pourrait s'avérer utile pour les logiciels basés sur le serveur, de manière surprenante, ce sont les continuations. Dans les logiciels Web, vous pouvez utiliser quelque chose comme le style de passage de continuation pour obtenir l'effet de sous-programmes dans le monde intrinsèquement sans état d'une session Web. Peut-être que cela vaudrait la peine d'avoir de véritables continuations, si ce n'est pas trop coûteux.

4. Quelles nouvelles abstractions restent à découvrir ?

Je ne suis pas sûr que ce soit un espoir raisonnable, mais une chose que j'aimerais vraiment faire, personnellement, c'est de découvrir une nouvelle abstraction - quelque chose qui ferait autant de différence que d'avoir des fonctions de première classe ou la récursivité, voire même les paramètres clés. Cela peut être un rêve impossible. Ces choses ne se découvrent pas si souvent. Mais je suis toujours à la recherche.

1. Vous pouvez utiliser n'importe quel langage que vous voulez.

Écrire des programmes d'application signifiait autrefois écrire des logiciels de bureau. Et dans les logiciels de bureau, il y a une forte tendance à écrire l'application dans le même langage que le système d'exploitation. Et donc, il y a dix ans, écrire un logiciel signifiait pratiquement écrire un logiciel en C. Avec le temps, une tradition s'est développée : les programmes d'application ne doivent pas être écrits dans des langages inhabituels. Et cette tradition a eu le temps de se développer à tel point que les gens non techniques, comme les gestionnaires et les capitalistes-risqueurs, l'ont également apprise.

Les logiciels basés sur le serveur balaient tout ce modèle. Avec les logiciels basés sur le serveur, vous pouvez utiliser n'importe quel langage que vous voulez. Presque personne ne comprend encore cela (surtout pas les gestionnaires et les capitalistes-risqueurs). Quelques hackers le comprennent, et c'est pourquoi nous entendons même parler de nouveaux langages indépendants comme Perl et Python. Nous n'entendons pas parler de Perl et de Python parce que les gens les utilisent pour écrire des applications Windows.

Ce que cela signifie pour nous, en tant que personnes intéressées par la conception de langages de programmation, c'est qu'il y a maintenant potentiellement un public réel pour notre travail.

2. La vitesse vient des profileurs.

Les concepteurs de langages, ou du moins les implémenteurs de langages, aiment écrire des compilateurs qui génèrent du code rapide. Mais je ne pense pas que ce soit ce qui rend les langages rapides pour les utilisateurs. Knuth a fait remarquer il y a longtemps que la vitesse n'a d'importance que dans quelques goulots d'étranglement critiques. Et quiconque a essayé sait qu'on ne peut pas deviner où se trouvent ces goulots d'étranglement. Les profileurs sont la réponse.

Les concepteurs de langages résolvent le mauvais problème. Les utilisateurs n'ont pas besoin de benchmarks pour aller vite. Ce dont ils ont besoin, c'est d'un langage qui peut leur montrer quelles parties de leurs propres programmes doivent être réécrites. C'est de là que vient la vitesse en pratique. Donc peut-être que ce serait un gain net si les implémenteurs de langages passaient la moitié du temps qu'ils auraient passé à faire des optimisations de compilateur à écrire un bon profileur à la place.

3. Vous avez besoin d'une application pour guider la conception d'un langage.

Ce n'est peut-être pas une règle absolue, mais il semble que les meilleurs langages aient tous évolué en même temps qu'une application qu'ils étaient utilisés pour écrire. C a été écrit par des gens qui en avaient besoin pour la programmation système. Lisp a été développé en partie pour faire de la différentiation symbolique, et McCarthy était tellement impatient de commencer qu'il écrivait des programmes de différentiation dès le premier article sur Lisp, en 1960.

C'est particulièrement bon si votre application résout un nouveau problème. Cela aura tendance à pousser votre langage à avoir de nouvelles fonctionnalités dont les programmeurs ont besoin. Personnellement, je suis intéressé par l'écriture d'un langage qui sera bon pour écrire des applications basées sur le serveur.

[Pendant le panel, Guy Steele a également fait ce point, avec la suggestion supplémentaire que l'application ne devrait pas consister à écrire le compilateur de votre langage, sauf si votre langage est destiné à écrire des compilateurs.]

4. Un langage doit être bon pour écrire des programmes jetables.

Vous savez ce qu'est un programme jetable : quelque chose que vous écrivez rapidement pour une tâche limitée. Je pense que si vous regardiez autour de vous, vous trouveriez qu'une grande partie des programmes importants et sérieux ont commencé comme des programmes jetables. Je ne serais pas surpris si la plupart des programmes avaient commencé comme des programmes jetables. Et donc, si vous voulez créer un langage qui soit bon pour écrire des logiciels en général, il doit être bon pour écrire des programmes jetables, car c'est le stade larvaire de la plupart des logiciels.

5. La syntaxe est liée à la sémantique.

Il est traditionnel de penser que la syntaxe et la sémantique sont complètement séparées. Cela peut vous choquer, mais il se peut qu'elles ne le soient pas. Je pense que ce que vous voulez dans votre langage peut être lié à la façon dont vous l'exprimez.

Je parlais récemment à Robert Morris, et il a fait remarquer que la surcharge d'opérateurs est un gain plus important dans les langages avec une syntaxe infixe. Dans un langage avec une syntaxe préfixée, toute fonction que vous définissez est effectivement un opérateur. Si vous voulez définir un plus pour un nouveau type de nombre que vous avez créé, vous pouvez simplement définir une nouvelle fonction pour les additionner. Si vous faites cela dans un langage avec une syntaxe infixe, il y a une grande différence d'apparence entre l'utilisation d'un opérateur surchargé et un appel de fonction.

1. Nouveaux langages de programmation.

Dans les années 1970, il était à la mode de concevoir de nouveaux langages de programmation. Récemment, ce ne l'a pas été. Mais je pense que les logiciels basés sur le serveur vont remettre les nouveaux langages à la mode. Avec les logiciels basés sur le serveur, vous pouvez utiliser n'importe quel langage que vous voulez, donc si quelqu'un conçoit un langage qui semble vraiment meilleur que les autres qui sont disponibles, il y aura des gens qui prendront le risque de l'utiliser.

2. Le temps partagé.

Richard Kelsey a donné cette idée comme étant revenue à l'ordre du jour lors du dernier panel, et je suis complètement d'accord avec lui. Mon hypothèse (et l'hypothèse de Microsoft, semble-t-il) est que beaucoup d'informatique se déplacera du bureau vers des serveurs distants. En d'autres termes, le time-sharing est de retour. Et je pense qu'il faudra un soutien pour cela au niveau du langage. Par exemple, je sais que Richard et Jonathan Rees ont beaucoup travaillé sur la mise en œuvre de l'ordonnancement des processus dans Scheme 48.

3. Efficacité.

Il commençait récemment à sembler que les ordinateurs étaient enfin assez rapides. De plus en plus, nous commencions à entendre parler de byte code, ce qui me laisse penser que nous pensons avoir des cycles à épargner. Mais je ne pense pas que ce sera le cas avec les logiciels basés sur le serveur. Quelqu'un devra payer pour les serveurs sur lesquels les logiciels s'exécutent, et le nombre d'utilisateurs qu'ils peuvent prendre en charge par machine sera le diviseur de leur coût en capital.

Donc je pense que l'efficacité comptera, au moins dans les goulots d'étranglement de calcul. Il sera particulièrement important d'effectuer les entrées/sorties rapidement, car les applications basées sur le serveur effectuent beaucoup d'entrées/sorties.

Il se peut que le byte code ne soit pas une bonne solution, en fin de compte. Sun et Microsoft semblent se faire face dans une sorte de bataille des byte codes pour le moment. Mais ils le font parce que le byte code est un endroit pratique pour s'insérer dans le processus, pas parce que le byte code est en soi une bonne idée. Il se peut que ce champ de bataille soit contourné. Ce serait assez amusant.

1. Clients.

Ce n'est qu'une supposition, mais mon hypothèse est que le modèle gagnant pour la plupart des applications sera purement basé sur le serveur. Concevoir un logiciel qui fonctionne sur l'hypothèse que tout le monde aura votre client est comme concevoir une société sur l'hypothèse que tout le monde sera honnête. Ce serait certainement pratique, mais vous devez supposer que cela ne se produira jamais.

Je pense qu'il y aura une prolifération d'appareils qui auront un certain type d'accès Web, et tout ce que vous pourrez supposer à leur sujet, c'est qu'ils pourront prendre en charge un simple HTML et des formulaires. Aurez-vous un navigateur sur votre téléphone portable ? Y aura-t-il un téléphone dans votre assistant numérique ? Votre Blackberry aura-t-il un plus grand écran ? Pourrez-vous naviguer sur le Web sur votre Game Boy ? Votre montre ? Je ne sais pas. Et je n'ai pas besoin de le savoir si je mise sur le fait que tout sera sur le serveur. C'est tellement plus robuste d'avoir toute l'intelligence sur le serveur.

2. Programmation orientée objet.

Je sais que c'est un sujet controversé, mais je ne pense pas que la programmation orientée objet soit si importante. Je pense que c'est un bon modèle pour certains types d'applications qui ont besoin de ce type spécifique de structure de données, comme les systèmes de fenêtrage, les simulations et les programmes CAO. Mais je ne vois pas pourquoi cela devrait être le modèle pour toute la programmation.

Je pense qu'une partie de la raison pour laquelle les gens dans les grandes entreprises aiment la programmation orientée objet est qu'elle produit beaucoup de ce qui ressemble à du travail. Quelque chose qui pourrait naturellement être représenté comme une liste d'entiers, par exemple, peut maintenant être représenté comme une classe avec toutes sortes d'échafaudages et d'agitation.

Un autre attrait de la programmation orientée objet est que les méthodes vous donnent une partie de l'effet des fonctions de premier ordre. Mais ce n'est pas une nouveauté pour les programmeurs Lisp. Quand vous avez de véritables fonctions de premier ordre, vous pouvez les utiliser de la manière la plus appropriée à la tâche à accomplir, au lieu de forcer tout dans un moule de classes et de méthodes.

Ce que cela signifie pour la conception de langages, je pense, c'est que vous ne devriez pas trop approfondir la programmation orientée objet. Peut-être que la réponse est d'offrir des choses plus générales et sous-jacentes, et de laisser les gens concevoir les systèmes d'objets qu'ils veulent sous forme de bibliothèques.

3. Conception par comité.

Avoir son langage conçu par un comité est un gros piège, et pas seulement pour les raisons que tout le monde connaît. Tout le monde sait que les comités ont tendance à produire des conceptions inégales et incohérentes. Mais je pense qu'un plus grand danger est qu'ils ne prendront pas de risques. Quand une seule personne est aux commandes, elle peut prendre des risques qu'un comité n'accepterait jamais.

Est-il nécessaire de prendre des risques pour concevoir un bon langage cependant ? Beaucoup de gens pourraient soupçonner que la conception de langages est quelque chose où l'on devrait rester assez proche de la sagesse conventionnelle. Je parie que ce n'est pas vrai. Dans tout le reste de ce que les gens font, la récompense est proportionnelle au risque. Pourquoi la conception de langages devrait-elle être différente ?