LA LANGUE 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 lois 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 le logiciel contrôlant ces voitures volantes ?

Cela vaut la peine d'y réfléchir non pas tant parce que nous allons réellement 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 langages formeront des arbres évolutifs, avec des impasses se ramifiant partout. Nous pouvons déjà voir cela se produire. Cobol, malgré sa popularité parfois, 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 courriels en disant : "Comment pouvez-vous dire que Java ne sera pas un langage réussi ? C'est déjà un langage réussi." Et j'admets que c'est le cas, si vous mesurez le succès par l'espace de rayonnage occupé par des livres à son sujet (en particulier des livres individuels à son 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 sera pas un langage réussi, je veux dire quelque chose de plus spécifique : que Java s'avérera être une impasse évolutive, comme Cobol.

C'est juste 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 de faire en sorte que les gens se demandent, où sur l'arbre se trouve le langage X ? La raison de poser cette question n'est pas seulement pour que nos fantômes puissent dire, dans cent ans, je vous l'avais 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, vous êtes probablement le plus heureux sur les branches principales d'un arbre évolutif. Même lorsqu'il y avait encore beaucoup de néandertaliens, cela devait être désagréable d'en être un. Les Cro-Magnons auraient constamment débarqué et vous auraient battu et volé votre nourriture.

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

L'évolution des langages diffère de l'évolution des espèces parce que les branches peuvent converger. La branche Fortran, par exemple, semble fusionner avec les descendants d'Algol. En théorie, cela est également possible pour les espèces, mais il est peu probable que cela se soit produit pour quoi que ce soit de plus gros qu'une cellule.

La convergence est plus probable pour les langages 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 incorporent délibérément des idées d'autres langages.

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

Tout langage de programmation peut être divisé en deux parties : un 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 dans la survie à long terme d'un langage. Le reste, vous pouvez le changer. C'est comme la règle selon laquelle, en achetant une maison, vous devriez considérer l'emplacement avant tout. Tout le reste, vous pouvez le corriger plus tard, mais vous ne pouvez pas corriger 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 ressenti cela à propos des axiomes - moins il y en a, mieux c'est - et je pense qu'ils ont raison.

Au minimum, cela doit être un exercice utile d'examiner de près le cœur d'un langage pour voir s'il y a des axiomes qui pourraient être éliminés. J'ai découvert au cours de ma longue carrière de paresseux que le superflu engendre le superflu, et j'ai vu cela se produire dans les logiciels ainsi que sous les lits et dans les coins des pièces.

J'ai l'intuition que les branches principales de l'arbre évolutif passent par les langages qui ont les cœurs les plus petits et les plus propres. Plus vous pouvez écrire d'un langage en lui-même, mieux c'est.

Bien sûr, je fais une grande supposition en demandant même à quoi ressembleront les langages de programmation dans cent ans. Écrirons-nous même des programmes dans cent ans ? Ne dirons-nous pas simplement 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 avis est que dans cent ans, les gens diront encore aux ordinateurs quoi faire en utilisant des programmes que nous reconnaîtrions comme tels. Il peut y avoir des tâches que nous résolvons maintenant en écrivant des programmes et pour lesquelles, dans cent ans, vous n'aurez pas besoin d'écrire des 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 quiconque peut prédire à quoi ressemblera une technologie dans cent ans. Mais rappelez-vous que nous avons déjà presque cinquante ans d'histoire derrière nous. Regarder vers l'avenir dans cent ans est une idée saisissable lorsque nous considérons à quel point les langages ont évolué lentement au cours des cinquante dernières années.

Les langages évoluent lentement parce qu'ils ne sont pas vraiment des technologies. Les langages sont une notation. Un programme est une description formelle du problème que vous voulez qu'un ordinateur résolve pour vous. Ainsi, le taux d'évolution des langages de programmation est plus proche du taux d'évolution de la notation mathématique que, disons, des transports ou des communications. La notation mathématique évolue, mais pas avec les sauts géants que vous voyez dans la technologie.

