LE LANGAGE CENTENAIRE

Avril 2003

(Cet essai est dérivé d'un discours principal à PyCon 2003.)

Il est difficile de prédire à quoi ressemblera la vie dans cent ans. Il y a seulement quelques choses que nous pouvons dire avec certitude. Nous savons que tout le monde conduira des voitures volantes, que les réglementations de zonage seront assouplies pour permettre des bâtiments de centaines d'étages, qu'il fera sombre la plupart du temps et que toutes les femmes seront formées aux arts martiaux. Ici, je veux me concentrer sur un détail de cette image. Quel type de langage de programmation utiliseront-ils pour écrire les logiciels contrôlant ces voitures volantes ?

Cela vaut la peine d'y réfléchir, non pas parce que nous aurons la chance d'utiliser ces langages, mais parce que, si nous avons de la chance, nous utiliserons des langages sur le chemin de ce point à celui-là.

Je pense que, comme les espèces, les langues formeront des arbres évolutifs, avec des impasses se ramifiant partout. Nous pouvons déjà voir cela se produire. Le Cobol, malgré sa popularité à un certain moment, ne semble pas avoir de descendants intellectuels. C'est une impasse évolutive - un langage néandertalien.

Je prédis un sort similaire pour Java. Les gens m'envoient parfois des courriers électroniques en disant : "Comment pouvez-vous dire que Java ne se révélera pas être un langage réussi ? C'est déjà un langage réussi." Et j'admets que c'est le cas, si l'on mesure le succès par l'espace occupé sur les étagères par les livres à ce sujet (en particulier les livres individuels à ce sujet), ou par le nombre d'étudiants de premier cycle qui croient devoir l'apprendre pour obtenir un emploi. Quand je dis que Java ne se révélera pas être un langage réussi, je veux dire quelque chose de plus spécifique : que Java se révélera être une impasse évolutive, comme le Cobol.

Ce n'est qu'une supposition. Je peux me tromper. Mon but ici n'est pas de dénigrer Java, mais de soulever la question des arbres évolutifs et d'amener les gens à se demander où se situe le langage X sur l'arbre. La raison de poser cette question n'est pas seulement pour que nos fantômes puissent dire, dans cent ans, je vous l'avais bien dit. C'est parce que rester proche des branches principales est une heuristique utile pour trouver des langages qui seront bons à programmer maintenant.

À tout moment donné, vous êtes probablement plus heureux sur les branches principales d'un arbre évolutif. Même quand il y avait encore beaucoup de Néandertaliens, ça devait être nul d'en être un. Les Cro-Magnons devaient constamment venir vous battre et vous voler votre nourriture.

La raison pour laquelle je veux savoir à quoi ressembleront les langages dans cent ans, c'est pour savoir sur quelle branche de l'arbre parier maintenant.

L'évolution des langues diffère de l'évolution des espèces car les branches peuvent converger. La branche Fortran, par exemple, semble se fondre avec les descendants d'Algol. En théorie, c'est possible pour les espèces aussi, mais ce n'est pas susceptible de s'être produit pour quelque chose de plus gros qu'une cellule.

La convergence est plus probable pour les langues en partie parce que l'espace des possibilités est plus petit, et en partie parce que les mutations ne sont pas aléatoires. Les concepteurs de langages intègrent délibérément des idées d'autres langages.

Il est particulièrement utile pour les concepteurs de langages de réfléchir à la direction que l'évolution des langages de programmation est susceptible de prendre, car ils peuvent s'orienter en conséquence. Dans ce cas, "rester sur une branche principale" devient plus qu'un moyen de choisir un bon langage. C'est une heuristique pour prendre les bonnes décisions concernant la conception du langage.

Tout langage de programmation peut être divisé en deux parties : un certain ensemble d'opérateurs fondamentaux qui jouent le rôle d'axiomes, et le reste du langage, qui pourrait en principe être écrit en termes de ces opérateurs fondamentaux.

Je pense que les opérateurs fondamentaux sont le facteur le plus important pour la survie à long terme d'un langage. Le reste, vous pouvez le changer. C'est comme la règle selon laquelle, lorsque vous achetez une maison, vous devez d'abord considérer l'emplacement. Tout le reste, vous pouvez le réparer plus tard, mais vous ne pouvez pas changer l'emplacement.

Je pense qu'il est important non seulement que les axiomes soient bien choisis, mais qu'il y en ait peu. Les mathématiciens ont toujours pensé ainsi à propos des axiomes - moins il y en a, mieux c'est - et je pense qu'ils ont raison.

Au minimum, ce doit être un exercice utile de regarder de près le cœur d'une langue pour voir s'il y a des axiomes qui pourraient être éliminés. J'ai constaté dans ma longue carrière de flemmard que la crasse engendre la crasse, et j'ai vu cela se produire dans les logiciels ainsi que sous les lits et dans les coins des pièces.

J'ai un pressentiment que les branches principales de l'arbre évolutif passent par les langues qui ont les noyaux les plus petits et les plus propres. Plus vous pouvez écrire une langue dans elle-même, mieux c'est.

Bien sûr, je fais une grande hypothèse en me demandant à quoi ressembleront les langages de programmation dans cent ans. Écrirons-nous encore des programmes dans cent ans ? Ne ferons-nous que dire aux ordinateurs ce que nous voulons qu'ils fassent ?

Il n'y a pas eu beaucoup de progrès dans ce domaine jusqu'à présent. Mon pari est que dans cent ans, les gens diront encore aux ordinateurs ce qu'ils doivent faire à l'aide de programmes que nous reconnaîtrions comme tels. Il peut y avoir des tâches que nous résolvons maintenant en écrivant des programmes et que dans cent ans, vous n'aurez pas à écrire de programmes pour résoudre, mais je pense qu'il y aura encore beaucoup de programmation du type que nous faisons aujourd'hui.

Il peut sembler présomptueux de penser que quelqu'un peut prédire à quoi ressemblera une technologie dans cent ans. Mais rappelez-vous que nous avons déjà près de cinquante ans d'histoire derrière nous. Regarder vers l'avant sur cent ans est une idée saisissable lorsque l'on considère à quel point les langues ont évolué lentement au cours des cinquante dernières années.

Les langues évoluent lentement parce qu'elles ne sont pas vraiment des technologies. Les langues sont une notation. Un programme est une description formelle du problème que vous voulez qu'un ordinateur résolve pour vous. Donc le rythme d'évolution des langages de programmation est plus proche du rythme d'évolution de la notation mathématique que, disons, des transports ou des communications. La notation mathématique évolue, mais pas avec les bonds de géant que l'on voit dans la technologie.

Quoi que soient les ordinateurs dans cent ans, il semble sûr de prédire qu'ils seront beaucoup plus rapides qu'ils ne le sont maintenant. Si la loi de Moore continue à produire, ils seront 74 quintillions (73 786 976 294 838 206 464) de fois plus rapides. C'est assez difficile à imaginer. Et en effet, la prédiction la plus probable dans le domaine de la vitesse peut être que la loi de Moore cessera de fonctionner. Tout ce qui est censé doubler tous les dix-huit mois semble susceptible de se heurter à une certaine limite fondamentale un jour. Mais je n'ai aucun mal à croire que les ordinateurs seront beaucoup plus rapides. Même s'ils ne finissent que par être un million de fois plus rapides, cela devrait changer considérablement les règles de base des langages de programmation. Entre autres choses, il y aura plus de place pour ce qui serait maintenant considéré comme des langages lents, c'est-à-dire des langages qui ne produisent pas de code très efficace.

Et pourtant, certaines applications exigeront toujours de la vitesse. Certains des problèmes que nous voulons résoudre avec les ordinateurs sont créés par les ordinateurs ; par exemple, le rythme auquel vous devez traiter les images vidéo dépend du rythme auquel un autre ordinateur peut les générer. Et il y a une autre classe de problèmes qui ont une capacité illimitée à absorber les cycles : le rendu d'images, la cryptographie, les simulations.

Si certaines applications peuvent être de plus en plus inefficaces tandis que d'autres continuent à exiger toute la vitesse que le matériel peut fournir, des ordinateurs plus rapides signifieront que les langages doivent couvrir une gamme de plus en plus large d'efficacités. Nous avons déjà vu cela se produire. Les implémentations actuelles de certains nouveaux langages populaires sont étonnamment gaspilleuses par rapport aux normes des décennies précédentes.

Ce n'est pas seulement quelque chose qui se produit avec les langages de programmation. C'est une tendance historique générale. À mesure que les technologies s'améliorent, chaque génération peut faire des choses que la génération précédente aurait considérées comme du gaspillage. Les gens d'il y a trente ans seraient stupéfaits de la façon dont nous faisons nonchalamment des appels longue distance. Les gens d'il y a cent ans seraient encore plus stupéfaits qu'un colis puisse un jour voyager de Boston à New York via Memphis.

Je peux déjà vous dire ce qui va arriver à tous ces cycles supplémentaires que le matériel plus rapide va nous donner au cours des cent prochaines années. Ils seront presque tous gaspillés.

J'ai appris à programmer quand la puissance des ordinateurs était rare. Je me souviens avoir supprimé tous les espaces de mes programmes Basic pour qu'ils tiennent dans la mémoire d'un TRS-80 de 4 Ko. L'idée de ce logiciel stupidement inefficace brûlant des cycles à faire la même chose encore et encore me semble un peu dégoûtante. Mais je pense que mes intuitions ici sont fausses. Je suis comme quelqu'un qui a grandi dans la pauvreté et qui ne peut pas se résoudre à dépenser de l'argent, même pour quelque chose d'important comme aller chez le médecin.

Certains types de gaspillage sont vraiment dégoûtants. Les SUV, par exemple, seraient discutables même s'ils fonctionnaient avec un carburant qui ne s'épuiserait jamais et ne généreraient aucune pollution. Les SUV sont dégoûtants parce qu'ils sont la solution à un problème dégoûtant. (Comment rendre les monospaces plus masculins.) Mais tout le gaspillage n'est pas mauvais. Maintenant que nous avons l'infrastructure pour le supporter, compter les minutes de vos appels interurbains commence à sembler mesquin. Si vous avez les ressources, il est plus élégant de considérer tous les appels téléphoniques comme une seule et même chose, peu importe où se trouve l'autre personne.

Il y a du bon gaspillage et du mauvais gaspillage. Je m'intéresse au bon gaspillage - le genre où, en dépensant plus, nous pouvons obtenir des conceptions plus simples. Comment tirerons-nous parti des opportunités de gaspiller des cycles que nous obtiendrons avec de nouveaux matériels plus rapides ?

Le désir de vitesse est tellement ancré en nous, avec nos pitoyables ordinateurs, qu'il faudra un effort conscient pour le surmonter. Dans la conception de langages, nous devrions chercher consciemment des situations où nous pouvons échanger de l'efficacité contre la moindre augmentation de commodité.

La plupart des structures de données existent à cause de la vitesse. Par exemple, de nombreux langages ont aujourd'hui à la fois des chaînes de caractères et des listes. Sémantiquement, les chaînes de caractères sont plus ou moins un sous-ensemble des listes dans lesquelles les éléments sont des caractères. Alors pourquoi avez-vous besoin d'un type de données séparé ? Vous n'en avez pas vraiment besoin. Les chaînes de caractères n'existent que pour l'efficacité. Mais c'est lamentable d'encombrer la sémantique du langage avec des astuces pour faire tourner les programmes plus vite. Avoir des chaînes de caractères dans un langage semble être un cas d'optimisation prématurée.

Si nous considérons le cœur d'un langage comme un ensemble d'axiomes, il est sûrement dégoûtant d'avoir des axiomes supplémentaires qui n'ajoutent aucun pouvoir d'expression, simplement pour des raisons d'efficacité. L'efficacité est importante, mais je ne pense pas que ce soit la bonne façon de l'obtenir.

La bonne façon de résoudre ce problème, je pense, est de séparer le sens d'un programme des détails d'implémentation. Au lieu d'avoir à la fois des listes et des chaînes de caractères, n'avoir que des listes, avec un moyen de donner des conseils d'optimisation au compilateur qui lui permettront de disposer les chaînes de caractères en octets contigus si nécessaire.

Puisque la vitesse n'a pas d'importance dans la plupart d'un programme, vous n'aurez généralement pas besoin de vous soucier de ce genre de micromanagement. Cela sera de plus en plus vrai à mesure que les ordinateurs deviendront plus rapides.

Dire moins sur l'implémentation devrait également rendre les programmes plus flexibles. Les spécifications changent pendant qu'un programme est en cours d'écriture, et cela n'est pas seulement inévitable, mais souhaitable.

Le mot "essai" vient du verbe français "essayer", qui signifie "tenter". Un essai, dans le sens original, est quelque chose que vous écrivez pour essayer de comprendre quelque chose. Cela se produit aussi dans les logiciels. Je pense que certains des meilleurs programmes étaient des essais, dans le sens où les auteurs ne savaient pas exactement ce qu'ils essayaient d'écrire quand ils ont commencé.

Les hackers Lisp connaissent déjà la valeur d'être flexible avec les structures de données. Nous avons tendance à écrire la première version d'un programme de manière à ce qu'il fasse tout avec des listes. Ces versions initiales peuvent être tellement choquamment inefficaces qu'il faut un effort conscient pour ne pas penser à ce qu'elles font, tout comme, pour moi du moins, manger un steak nécessite un effort conscient pour ne pas penser à d'où il vient.

Ce que les programmeurs dans cent ans rechercheront avant tout, c'est un langage où vous pouvez rassembler une version 1 incroyablement inefficace d'un programme avec le moins d'efforts possible. Du moins, c'est ainsi que nous le décririons dans les termes d'aujourd'hui. Ce qu'ils diront, c'est qu'ils veulent un langage facile à programmer.

Un logiciel inefficace n'est pas dégoûtant. Ce qui est dégoûtant, c'est un langage qui oblige les programmeurs à faire un travail inutile. Gaspiller le temps des programmeurs est la véritable inefficacité, pas gaspiller le temps machine. Cela deviendra de plus en plus évident à mesure que les ordinateurs deviendront plus rapides.

Je pense que nous pourrions déjà envisager de nous débarrasser des chaînes de caractères. Nous l'avons fait dans Arc, et cela semble être un gain ; certaines opérations qui seraient maladroites à décrire comme des expressions régulières peuvent être décrites facilement comme des fonctions récursives.

Jusqu'où ira cette aplanissement des structures de données ? Je peux imaginer des possibilités qui me choquent même moi, avec mon esprit consciencieusement élargi. Allons-nous nous débarrasser des tableaux, par exemple ? Après tout, ce ne sont qu'un sous-ensemble des tables de hachage où les clés sont des vecteurs d'entiers. Allons-nous remplacer les tables de hachage elles-mêmes par des listes ?

Il y a des perspectives encore plus choquantes que cela. Le Lisp que McCarthy a décrit en 1960, par exemple, n'avait pas de nombres. Logiquement, vous n'avez pas besoin d'avoir une notion séparée des nombres, car vous pouvez les représenter sous forme de listes : l'entier n pourrait être représenté comme une liste de n éléments. Vous pouvez faire des mathématiques de cette façon. C'est juste d'une inefficacité insupportable.

Personne n'a réellement proposé de mettre en œuvre les nombres sous forme de listes dans la pratique. En fait, l'article de McCarthy de 1960 n'était pas, à l'époque, destiné à être mis en œuvre du tout. C'était un exercice théorique, une tentative de créer une alternative plus élégante à la machine de Turing. Lorsque quelqu'un a, de manière inattendue, pris ce document et l'a traduit en un interpréteur Lisp fonctionnel, les nombres n'étaient certainement pas représentés sous forme de listes ; ils étaient représentés en binaire, comme dans tous les autres langages.

Un langage de programmation pourrait-il aller jusqu'à se débarrasser des nombres comme type de données fondamental ? Je pose cette question non pas tant comme une question sérieuse que comme un moyen de jouer à la poule mouillée avec l'avenir. C'est comme le cas hypothétique d'une force irrésistible rencontrant un objet immobile - ici, une mise en œuvre d'une inefficacité inimaginable rencontrant des ressources d'une grandeur inimaginable. Je ne vois pas pourquoi pas. L'avenir est plutôt long. S'il y a quelque chose que nous pouvons faire pour diminuer le nombre d'axiomes dans le langage de base, ce serait le côté sur lequel miser à mesure que t tend vers l'infini. Si l'idée semble encore insupportable dans cent ans, peut-être qu'elle ne le sera plus dans mille.

Pour être clair à ce sujet, je ne propose pas que tous les calculs numériques soient en fait effectués à l'aide de listes. Je propose que le langage de base, avant toute notation supplémentaire sur la mise en œuvre, soit défini de cette manière. En pratique, tout programme qui voudrait faire un tant soit peu de mathématiques représenterait probablement les nombres en binaire, mais ce serait une optimisation, pas une partie intégrante de la sémantique du langage de base.

Une autre façon de brûler des cycles est d'avoir de nombreuses couches de logiciels entre l'application et le matériel. C'est également une tendance que nous voyons se produire déjà : de nombreux langages récents sont compilés en bytecode. Bill Woods m'a un jour dit que, en règle générale, chaque couche d'interprétation coûte un facteur 10 en vitesse. Ce coût supplémentaire vous apporte de la flexibilité.

La toute première version d'Arc était un cas extrême de ce type de lenteur à plusieurs niveaux, avec les avantages correspondants. C'était un interprète "métacirculaire" classique écrit sur la base de Common Lisp, avec une ressemblance de famille évidente avec la fonction eval définie dans l'article original de Lisp de McCarthy. Le tout ne faisait que quelques centaines de lignes de code, donc c'était très facile à comprendre et à modifier. Le Common Lisp que nous utilisions, CLisp, s'exécute lui-même sur un interpréteur de bytecode. Donc ici, nous avions deux niveaux d'interprétation, l'un d'eux (le supérieur) étant d'une inefficacité choquante, et le langage était utilisable. À peine utilisable, je l'admets, mais utilisable.

L'écriture de logiciels sous forme de couches multiples est une technique puissante, même au sein des applications. La programmation ascendante consiste à écrire un programme sous forme d'une série de couches, dont chacune sert de langage pour celle qui la précède. Cette approche tend à produire des programmes plus petits et plus flexibles. C'est aussi la meilleure voie vers ce saint graal qu'est la réutilisabilité. Un langage est par définition réutilisable. Plus vous pouvez pousser votre application vers le bas dans un langage pour écrire ce type d'application, plus votre logiciel sera réutilisable.

Somehow the idea of reusability got attached to object-oriented programming in the 1980s, and no amount of evidence to the contrary seems to be able to shake it free. But although some object-oriented software is reusable, what makes it reusable is its bottom-upness, not its object-orientedness. Consider libraries: they're reusable because they're language, whether they're written in an object-oriented style or not.

Je ne prédis pas la disparition de la programmation orientée objet, d'ailleurs. Bien que je ne pense pas qu'elle ait beaucoup à offrir aux bons programmeurs, sauf dans certains domaines spécialisés, elle est irrésistible pour les grandes organisations. La programmation orientée objet offre un moyen durable d'écrire du code spaghetti. Cela vous permet d'accroître les programmes sous forme de correctifs.

Les grandes organisations ont toujours tendance à développer des logiciels de cette manière, et je m'attends à ce que cela soit aussi vrai dans cent ans qu'aujourd'hui.

Tant que nous parlons de l'avenir, nous ferions mieux de parler du calcul parallèle, car c'est là que cette idée semble vivre. C'est-à-dire que, quel que soit le moment où vous en parlez, le calcul parallèle semble être quelque chose qui va se produire dans le futur.

Le futur rattrapera-t-il un jour ? Les gens parlent du calcul parallèle comme quelque chose d'imminent depuis au moins 20 ans, et cela n'a pas beaucoup affecté la pratique de la programmation jusqu'à présent. Ou est-ce le cas ? Déjà les concepteurs de puces doivent y penser, et donc aussi les personnes qui essaient d'écrire des logiciels système sur des ordinateurs multi-processeurs.

La vraie question est, à quel niveau d'abstraction le parallélisme va-t-il monter ? Dans cent ans, affectera-t-il même les programmeurs d'applications ? Ou sera-ce quelque chose dont les rédacteurs de compilateurs doivent s'occuper, mais qui sera généralement invisible dans le code source des applications ?

Une chose qui semble probable, c'est que la plupart des opportunités de parallélisme seront gaspillées. C'est un cas particulier de ma prédiction plus générale selon laquelle la plupart de la puissance de calcul supplémentaire dont nous disposons sera gaspillée. Je m'attends à ce que, comme pour la vitesse stupéfiante du matériel sous-jacent, le parallélisme soit quelque chose qui est disponible si vous le demandez explicitement, mais qui, en règle générale, n'est pas utilisé. Cela implique que le type de parallélisme que nous aurons dans cent ans ne sera pas, sauf dans des applications spéciales, un parallélisme massif. Je m'attends à ce que pour les programmeurs ordinaires, ce soit plus comme pouvoir lancer des processus qui finissent tous par s'exécuter en parallèle.

Et cela sera, comme la demande de mises en œuvre spécifiques de structures de données, quelque chose que l'on fera assez tard dans la vie d'un programme, lorsqu'on essaie de l'optimiser. Les versions 1 ignoreront généralement tous les avantages à tirer du calcul parallèle, tout comme elles ignoreront les avantages à tirer de représentations spécifiques des données.

Sauf dans certains types d'applications spéciales, le parallélisme ne imprégner les programmes qui seront écrits dans cent ans. Ce serait une optimisation prématurée s'il le faisait.

Combien de langages de programmation y aura-t-il dans cent ans ? Il semble y avoir un très grand nombre de nouveaux langages de programmation ces derniers temps. Une partie de la raison est que du matériel plus rapide a permis aux programmeurs de faire différents compromis entre vitesse et commodité, selon l'application. Si c'est une tendance réelle, le matériel que nous aurons dans cent ans ne devrait faire qu'accentuer cette tendance.

Et pourtant, il n'y aura peut-être que quelques langages largement utilisés dans cent ans. Une partie de la raison pour laquelle je dis cela est l'optimisme : il semble que, si vous faisiez un travail vraiment bon, vous pourriez créer un langage qui serait idéal pour écrire une version 1 lente, et pourtant, avec les bons conseils d'optimisation pour le compilateur, produirait également un code très rapide si nécessaire. Donc, puisque je suis optimiste, je vais prédire que malgré l'énorme écart qu'ils auront entre une performance acceptable et maximale, les programmeurs dans cent ans auront des langages qui pourront couvrir la plupart de cet écart.

À mesure que cet écart se creusera, les profileurs deviendront de plus en plus importants. On accorde peu d'attention au profilage maintenant. Beaucoup de gens semblent encore croire que le moyen d'obtenir des applications rapides est d' écrire des compilateurs qui génèrent du code rapide. À mesure que l'écart entre les performances acceptables et maximales se creusera, il deviendra de plus en plus clair que le moyen d'obtenir des applications rapides est d'avoir un bon guide pour passer de l'un à l'autre.

Lorsque je dis qu'il ne peut y avoir que quelques langues, je n'inclus pas les "petites langues" spécifiques à un domaine. Je pense que de tels langages intégrés sont une excellente idée et je m'attends à ce qu'ils se multiplient. Mais je m'attends à ce qu'ils soient écrits de manière suffisamment mince pour que les utilisateurs puissent voir la langue générale sous-jacente.

Qui concevra les langues du futur ? L'une des tendances les plus passionnantes de ces dix dernières années a été l'essor de langages open source comme Perl, Python et Ruby. La conception des langages est reprise par les hackers. Les résultats sont jusqu'à présent désordonnés, mais encourageants. Il y a des idées étonnamment nouvelles dans Perl, par exemple. Beaucoup sont étonnamment mauvaises, mais c'est toujours le cas des efforts ambitieux. Au rythme actuel de sa mutation, Dieu sait ce que Perl pourrait devenir dans cent ans.

Il n'est pas vrai que ceux qui ne peuvent pas faire, enseignent (certains des meilleurs hackers que je connaisse sont des professeurs), mais il est vrai qu'il y a beaucoup de choses que ceux qui enseignent ne peuvent pas faire. La recherche impose des restrictions de caste contraignantes. Dans n'importe quel domaine universitaire, il y a des sujets sur lesquels il est acceptable de travailler et d'autres qui ne le sont pas. Malheureusement, la distinction entre les sujets acceptables et interdits est généralement basée sur la façon dont le travail semble intellectuel lorsqu'il est décrit dans des articles de recherche, plutôt que sur son importance pour obtenir de bons résultats. Le cas extrême est probablement la littérature ; les gens qui étudient la littérature disent rarement quelque chose qui serait de la moindre utilité pour ceux qui la produisent.

Bien que la situation soit meilleure dans les sciences, le chevauchement entre le type de travail que vous êtes autorisé à faire et le type de travail qui produit de bons langages est désespérément faible. (Olin Shivers s'en est plaint avec éloquence.) Par exemple, les types semblent être une source inépuisable d'articles de recherche, malgré le fait que le typage statique semble exclure de véritables macros - sans lesquelles, à mon avis, aucun langage ne vaut la peine d'être utilisé.

La tendance n'est pas seulement que les langages sont développés en tant que projets open source plutôt que "de recherche", mais que les langages sont conçus par les programmeurs d'applications qui ont besoin de les utiliser, plutôt que par les rédacteurs de compilateurs. Cette tendance semble bonne et je m'attends à ce qu'elle se poursuive.

Contrairement à la physique dans cent ans, qui est presque nécessairement impossible à prédire, je pense qu'il peut être possible en principe de concevoir maintenant un langage qui plairait aux utilisateurs dans cent ans.

Une façon de concevoir un langage est de simplement écrire le programme que l'on aimerait pouvoir écrire, indépendamment du fait qu'il existe ou non un compilateur capable de le traduire ou du matériel capable de l'exécuter. Lorsque vous faites cela, vous pouvez supposer des ressources illimitées. Il semble que nous devrions être capables d'imaginer des ressources illimitées aujourd'hui autant que dans cent ans.

Quel programme voudrait-on écrire ? Celui qui demande le moins de travail. Sauf pas tout à fait : celui qui demanderait le moins de travail si vos idées sur la programmation n'étaient pas déjà influencées par les langages auxquels vous êtes actuellement habitué. Cette influence peut être si omniprésente qu'il faut un grand effort pour la surmonter. On penserait que pour des créatures aussi paresseuses que nous, il serait évident de savoir comment exprimer un programme avec le moins d'efforts possible. En fait, nos idées sur ce qui est possible sont tellement limitées par la langue dans laquelle nous pensons que les formulations plus faciles des programmes semblent très surprenantes. Ce sont des choses que l'on doit découvrir, pas des choses dans lesquelles on s'enfonce naturellement.

Un truc utile ici est d'utiliser la longueur du programme comme approximation de la quantité de travail nécessaire pour l'écrire. Pas la longueur en caractères, bien sûr, mais la longueur en éléments syntaxiques distincts - en gros, la taille de l'arbre d'analyse. Il n'est peut-être pas tout à fait vrai que le programme le plus court est celui qui demande le moins de travail à écrire, mais c'est assez proche pour qu'il soit préférable de viser la cible solide de la brièveté plutôt que la cible floue et proche du moindre travail. Alors l'algorithme de conception de langage devient : regardez un programme et demandez-vous s'il y a un moyen de l'écrire de manière plus courte.

En pratique, écrire des programmes dans une langue imaginaire centenaire fonctionnera à des degrés divers selon la proximité avec le noyau. Vous pouvez écrire maintenant des routines de tri. Mais il serait difficile de prédire maintenant quels types de bibliothèques pourraient être nécessaires dans cent ans. Vraisemblablement, de nombreuses bibliothèques seront pour des domaines qui n'existent même pas encore. Si SETI@home fonctionne, par exemple, nous aurons besoin de bibliothèques pour communiquer avec des extraterrestres. À moins, bien sûr, qu'ils ne soient suffisamment avancés pour déjà communiquer en XML.

À l'autre extrême, je pense que vous pourriez être en mesure de concevoir le langage de base aujourd'hui. En fait, certains pourraient soutenir qu'il a déjà été principalement conçu en 1958.

Si la langue centenaire était disponible aujourd'hui, voudrions-nous y programmer ? Une façon de répondre à cette question est de regarder en arrière. Si les langages de programmation actuels avaient été disponibles en 1960, quelqu'un aurait-il voulu les utiliser ?

À certains égards, la réponse est non. Les langages d'aujourd'hui supposent une infrastructure qui n'existait pas en 1960. Par exemple, un langage dans lequel l'indentation est significative, comme Python, ne fonctionnerait pas très bien sur les terminaux d'imprimante. Mais en laissant de côté ces problèmes - en supposant, par exemple, que les programmes soient tous simplement écrits sur papier - les programmeurs des années 1960 auraient-ils aimé écrire des programmes dans les langages que nous utilisons maintenant ?

Je pense que oui. Certains d'entre eux, les moins imaginatifs, qui avaient des artefacts de langages anciens intégrés dans leurs idées de ce qu'était un programme, auraient peut-être eu du mal. (Comment peut-on manipuler des données sans faire d'arithmétique de pointeurs ? Comment peut-on implémenter des organigrammes sans gotos ?) Mais je pense que les programmeurs les plus intelligents n'auraient eu aucun mal à tirer le meilleur parti des langages d'aujourd'hui, s'ils les avaient eus.

Si nous avions la langue centenaire maintenant, ce serait au moins un excellent pseudocode. Que dire de l'utiliser pour écrire des logiciels ? Puisque la langue centenaire devra générer du code rapide pour certaines applications, elle pourrait probablement générer un code suffisamment efficace pour s'exécuter de manière acceptable sur notre matériel. Nous devrions peut-être donner plus de conseils d'optimisation que les utilisateurs dans cent ans, mais cela pourrait quand même être un gain net.

Maintenant, nous avons deux idées qui, si on les combine, suggèrent des possibilités intéressantes : (1) la langue centenaire pourrait, en principe, être conçue aujourd'hui, et (2) une telle langue, si elle existait, pourrait être bonne à programmer aujourd'hui. Quand on voit ces idées exposées ainsi, il est difficile de ne pas se dire : pourquoi ne pas essayer d'écrire la langue centenaire maintenant ?

Lorsque vous travaillez sur la conception de langages, je pense qu'il est bon d'avoir un tel objectif et de le garder consciemment à l'esprit. Quand vous apprenez à conduire, l'un des principes qu'on vous enseigne est d'aligner la voiture non pas en alignant le capot avec les bandes peintes sur la route, mais en visant un point à l'horizon. Même si tout ce qui vous intéresse est ce qui se passe dans les dix prochains pieds, c'est la bonne réponse. Je pense que nous pouvons et devrions faire la même chose avec les langages de programmation.

Notes

Je crois que Lisp Machine Lisp a été le premier langage à incarner le principe selon lequel les déclarations (à l'exception de celles des variables dynamiques) n'étaient que des conseils d'optimisation et ne changeraient pas le sens d'un programme correct. Common Lisp semble avoir été le premier à l'énoncer explicitement.

Remerciements à Trevor Blackwell, Robert Morris et Dan Giffin pour avoir lu les brouillons de ce texte, et à Guido van Rossum, Jeremy Hylton et le reste de l'équipe Python pour m'avoir invité à m'exprimer à PyCon.