CINQ QUESTIONS SUR LA CONCEPTION DES LANGAGES

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 humains.

Les langages de programmation sont la façon dont les gens parlent aux ordinateurs. L'ordinateur serait tout aussi heureux de parler n'importe quelle langue qui soit 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. Le but 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 est en grande partie une question de franchir une distance donnée avec le moins de matière possible. L'autre extrémité du spectre est la conception de chaises. Les concepteurs de chaises doivent passer leur temps à penser aux fesses humaines.

Les logiciels varient de la même manière. Concevoir des algorithmes pour le routage des données sur un réseau est un problème agréable et abstrait, comme la conception de ponts. Alors que la conception de langages de programmation ressemble à la conception de chaises : tout est une question de gestion des faiblesses humaines.

La plupart d'entre nous détestent reconnaître cela. Concevoir des systèmes d'une grande élégance mathématique semble beaucoup plus attrayant pour la plupart d'entre nous que de pander 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 étaient 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 langages étaient des langages conçus pour leurs propres auteurs, et un grand nombre des pires é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 personnes moins intelligentes que le concepteur du langage. Donc, vous obtenez un langage qui vous parle de haut. 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. Cela peut être vrai. Mais ces quelques bons programmeurs écrivent une proportion disproportionnée du logiciel.

Je m'intéresse à la question, comment concevoir un langage que les meilleurs hackers apprécieront ? Je pense que c'est identique à la question, comment concevoir 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 autant de contrôle que possible.

De nombreux langages (en particulier 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 le concept opposé : donnez au programmeur autant de contrôle que possible.

Lorsque j'ai appris Lisp pour la première fois, ce que j'ai aimé le plus, c'est qu'il me considérait comme un partenaire égal. Dans les autres langages que j'avais appris jusqu'alors, il y avait le langage et il y avait mon programme, écrit dans le langage, et les deux étaient très distincts. Mais en 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 voulais. Il avait le même attrait que les logiciels open source.

4. Visez la brièveté.

La brièveté est sous-estimée et même méprisée. Mais si vous regardez dans le 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 incroyables 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 rendre les programmes plus courts 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 ne sont pas seulement les programmes qui devraient être courts. Le manuel devrait être mince aussi. Une bonne partie des manuels est consacrée aux clarifications et aux réserves et aux avertissements et aux 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 autant d'explications.

5. Admettez ce qu'est le piratage.

Beaucoup de gens souhaitent que le piratage soit des mathématiques, ou au moins quelque chose comme une science naturelle. Je pense que le piratage ressemble plus à 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 le but 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 faire de grands programmes. Et je pense que, du moins dans notre propre esprit, 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 valable de concevoir un langage que les programmeurs adoreront que de concevoir un langage horrible qui incarne une idée sur laquelle vous pouvez publier un article.

1. Comment organiser les grandes bibliothèques ?

Les bibliothèques sont en train de devenir un composant de plus en plus important des langages de programmation. Elles sont également de plus en plus volumineuses, 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.) Je pense donc 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 ?

C'est un problème ouvert dans le sens où je me le pose depuis des années et je ne connais toujours pas la réponse. La syntaxe préfixée me semble parfaitement naturelle à moi, sauf peut-être pour les mathématiques. Mais il se pourrait qu'une grande partie de l'impopularité de Lisp soit simplement due à une syntaxe inconnue. Savoir s'il faut faire quelque chose à ce sujet, si c'est vrai, est une autre question.

3. De quoi avez-vous besoin pour les logiciels basés sur des serveurs ?

Je pense que beaucoup des nouvelles applications les plus excitantes 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 vous parlent via un Web navigateur. Et pour écrire ces types de programmes, nous aurons peut-être besoin de quelques nouvelles choses.