Quoi que les ordinateurs soient faits 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 de s'appliquer, ils seront 74 quintillions (73,786,976,294,838,206,464) de fois plus rapides. C'est un peu difficile à imaginer. Et en effet, la prédiction la plus probable dans le domaine de la vitesse pourrait être que la loi de Moore cessera de fonctionner. Tout ce qui est censé doubler tous les dix-huit mois semble susceptible de rencontrer un certain type de limite fondamentale à un moment donné. Mais je n'ai aucun mal à croire que les ordinateurs seront beaucoup plus rapides. Même s'ils finissent par n'être qu'un misérable million de fois plus rapides, cela devrait changer les règles du jeu pour les langages de programmation de manière substantielle. 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 des ordinateurs sont créés par des ordinateurs ; par exemple, le taux auquel vous devez traiter des images vidéo dépend du taux auquel un autre ordinateur peut les générer. Et il existe une autre classe de problèmes qui ont intrinsèquement une capacité illimitée à absorber des cycles : le rendu d'images, la cryptographie, les simulations.

Si certaines applications peuvent devenir de plus en plus inefficaces tandis que d'autres continuent d'exiger toute la vitesse que le matériel peut fournir, des ordinateurs plus rapides signifieront que les langages devront couvrir une gamme d'efficacités de plus en plus large. Nous avons déjà vu cela se produire. Les implémentations actuelles de certains nouveaux langages populaires sont choquantes 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 étonnés de voir à quel point nous passons des appels téléphoniques longue distance de manière désinvolte. Les gens d'il y a cent ans seraient encore plus étonnés 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 dans les cent prochaines années. Ils seront presque tous gaspillés.

J'ai appris à programmer lorsque la puissance des ordinateurs était rare. Je me souviens d'avoir retiré tous les espaces de mes programmes Basic pour qu'ils tiennent dans la mémoire d'un TRS-80 de 4K. La pensée de tout ce logiciel stupéfiant et 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 pauvre et qui ne peut pas supporter de dépenser de l'argent même pour quelque chose d'important, comme aller chez le médecin.

Certaines formes de gaspillage sont vraiment dégoûtantes. Les SUV, par exemple, seraient sans doute dégoûtants même s'ils fonctionnaient avec un carburant qui ne s'épuiserait jamais et ne produisait aucune pollution. Les SUV sont dégoûtants parce qu'ils sont la solution à un problème dégoûtant. (Comment faire en sorte que les minivans aient l'air plus masculins.) Mais tout gaspillage n'est pas mauvais. Maintenant que nous avons l'infrastructure pour le soutenir, compter les minutes de vos appels longue distance 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 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 - celui où, en dépensant plus, nous pouvons obtenir des conceptions plus simples. Comment allons-nous tirer parti des opportunités de gaspillage de cycles que nous obtiendrons grâce à un matériel nouveau et plus rapide ?

Le désir de vitesse est si profondément ancré en nous, avec nos ordinateurs chétifs, qu'il faudra un effort conscient pour le surmonter. Dans la conception de langages, nous devrions chercher consciemment des situations où nous pouvons échanger l'efficacité contre même la plus petite augmentation de commodité.

La plupart des structures de données existent à cause de la vitesse. Par exemple, de nombreux langages aujourd'hui ont à la fois des chaînes et des listes. Sémantiquement, les chaînes sont plus ou moins un sous-ensemble de listes dans lequel 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 n'existent que pour l'efficacité. Mais c'est ennuyeux de surcharger la sémantique du langage avec des astuces pour faire fonctionner les programmes plus rapidement. Avoir des chaînes 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 certainement 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, n'avoir que des listes, avec un moyen de donner des conseils d'optimisation au compilateur qui lui permettra de disposer les chaînes en tant qu'octets contigus si nécessaire.

Puisque la vitesse n'a pas d'importance dans la plupart d'un programme, vous n'aurez ordinairement pas besoin de vous soucier de ce genre de microgestion. 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 "essayer". 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 lorsqu'ils ont commencé.

Les hackers Lisp savent déjà la valeur d'être flexibles 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 si choquantes d'inefficacité qu'il faut un effort conscient pour ne pas penser à ce qu'elles font, tout comme, pour moi au moins, manger un steak nécessite un effort conscient pour ne pas penser à son origine.

