CINQ QUESTIONS SUR LA CONCEPTION DES LANGAGES
OriginalMai 2001
(Ce sont quelques notes que j'ai prises pour une discussion en panel 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 parlent aux ordinateurs. L'ordinateur serait tout aussi heureux de parler n'importe quel langage qui soit sans ambiguïté. 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 clairs et les plus abstraits est la conception de ponts. Là, votre travail consiste principalement à franchir une distance donnée avec le moins de matériel. L'autre extrémité du spectre est la conception de chaises. Les concepteurs de chaises doivent passer leur temps à réfléchir aux derrières humains.
Le logiciel varie de la même manière. Concevoir des algorithmes pour acheminer des données à travers un réseau est un problème agréable et abstrait, comme la conception de ponts. Alors que concevoir des langages de programmation est comme concevoir des chaises : il s'agit de traiter les 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 céder aux faiblesses humaines. Et il y a un rôle pour l'élégance mathématique : certaines formes 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 de mauvais programmeurs. En fait, je pense que vous devriez concevoir pour les meilleurs programmeurs, mais même les meilleurs programmeurs ont des limitations. Je ne pense pas que quiconque aimerait programmer dans un langage où toutes les variables étaient la lettre x avec des indices entiers.
2. Concevez pour Vous et Vos Amis.
Si vous regardez l'histoire des langages de programmation, beaucoup des meilleurs étaient des langages conçus pour que leurs propres auteurs les utilisent, et beaucoup des pires étaient conçus pour que d'autres les utilisent.
Lorsque les langages sont conçus pour d'autres personnes, c'est toujours un groupe spécifique d'autres personnes : des personnes pas aussi intelligentes que le concepteur du langage. Vous obtenez donc 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 pour cela que les hackers l'aiment.
L'argument en faveur de la conception de langages pour de 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 un pourcentage disproportionné de logiciels.
Je m'intéresse à la question de savoir comment concevoir un langage que les meilleurs hackers aimeront. Je pense que cela est identique à la question de savoir 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 (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 autant de contrôle que vous le pouvez.
Lorsque j'ai appris Lisp pour la première fois, ce que j'aimais le plus à son sujet était 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 séparés. Mais dans Lisp, les fonctions et macros que j'écrivais étaient tout 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 le logiciel 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 tendresse de la façon dont, disons, APL, leur permettait de faire des choses incroyables avec juste quelques lignes de code ? Je pense que tout ce que des 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 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. Admettez Ce Qu'est le Hacking.
Beaucoup de gens souhaiteraient que le hacking soit des 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 créer 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 nos propres esprits, que nous devons nous rappeler qu'il est 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 aimeront que de concevoir un horrible qui incarne une idée sur laquelle vous pouvez publier un article.
1. Comment Organiser de Grandes Bibliothèques ?
Les bibliothèques deviennent un composant de plus en plus important des langages de programmation. Elles grossissent également, et cela peut être dangereux. Si cela prend plus de temps pour trouver la fonction de bibliothèque qui fera ce que vous voulez que cela ne prendrait pour l'écrire vous-même, alors tout ce code ne fait rien d'autre que d'épaissir votre manuel. (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éfixe ?
C'est un problème ouvert dans le sens où je me suis demandé à ce sujet pendant des années et je ne sais toujours pas la réponse. La syntaxe préfixe me semble parfaitement naturelle, 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 peu familière. Savoir s'il faut faire quelque chose à ce sujet, si c'est vrai, est une autre question.
3. De Qu'avez-Vous Besoin pour un Logiciel Basé sur un Serveur ?
Je pense qu'une grande partie des nouvelles applications les plus passionnantes qui seront écrites dans les vingt prochaines années seront des applications basées sur le Web, c'est-à-dire des programmes qui se trouvent sur le serveur et vous parlent à travers un navigateur Web. Et pour écrire ce type de programmes, nous pourrions avoir besoin de certaines nouvelles choses.
Une chose dont nous aurons besoin est le support pour la nouvelle façon dont les applications basées sur un serveur sont publiées. Au lieu d'avoir une ou deux grandes versions par an, comme les logiciels de bureau, les applications basées sur un serveur sont publiées sous forme de 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 vous pouvez concevoir des programmes pour être débogables ? Eh bien, le logiciel basé sur un serveur doit également être conçu pour être modifiable. Vous devez pouvoir le changer facilement, ou au moins savoir ce qui est un petit changement et ce qui est un changement majeur.
Une autre chose qui pourrait s'avérer utile pour le logiciel basé sur un serveur, de manière surprenante, est les continuations. Dans le logiciel basé sur le Web, vous pouvez utiliser quelque chose comme le style de passage de continuation pour obtenir l'effet des sous-routines dans le monde intrinsèquement sans état d'une session Web. Peut-être qu'il vaudrait la peine d'avoir de véritables continuations, si ce n'était pas trop coûteux.
4. Quelles Nouvelles Abstractions Restent à Découvrir ?
Je ne suis pas sûr de la raisonnable espérance que cela représente, mais une chose que j'aimerais vraiment faire, personnellement, 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 de la récursion ou même des paramètres de mot-clé. 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 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 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. Finalement, 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 tant de temps pour se développer que des personnes non techniques comme les gestionnaires et les capital-risqueurs l'ont également apprise.
Le logiciel basé sur un serveur balaie tout ce modèle. Avec le logiciel basé sur un serveur, vous pouvez utiliser n'importe quel langage que vous voulez. Presque personne ne comprend cela encore (surtout pas les gestionnaires et les capital-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 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 Profils.
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 souligné il y a longtemps que la vitesse n'a d'importance que dans quelques goulets d'étranglement critiques. Et quiconque a essayé sait que vous ne pouvez pas deviner où se trouvent ces goulets 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 références 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 là que la vitesse vient en pratique. Donc peut-être que ce serait un gain net si les implémenteurs de langages prenaient la moitié du temps qu'ils auraient passé à faire des optimisations de compilateur et le passaient à écrire un bon profileur à la place.
3. Vous Avez Besoin d'une Application pour Guider la Conception d'un Langage.
Cela peut ne pas être une règle absolue, mais il semble que les meilleurs langages ont tous évolué en même temps qu'une application pour laquelle ils étaient utilisés. 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érentiation symbolique, et McCarthy était si désireux de commencer qu'il écrivait des programmes de différentiation même dans le premier article sur Lisp, en 1960.
C'est particulièrement bon si votre application résout un nouveau problème. Cela tendra à pousser votre langage à avoir de nouvelles fonctionnalités dont les programmeurs ont besoin. Personnellement, je suis intéressé à écrire un langage qui sera bon pour écrire des applications basées sur un serveur.
[Lors du panel, 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 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 va sembler 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 souligné que la surcharge d'opérateurs est un plus plus important dans les langages avec une syntaxe infixe. Dans un langage avec une syntaxe préfixe, 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 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 n'était pas le cas. Mais je pense que le logiciel basé sur un serveur rendra à nouveau les nouveaux langages à la mode. Avec le logiciel basé sur un serveur, vous pouvez utiliser n'importe quel langage que vous voulez, donc si quelqu'un conçoit un langage qui semble réellement meilleur que d'autres qui sont disponibles, il y aura des gens qui prendront le risque de l'utiliser.
2. Partage de Temps.
Richard Kelsey a donné cela comme une idée dont le moment est revenu lors du dernier panel, et je suis complètement d'accord avec lui. Mon avis (et l'avis de Microsoft, semble-t-il) est qu'une grande partie de l'informatique va passer du bureau à des serveurs distants. En d'autres termes, le partage de temps est de retour. Et je pense qu'il devra y avoir un support pour cela au niveau du langage. Par exemple, je sais que Richard et Jonathan Rees ont fait beaucoup de travail sur la planification des processus dans 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 bytecode, ce qui implique pour moi au moins que nous avons des cycles à revendre. Mais je ne pense pas que ce sera le cas avec le logiciel basé sur un serveur. Quelqu'un va devoir payer pour les serveurs sur lesquels le logiciel fonctionne, et le nombre d'utilisateurs qu'ils peuvent supporter par machine sera le diviseur de leur coût en capital.
Donc je pense que l'efficacité comptera, au moins dans les goulets d'étranglement computationnels. Il sera particulièrement important de faire de l'entrée/sortie rapidement, car les applications basées sur un serveur font beaucoup d'entrée/sortie.
Il se peut que le bytecode ne soit pas un avantage, au final. Sun et Microsoft semblent être en train de s'affronter dans une sorte de bataille des bytecodes en ce moment. Mais ils le font parce que le bytecode est un endroit pratique pour s'insérer dans le processus, pas parce que le bytecode est en soi une bonne idée. Il se peut que ce champ de bataille soit complètement contourné. Ce serait plutôt amusant.
1. Clients.
C'est juste une supposition, mais je parie 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, c'est comme concevoir une société sur l'hypothèse que tout le monde sera simplement 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 ont une sorte d'accès Web, et tout ce que vous pourrez supposer à leur sujet est qu'ils peuvent supporter du 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 palm pilot ? Votre blackberry aura-t-il un écran plus grand ? Pourrez-vous naviguer sur le Web sur votre gameboy ? Votre montre ? Je ne sais pas. Et je n'ai pas besoin de savoir si je parie sur le fait que tout sera simplement sur le serveur. C'est juste tellement plus robuste d'avoir tous les cerveaux sur le serveur.
2. Programmation Orientée Objet.
Je réalise 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ê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 de 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 d'entiers, peut maintenant être représenté comme une classe avec toutes sortes de scaffolding et d'agitation.
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 véritables fonctions de première classe, vous pouvez simplement les utiliser de la manière qui convient le mieux à 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 intégrer la programmation orientée objet trop profondément. 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 en tant que bibliothèques.
3. Conception par Comité.
Avoir votre langage conçu par un comité est un grand 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 danger plus grand est qu'ils ne prendront pas de risques. Quand une personne est en charge, elle peut prendre des risques qu'un comité ne serait jamais d'accord.
Est-il nécessaire de prendre des risques pour concevoir un bon langage ? Beaucoup de gens pourraient soupçonner que la conception de langages est quelque chose où vous devriez vous en tenir assez près à 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 de langages devrait-elle être différente ?