Une chose dont nous aurons besoin est la prise en charge de la nouvelle façon dont les serveurs les applications sont publiées. Au lieu d'avoir une ou deux grandes versions par an, comme les logiciels de bureau, les applications basées sur des serveurs sont publiées sous la forme d'une série de petites modifications. 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 vous pouvez concevoir des programmes pour qu'ils soient déboguables ? Eh bien, les logiciels basés sur des serveurs doivent également être conçus pour être modifiables. Vous devez pouvoir le 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 serveurs logiciels, étonnamment, 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-routines dans le monde intrinsèquement sans état d'une session Web. Peut-être vaudrait-il la peine d'avoir de vraies continuations, si ce n'était pas trop cher.

4. Quelles nouvelles abstractions restent à découvrir ?

Je ne suis pas sûr de savoir à quel point cet espoir est raisonnable, mais une chose que j'aimerais vraiment faire, personnellement, c'est 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é ou même les paramètres de mots-clés. Cela peut être un rêve impossible. Ces choses ne sont pas découvertes si souvent. Mais je suis toujours à la recherche.

1. Vous pouvez utiliser le langage que vous voulez.

Écrire des applications les programmes servaient autrefois à écrire des logiciels de bureau. Et dans les logiciels de bureau il y a un grand biais en faveur de l'écriture de l'application dans le même langage que le système d'exploitation. Et donc il y a dix ans, écrire des logiciels signifiait à peu près écrire des logiciels en C. Une tradition a fini par se développer : les programmes d'application ne doivent pas être écrits dans des langages inhabituels. Et cette tradition a eu tellement de temps pour se développer que les personnes non techniques comme les gestionnaires et les investisseurs en capital-risque l'ont également apprise.

Les logiciels basés sur des serveurs font sauter tout ce modèle. Avec les serveurs logiciels, vous pouvez utiliser le langage que vous voulez. Presque personne ne comprend cela encore (surtout pas les gestionnaires et les investisseurs en capital-risque). 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 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 véritable public 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 ne compte que dans quelques points critiques de goulot d'étranglement. Et tous ceux qui ont essayé savent que vous ne pouvez pas deviner où se trouvent ces goulots d'étranglement. Les profileurs sont la solution.

Les concepteurs de langages résolvent le mauvais problème. Les utilisateurs n'ont pas besoin de benchmarks pour fonctionner rapidement. 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 dans la pratique. Donc, peut-être serait-ce un gain net si les implémenteurs de langages consacraient la moitié du temps qu'ils auraient passé à faire des optimisations de compilateur et à passer ce temps à écrire un bon profileur à la place.

3. Vous avez besoin d'une application pour piloter 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 personnes qui en avaient besoin pour la programmation système. Lisp a été développé en partie pour faire de la différenciation symbolique, et McCarthy était tellement impatient de commencer qu'il écrivait des programmes de différenciation même dans le premier article sur Lisp, en 1960.

C'est particulièrement bien 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 des serveurs.