Ce que les programmeurs dans cent ans rechercheront, avant tout, c'est un langage où vous pouvez assembler une version 1 incroyablement inefficace d'un programme avec le moins d'effort possible. Du moins, c'est ainsi que nous le décririons en termes contemporains. 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 de la machine. Cela deviendra de plus en plus clair à mesure que les ordinateurs deviendront plus rapides.

Je pense que se débarrasser des chaînes est déjà quelque chose à laquelle nous pourrions réfléchir. Nous l'avons fait dans Arc, et cela semble être un avantage ; certaines opérations qui seraient difficiles à 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 penser à des possibilités qui choquent même moi, avec mon esprit consciencieusement élargi. Vont-nous nous débarrasser des tableaux, par exemple ? Après tout, ils ne sont qu'un sous-ensemble des tables de hachage où les clés sont des vecteurs d'entiers. Vont-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 de 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 manière. C'est juste incroyablement inefficace.

Personne n'a réellement proposé d'implémenter des nombres sous forme de listes dans la pratique. En fait, le papier de McCarthy de 1960 n'était pas, à l'époque, destiné à être implémenté 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 pris ce papier et l'a traduit de manière inattendue 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 en tant que type de données fondamental ? Je pose cette question non pas tant comme une question sérieuse que comme un moyen de jouer à la roulette avec l'avenir. C'est comme le cas hypothétique d'une force irrésistible rencontrant un objet immuable - ici, une implémentation incroyablement inefficace rencontrant des ressources incroyablement grandes. Je ne vois pas pourquoi pas. L'avenir est assez long. S'il y a quelque chose que nous pouvons faire pour diminuer le nombre d'axiomes dans le langage de base, cela semblerait être le côté sur lequel parier à mesure que t approche l'infini. Si l'idée semble encore insupportable dans cent ans, peut-être ne le sera-t-elle pas dans mille ans.

Pour être clair à ce sujet, je ne propose pas que tous les calculs numériques soient réellement effectués en utilisant des listes. Je propose que le langage de base, avant toute notation supplémentaire sur l'implémentation, soit défini de cette manière. En pratique, tout programme qui voudrait faire une certaine quantité de mathématiques représenterait probablement les nombres en binaire, mais cela serait une optimisation, pas une partie 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 aussi une tendance que nous voyons déjà se produire : de nombreux langages récents sont compilés en bytecode. Bill Woods m'a dit un jour qu'en règle générale, chaque couche d'interprétation coûte un facteur de 10 en vitesse. Ce coût supplémentaire vous achète de la flexibilité.

La toute première version d'Arc était un cas extrême de ce type de lenteur multi-niveaux, avec des avantages correspondants. C'était un interpréteur "métacirculaire" classique écrit sur Common Lisp, avec une certaine ressemblance familiale avec la fonction eval définie dans le papier original de Lisp de McCarthy. L'ensemble ne faisait que quelques centaines de lignes de code, donc il était très facile à comprendre et à modifier. Le Common Lisp que nous utilisions, CLisp, fonctionne 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 choquante d'inefficacité, et le langage était utilisable. À peine utilisable, j'admets, mais utilisable.

Écrire des logiciels sous forme de plusieurs couches est une technique puissante même au sein des applications. La programmation ascendante signifie écrire un programme comme une série de couches, chacune servant de langage pour celle au-dessus. Cette approche tend à produire des programmes plus petits et plus flexibles. C'est aussi le meilleur moyen d'atteindre ce saint graal, la réutilisabilité. Un langage est par définition réutilisable. Plus vous pouvez pousser de votre application dans un langage pour écrire ce type d'application, plus votre logiciel sera réutilisable.

D'une manière ou d'une autre, l'idée de réutilisabilité a été attachée à la programmation orientée objet dans les années 1980, et aucune quantité de preuves contraires ne semble pouvoir la libérer. Mais bien que certains logiciels orientés objet soient réutilisables, ce qui les rend réutilisables est leur nature ascendante, pas leur nature orientée objet. Considérez les bibliothèques : elles sont réutilisables parce qu'elles sont un langage, qu'elles soient écrites dans un style orienté objet ou non.

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. Elle vous permet d'accumuler des programmes sous forme de séries 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 de calcul parallèle, car c'est là que cette idée semble vivre. C'est-à-dire que peu importe quand vous parlez, le calcul parallèle semble être quelque chose qui va se produire dans le futur.