[Pendant la table ronde, Guy Steele a également fait ce point, avec la suggestion supplémentaire que l'application ne devrait pas consister à écrire le compilateur pour votre langage, à moins que votre langage ne soit 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 que beaucoup de grands programmes sérieux ont commencé comme des programmes jetables. Je ne serais pas surpris si la plupart des programmes ont commencé comme des programmes jetables. Et donc, si vous voulez faire un langage qui est bon pour écrire des logiciels en général, il doit être bon pour écrire des programmes jetables, parce que 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 vous semblera choquant, 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 des opérateurs est un gain plus important dans les langages avec une syntaxe infixée. 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 inventé, vous pouvez simplement définir une nouvelle fonction pour les additionner. Si vous faites cela dans un langage avec une syntaxe infixée, 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 n'est plus le cas. Mais je pense que les logiciels basés sur des serveurs rendront les nouveaux langages à la mode à nouveau. Avec les logiciels basés sur des serveurs, vous pouvez utiliser le 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 personnes qui prendront un risque et l'utiliseront.

2. Partage de temps.

Richard Kelsey a donné cela comme une idée dont le temps est revenu dans le dernier panel, et je suis entièrement d'accord avec lui. Ma supposition (et celle de Microsoft, semble-t-il) est que beaucoup de calculs passeront du bureau vers des serveurs distants. En d'autres termes, le partage de temps est de retour. Et je pense qu'il faudra le prendre en charge au niveau du langage. Par exemple, je sais que Richard et Jonathan Rees ont fait beaucoup de travail pour implémenter le processus de planification au sein de Scheme 48.

3. Efficacité.

Récemment, il commençait à sembler que les ordinateurs étaient enfin assez rapides. De plus en plus, nous commencions à entendre parler de byte code, ce qui implique pour moi au moins que nous pensons avoir des cycles à revendre. Mais je ne pense pas que nous en aurons, avec les serveurs logiciels. Quelqu'un va devoir payer pour les serveurs qui exécutent le logiciel, et le nombre d'utilisateurs qu'ils peuvent prendre en charge par machine sera le diviseur de leur coût en capital.

Je pense donc que l'efficacité aura de l'importance, du moins dans les points de goulot d'étranglement computationnels. Il sera particulièrement important de faire des E/S rapidement, parce que les applications basées sur des serveurs font beaucoup d'E/S.

Il se peut que le byte code ne soit pas une victoire, au final. Sun et Microsoft semblent s'affronter dans une sorte de bataille des byte codes en ce 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 tout ce champ de bataille soit contourné. Ce serait assez amusant.

1. Clients.

Ce n'est qu'une supposition, mais je suppose que le modèle gagnant pour la plupart des applications sera purement basé sur un serveur. Concevoir des logiciels qui fonctionnent en supposant que tout le monde aura votre client, c'est comme concevoir une société en supposant que tout le monde sera honnête. Ce serait certainement pratique, mais vous devez supposer que cela n'arrivera jamais.

Je pense qu'il y aura une prolifération d'appareils qui auront une certaine forme d'accès Web, et tout ce que vous pourrez supposer à leur sujet, c'est qu'ils peuvent prendre en charge le html et les formulaires simples. Aurai-je un navigateur sur mon téléphone portable ? Y aura-t-il un téléphone dans mon assistant personnel ? Mon BlackBerry aura-t-il un écran plus grand ? Pourrai-je naviguer sur le Web avec ma Game Boy ? Ma montre ? Je ne sais pas. Et je n'ai pas besoin de savoir si je parie sur que tout est sur le serveur. C'est tout simplement beaucoup plus robuste d'avoir tous les cerveaux sur le serveur.

2. Programmation orientée objet.

Je réalise que c'est un point controversé, mais je ne pense pas que la programmation orientée objet soit un si gros problème. Je pense que c'est un bon modèle pour certains types d'applications qui ont besoin de ce type de structure de données spécifique, comme les systèmes de fenêtres, les simulations et les programmes de 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, disons, une liste de entiers, peut maintenant être représenté comme une classe avec toutes sortes de échafaudages et de va-et-vient.

Une autre attraction de la programmation orientée objet est que les méthodes vous donnent une partie de l'effet des fonctions de première classe. Mais c'est une vieille nouvelle pour les programmeurs Lisp. Lorsque vous avez de vraies fonctions de première classe, vous pouvez simplement les utiliser de la manière qui convient à la tâche à accomplir, au lieu de tout forcer dans un moule de classes et de méthodes.

Ce que cela signifie pour la conception des langages, je pense, c'est que vous ne devriez pas intégrer la programmation orientée objet trop profondément. Peut-être que la solution 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 comme des bibliothèques.

3. Conception par comité.

Faire concevoir votre langage 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 molles et incohérentes. Mais je pense qu'un danger plus grand est qu'ils ne prendront pas de risques. Lorsqu'une seule personne est responsable, elle peut prendre des risques qu'un comité n'accepterait jamais.

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