L'avenir rattrapera-t-il jamais cela ? 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 pas ? Déjà, les concepteurs de puces doivent y penser, tout comme ceux qui essaient d'écrire des logiciels système sur des ordinateurs multi-CPU.

La vraie question est de savoir jusqu'où le parallélisme ira dans l'échelle d'abstraction ? Dans cent ans, affectera-t-il même les programmeurs d'application ? Ou sera-t-il quelque chose auquel les rédacteurs de compilateurs pensent, mais qui est généralement invisible dans le code source des applications ?

Une chose qui semble probable 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 informatique supplémentaire que nous recevons sera gaspillée. Je m'attends à ce qu'avec 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 n'est ordinairement 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, cela ressemble davantage à la capacité de créer des processus qui finissent tous par s'exécuter en parallèle.

Et cela sera, comme demander des implémentations spécifiques de structures de données, quelque chose que vous ferez assez tard dans la vie d'un programme, lorsque vous essayez de l'optimiser. Les versions 1 ignoreront ordinairement tout avantage à tirer du calcul parallèle, tout comme elles ignoreront les avantages à tirer de représentations spécifiques des données.

Sauf dans des types d'applications spéciales, le parallélisme ne pénétrera pas les programmes qui seront écrits dans cent ans. Ce serait une optimisation prématurée si c'était le cas.

Combien de langages de programmation y aura-t-il dans cent ans ? Il semble qu'il y ait un nombre énorme de nouveaux langages de programmation ces derniers temps. Une partie de la raison est que le matériel plus rapide a permis aux programmeurs de faire différents compromis entre vitesse et commodité, selon l'application. Si c'est une véritable tendance, le matériel que nous aurons dans cent ans ne fera qu'augmenter cela.

Et pourtant, il pourrait n'y avoir 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 très bon travail, vous pourriez créer un langage qui serait idéal pour écrire une version lente 1, et pourtant avec les bons conseils d'optimisation au compilateur, produirait également un code très rapide lorsque cela est nécessaire. Donc, puisque je suis optimiste, je vais prédire qu'en dépit du grand écart qu'ils auront entre l'efficacité acceptable et maximale, les programmeurs dans cent ans auront des langages qui peuvent couvrir la plupart de cela.

À mesure que cet écart se creuse, les profileurs deviendront de plus en plus importants. Peu d'attention est accordée au profilage maintenant. Beaucoup de gens semblent encore croire que la façon d'obtenir des applications rapides est d'écrire des compilateurs qui génèrent du code rapide. À mesure que l'écart entre la performance acceptable et maximale s'élargit, il deviendra de plus en plus clair que la façon d'obtenir des applications rapides est d'avoir un bon guide de l'un à l'autre.

Quand je dis qu'il pourrait n'y avoir que quelques langages, je n'inclus pas les "petits langages" 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 prolifèrent. Mais je m'attends à ce qu'ils soient écrits comme des peaux suffisamment fines pour que les utilisateurs puissent voir le langage généraliste en dessous.

Qui concevra les langages du futur ? L'une des tendances les plus passionnantes des dix dernières années a été l'essor des langages open-source comme Perl, Python et Ruby. La conception de langages est en train d'être prise en charge par des hackers. Les résultats jusqu'à présent sont désordonnés, mais encourageants. Il y a des idées incroyablement novatrices dans Perl, par exemple. Beaucoup sont incroyablement mauvaises, mais c'est toujours vrai des efforts ambitieux. À son rythme actuel de mutation, Dieu sait en quoi Perl pourrait évoluer dans cent ans.

Il n'est pas vrai que ceux qui ne peuvent pas faire, enseignent (certains des meilleurs hackers que je connais 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 académique, 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 sonne intellectuellement 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 personnes étudiant la littérature disent rarement quoi que ce soit qui serait d'une utilité quelconque 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 petit. (Olin Shivers s'est plaint éloquemment à ce sujet.) Par exemple, les types semblent être une source inépuisable d'articles de recherche, malgré le fait que le typage statique semble exclure les véritables macros - sans lesquelles, à mon avis, aucun langage ne vaut la peine d'être utilisé.

La tendance n'est pas seulement vers des langages développés en tant que projets open-source plutôt que "de recherche", mais vers des langages conçus par les programmeurs d'application qui ont besoin de les utiliser, plutôt que par des rédacteurs de compilateurs. Cela semble être une bonne tendance 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 un langage maintenant qui plairait aux utilisateurs dans cent ans.

Une façon de concevoir un langage est d'écrire simplement le programme que vous aimeriez pouvoir écrire, peu importe s'il existe un compilateur qui peut le traduire ou un matériel qui peut 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 aussi bien aujourd'hui que dans cent ans.

Quel programme aimerait-on écrire ? Tout ce qui nécessite le moins de travail. Sauf que pas tout à fait : tout ce qui serait 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é. Une telle influence peut être si omniprésente qu'il faut un grand effort pour la surmonter. Vous penseriez qu'il serait évident pour des créatures aussi paresseuses que nous comment exprimer un programme avec le moins d'effort. En fait, nos idées sur ce qui est possible tendent à être si limitées par le langage dans lequel nous pensons que des formulations plus faciles de programmes semblent très surprenantes. Ce sont des choses que vous devez découvrir, pas quelque chose dans lequel vous vous plongez naturellement.

Un truc utile ici est d'utiliser la longueur du programme comme une approximation de la quantité de travail qu'il faut pour écrire. Pas la longueur en caractères, bien sûr, mais la longueur en éléments syntaxiques distincts - essentiellement, la taille de l'arbre de syntaxe. Il se peut qu'il ne soit pas tout à fait vrai que le programme le plus court est le moins de travail à écrire, mais c'est assez proche pour que vous ayez intérêt à viser la cible solide de la brièveté plutôt que la cible floue, proche, du moindre travail. Ensuite, l'algorithme pour la conception de langages devient : regardez un programme et demandez-vous, y a-t-il un moyen d'écrire cela qui soit plus court ?

En pratique, écrire des programmes dans un langage imaginaire de cent ans fonctionnera à des degrés divers selon la proximité que vous avez avec le cœur. Les routines de tri que vous pouvez écrire maintenant. Mais il serait difficile de prédire maintenant quels types de bibliothèques pourraient être nécessaires dans cent ans. Presque toutes les bibliothèques seront probablement 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 communiquer déjà 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 le langage centenaire était disponible aujourd'hui, voudrions-nous programmer avec ? Une façon de répondre à cette question est de regarder en arrière. Si les langages de programmation d'aujourd'hui 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 des terminaux d'imprimante. Mais en mettant de côté de tels problèmes - en supposant, par exemple, que les programmes étaient 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 des moins imaginatifs, qui avaient des artefacts des premiers langages intégrés dans leurs idées de ce qu'était un programme, auraient pu avoir des difficultés. (Comment pouvez-vous manipuler des données sans faire d'arithmétique de pointeur ? Comment pouvez-vous implémenter des organigrammes sans des 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 le langage centenaire maintenant, cela ferait au moins un excellent pseudocode. Qu'en est-il de l'utiliser pour écrire des logiciels ? Puisque le langage centenaire devra générer du code rapide pour certaines applications, il pourrait vraisemblablement générer un code suffisamment efficace pour fonctionner 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 tout de même être un gain net.

Maintenant, nous avons deux idées qui, si vous les combinez, suggèrent des possibilités intéressantes : (1) le langage centenaire pourrait, en principe, être conçu aujourd'hui, et (2) un tel langage, s'il existait, pourrait être bon à programmer aujourd'hui. Lorsque vous voyez ces idées exposées de cette manière, il est difficile de ne pas penser, pourquoi ne pas essayer d'écrire le langage 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. Lorsque vous apprenez à conduire, l'un des principes qu'ils vous enseignent est d'aligner la voiture non pas en alignant le capot avec les bandes peintes sur la route, mais en visant un point dans le lointain. 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 (sauf 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 des brouillons de ceci, et à Guido van Rossum, Jeremy Hylton et le reste de l'équipe Python pour m'avoir invité à parler à PyCon.