dorianmarie.com | Paul Graham | Legal | Terms | Privacy

Le Language de Cent-Ans

Chapitre 11

Il est difficile de prédire à quoi ressemblera la vie dans cent ans. Il n’y a que 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 aux bâtiments de plusieurs centaines d’étages, qu’il fera nuit la plupart du temps et que les femmes seront toutes formées aux arts martiaux. Ici, je veux zoomer 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 penser, non pas tant que nous utiliserons effectivement ces langages que parce que, si nous avons de la chance, nous utilisons des langages sur le chemin qui mène d’un point à un autre.

Je pense que, comme les espèces, les langues formeront des arbres évolutifs, avec des impasses qui se ramifient partout. Nous pouvons déjà voir cela se produire. Cobol, malgré sa popularité, ne semble pas avoir de descendance intellectuelles. C’est une impasse évolutive, une langue néandertale.

Je prédis un futur similaire pour Java. Les gens m’envoient parfois des courriels en disant : “Comment pouvez-vous dire que Java ne s’est pas révélé être un langage réussi ? C’est déjà un langage à succès. » Et j’admets que c’est le cas, si vous mesurez le succès par l’espace d’étagère occupé par les livres dessus, ou par le nombre d’ étudiants de premier cycle qui croient qu’ils doivent l’apprendre pour obtenir un emploi. Quand je dis que Java ne s’est pas révélé être un langage réussi, je veux dire quelque chose de plus spécifique : que Java s’est révélé être une impasse évolutive, comme Cobol.

Ce n’est qu’une supposition. Je me trompe peut-être. Mon but ici n’est pas de casser Java, mais de soulever la question des arbres évolutifs et d’ amener les gens à se demander, où sur l’arbre se trouve le langage x ? La raison de poser cette question n’est pas seulement pour que dans cent ans, nos fantômes puissent dire, je vous l’ai dit. C’est parce que rester près des branches principales est une heuristique utile pour trouver des langages qui seront bons à programmer maintenant.

À tout moment, vous serez probablement le plus heureux sur les branches principales d’un arbre évolutif. Même quand il y avait encore beaucoup de Néandertaliens, il a dû être nul d’en être un. Les Cro-Magnons auraient constamment été en train de venir se battre avec vous et de 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 langages diffère de l’évolution des espèces parce que les branches peuvent converger. La branche de Fortran, par exemple, semble fusionner avec les descendants d’Algol. En théorie, c’est possible pour les espèces aussi, mais c’est si peu probable que cela ne se soit probablement jamais produit.

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 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 à l’évolution des langages de programmation qui est susceptible de mener, car ils peuvent se diriger 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 en matière de conception du langage.

N’importe quel 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 les facteurs les plus importants dans la survie à long terme d’un langage. Le reste, vous pouvez changer. C’est comme la règle selon laquelle lors de l’achat d’une maison, vous devez d’abord tenir compte de l’emplacement. Tout le reste, vous pouvez le réparer plus tard, mais vous ne pouvez pas réparer l’emplacement.

Il est important non seulement que les axiomes soient bien choisis, mais aussi 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 mis le doigt sur quelque chose.

À tout le moins, il doit être utile d’examiner de près le noyau d’un langage pour voir s’il y a des axiomes qui pourraient être éliminés. J’ai trouvé dans ma longue carrière de bidouilleur que le croûtage élève le croûtage, et j’ai vu cela se produire dans les logiciels ainsi que sous les lits et dans les coins des chambres.

J’ai l’impression que les branches principales de l’arbre évolutif passent par les langages qui ont les noyaux les plus petits et les plus propres. Plus vous pouvez écrire d’un langage en soi, 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 département jusqu’à présent. Je suppose que dans cent ans, les gens diront toujours 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 que dans cent ans, vous n’aurez pas à écrire des programmes à 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 n’importe qui peut prédire à quoi ressemblera n’importe quelle technologie dans cent ans. Mais rappelons-nous que nous avons déjà près de cinquante ans d’histoire derrière nous. Regarder vers l’avenir 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’elles ne sont pas vraiment des technologies. Les langages sont la 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 dans les langages de programmation ressemble plus au taux d’évolution en notation mathématique que, par exemple, au transport ou aux communications. La notation mathématique évolue, mais pas avec les sauts géants que vous voyez dans la technologie.

Quels que soient les ordinateurs dans cent ans, il semble sûr de prédire qu’ils seront beaucoup plus rapides. Si la loi de Moore continue de s’édifier, elle sera 74 quintillions (73 786 976 294 838 206 464) fois plus rapide. C’est un peu difficile à imaginer. Et en effet, la prédiction la plus probable dans le département de la vitesse est 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 sorte de limite fondamentale. Mais je n’ai aucun mal à croire que les ordinateurs seront beaucoup plus rapides. Même s’ils finissent par être un million de fois plus rapides, cela devrait changer considérablement les règles de base pour les 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 donnent 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 des ordinateurs ; par exemple, la vitesse à laquelle vous devez traiter les images vidéo dépend de la vitesse à laquelle un autre ordinateur peut les générer. Et il y a une autre classe de problèmes qui ont intrinsèquement une capacité illimitée pour 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 d’exiger toute la vitesse que le matériel peut offrir, des ordinateurs plus rapides signifieront que les langages devront couvrir un éventail toujours plus large d’efficacités. Nous avons déjà vu cela se produire. Les implémentations actuelles de certains nouveaux langages populaires sont étonnamment inutiles selon les normes des décennies précédentes.

Ce n’est pas seulement quelque chose qui se passe avec les langages de programmation. C’est une tendance historique générale. Au fur et à 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. Il y a trente ans, les gens étaient étonnés de voir à quel point nous faisions des appels téléphoniques interurbains. Il y a cent ans, les gens seraient encore plus étonnés qu’un forfait voyage d’un jour de Boston à New York via Memphis existe.

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 vont presque tous être gaspillés.

J’ai appris à programmer quand la puissance de l’ordinateur était rare. Je me souviens avoir pris tous les espaces de mes programmes de base pour qu’ils s’intègrent dans la mémoire d’un TRS-80 4K. L’idée de tous ces logiciels incroyablement inefficaces qui brûlent des cycles en faisant la même chose encore et encore me semble un peu grossière. Mais je pense que mes intuitions ici sont fausses. Je suis comme quelqu’un qui a grandi pauvre et qui ne supporte pas de dépenser de l’argent même pour quelque chose d’important, comme aller chez le médecin.

Certains types de déchets sont vraiment dégoûtants. Les SUVs, par exemple, seraient sans doute grossiers même s’ils étaient alimentés par un carburant qui ne s’épuiserait jamais et ne générerait aucune pollution. Les SUVs sont grossiers parce qu’ils sont la solution à un problème grossier. (Comment rendre les mini-fourgonnettes plus masculines.) Mais tous les déchets ne sont pas mauvais. Maintenant que nous avons l’infrastructure pour le prendre en charge, compter les minutes de vos appels longue distance commence à sembler tatillon. Si vous avez les ressources, il est plus élégant de considérer tous les appels téléphoniques comme un seul genre de chose, peu importe où se trouve l’autre personne.

Il y a de bons déchets et de mauvais déchets. Je m’intéresse aux bons déchets - ceux où, en dépensant plus, nous pouvons obtenir des conceptions plus simples. Comment allons-nous profiter des opportunités de gaspillage des cycles que nous obtiendrons du nouveau matériel plus rapide ?

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

La plupart des structures de données existent en raison de la vitesse. Par exemple, de nombreuses langues d’aujourd’hui ont à la fois des chaînes et des listes. Sur le plan sémantique, les chaînes sont plus ou moins un sous-ensemble de listes dans lesquelles les éléments sont des caractères. Alors, pourquoi avez-vous besoin d’un type de données distinct ? Vous ne le faites pas, vraiment. Les cordes n’existent que pour l’efficacité. Mais c’est boiteux d’encombrer les caractéristiques d’un langage avec des hacks pour que les programmes s’exécutent plus rapidement. Avoir des cordes dans un langage semble être un cas d’opération prématurée.

Si nous pensons au cœur d’un langage comme à un ensemble d’axiomes, il est sûrement grossier d’avoir des axiomes supplémentaires qui n’ajoutent aucun pouvoir expressif, simplement par souci 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 est de séparer la signification d’un programme des détails de la mise en œuvre. Au lieu d’avoir à la fois des listes et des chaînes, n’ayez que des listes, avec un moyen de donner au compilateur des conseils d’optimisation qui lui permettront de présenter des chaînes en octets contigus si nécessaire ¹.

Étant donné que la vitesse n’a pas d’importance dans la majeure partie des programmes, vous n’aurez normalement pas besoin de vous préoccuper de ce genre de micro-gestion. Cela sera de plus en plus vrai au fur et à mesure que les ordinateurs deviendront plus rapides..

Dire moins sur la mise en œuvre devrait également rendre les programmes plus flexibles. Les spécifications changent pendant qu’un programme est écrit, et c’est non seulement inévitable, mais aussi souhaitable.

Le mot “essay” vient du verbe français “essayer”. Un essai, au 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, en ce sens que les auteurs ne savaient pas quand ils ont commencé exactement ce qu’ils essayaient d’écrire.

Les hackers Lisp connaissent déjà l’intérêt d’être flexible avec les structures de données. Nous avons tendance à écrire la première version d’un programme pour qu’il fasse tout avec des listes. Ces versions initiales peuvent être si étonnamment inefficaces 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 d’où il vient.

Ce que les programmeurs dans cent ans chercheront, surtout, c’est un langage où vous pouvez assembler une version 1 incroyablement inefficace d’un programme avec le moins d’effort possible. Au moins, c’est ainsi que nous le décririons en termes actuels. Ce qu’ils diront, c’est qu’ils veulent un langage facile à programmer.

Les logiciels inefficaces ne sont pas grossiers. Ce qui est grossier, c’est un langage qui oblige les programmeurs à faire un travail inutile. La gaspillage du temps du programmeur est la véritable inefficacité, et non le gaspillage du temps de la machine. Cela sera de plus en plus clair au fur et à mesure que les ordinateurs deviendront plus rapides.

Je pense que se débarrasser des ficelles est déjà quelque chose à laquelle nous pourrions supporter de penser. Nous l’avons fait dans Arc, et cela semble être une victoire ; certaines opérations qui seraient difficiles à décrire comme expressions régulières peuvent être facilement décrites comme des fonctions récursives.

Jusqu’où ira cet aplatissement des structures de données ? Je peux penser à des possibilités qui me choquent même, avec mon esprit consciencieusement large. Allons-nous nous débarrasser des tableaux, par exemple ? Après tout, ils ne sont qu’un sous-ensemble de tables de hachage où les clés sont des vecteurs entiers. Allons-nous remplacer les tables de hachage elles-mêmes par des listes?

Il y a même plus de perspectives choquantes que cela. Logiquement, vous n’avez pas besoin d’avoir une notion distincte des nombres, car vous pouvez les représenter sous forme de listes : l’entier n pourrait être représenté sous la forme d’une liste de n éléments. Vous pouvez faire des maths de cette façon. C’est tout simplement insupportablement inefficace.

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 moins comme une question sérieuse que comme une façon 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 rencontre de mise en œuvre inimaginablement inefficace rencontrant des ressources inimaginablement 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 à l’approche de l’infini. Si l’idée semble encore insupportable dans cent ans, peut-être qu’elle ne le sera pas dans mille ans.

Juste pour être clair à ce sujet, je ne propose pas que tous les calculs numériques soient réellement 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 façon. En pratique, tout programme qui voudrait faire une quantité quelconque de mathématiques représenterait probablement des nombres en binaire, mais ce serait une optimisation, et ne ferait pas partie de la sémantique du langage de base.

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 code d’octets. Bill Woods m’a dit un jour que, en règle générale, chaque couche d’interprétation coûte un facteur dix en vitesse. Ce coût supplémentaire vous fait gagner de la flexibilité.

La toute première version d’Arc était un cas extrême de ce genre de lenteur à plusieurs niveaux, avec les avantages correspondants. Il s’agissait d’un interprète “métacirculaire” classique écrit sur Common Lisp, avec une certaine ressemblance familiale avec la fonction d’évaluation définie dans l’article original de Lisp de McCarthy. Le tout n’était que de quelques centaines de lignes de code, donc c’était facile à comprendre et à changer. Le Common Lisp que nous avons utilisé, CLisp, s’exécute lui-même sur un interpréteur de code octet. Nous avions donc ici deux niveaux d’interprétation, l’un d’eux (le premier) étonnamment inefficace, et le langage était utilisable. À peine utilisable, je l’avoue, mais utilisable.

Écrire des logiciels en plusieurs couches est une technique puissante, même dans les applications. La programmation ascendante signifie l’écriture d’un programme sous la forme d’une série de couches, dont chacune sert de langage pour celle ci-dessus. Cette approche a tendance à produire des programmes plus petits et plus flexibles. C’est aussi la meilleure route vers ce Saint Graal, la réutilisabilité. Une langue est par définition réutilisable. Plus vous poussez votre application dans un langage permettant d’é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é s’est attachée à la programmation orientée objet dans les années 1980, et aucune preuve du contraire ne semble être en mesure de la secouer librement. Mais bien que certains logiciels orientés objet soient réutilisables, ce qui le rend réutilisable, c’est sa position ascendante, pas son orientation objet. Considérez les bibliothèques : elles sont réutilisables parce qu’elles sont du 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, soit dit en passant. Bien que je ne pense pas qu’il ait grand-chose à offrir à de bons professionnels, sauf dans certains domaines spécialisés, il est irrésistible pour les grandes organisations. La programmation orientée objet offre un moyen durable d’écrire du code spaghetti. Il vous permet d’accréditer les programmes sous la forme d’une série de correctifs. Les grandes organisations ont toujours tendance à développer des logiciels de cette façon, 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, parce que c’est là que cette idée semble vivre. À tout moment, cela semble toujours être quelque chose qui va se produire à l’avenir.

L’avenir le rattrapera-t-il un jour ? Les gens parlent du calcul parallèle comme de quelque chose d’imminent depuis au moins vingt ans, et cela n’a pas beaucoup affecté la pratique de la programmation jusqu’à présent. Ou n’est-ce pas ? Les concepteurs de puces doivent déjà y réfléchir, tout comme les gens qui essaient d’écrire des logiciels système sur des ordinateurs multi-CPU.

La vraie question est la suivante : jusqu’où ira le parallélisme dans l’échelle de l’abstraction ? Dans cent ans, cela affectera-t-il même les programmeurs d’applications ? Ou est-ce quelque chose auquel les rédacteurs compilateurs pensent, mais qui est 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 plus grande prédiction que la majeure partie de la puissance supplémentaire de l’ordinateur qui nous est donnée sera gaspillée. Je m’attends à ce que, comme pour la vitesse prodigieuse du matériel déséquilibré et, le parallélisme sera quelque chose qui sera disponible si vous le demandez explicitement, mais normalement pas utilisé. Cela implique que le genre de parallélisme que nous avons 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, il s’agira plutôt d’être en mesure de dériver des processus qui finissent tous par s’exécuter en parallèle.

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

Sauf dans les types spéciaux d’applications, le parallélisme n’imprégnera pas les programmes qui sont é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 y avoir un grand nombre de nouveaux langages de programmation ces derniers temps. Une partie de la raison en est que le matériel plus rapide a permis aux programmeurs de faire différents compromis entre la vitesse et la commodité, en fonction de l’application. S’il s’agit d’une véritable tendance, le matériel que nous aurons dans cent ans ne devrait que l’augmenter.

Et pourtant, il n’y a peut-être que quelques langages largement utilisés en 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 idéal pour écrire une version lente 1, et pourtant, avec les bons conseils d’optimisation au compilateur, vous donneriez également un code rapide si nécessaire. Donc, puisque je suis optimiste, je vais prédire que malgré l’énorme écart qu’ils auront entre l’efficacité acceptable et l’efficacité maximale, les programmeurs dans cent ans auront des langages qui peuvent couvrir la majeure partie de celui-ci.

Au fur et à mesure que cet écart s’élargira, 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. Au fur et à mesure que l’écart entre les performances acceptables et maximales 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 n’y a peut-être que quelques langages, je n’inclue pas les “petits langages” spécifiques au domaine. Je pense que de tels langages embarqué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 assez fines pour que les utilisateurs puissent voir le langage général en dessous.

Qui concevra les langues du futur ? L’une des tendances les plus citées au cours des dix dernières années a été l’essor des langages open source comme Perl, Python et Ruby. La conception du langage est 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 nouvelles à Perl, par exemple. Beaucoup sont incroyablement mauvais, mais c’est toujours le cas des efforts ambitieux. À son taux de mutation actuel, 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 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 contraignantes liées à la caste. 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 semble intellectuel lorsqu’il est décrit dans les documents de recherche, plutôt que sur l’importance qu’il est pour obtenir de bons résultats. Le cas extrême est probablement la littérature ; les personnes qui étudient la littérature disent rarement quoi que ce soit qui serait de la moindre utilité pour ceux qui la produisent.

Bien que la situation soit meilleure dans les sciences, le chevauchement entre le genre de travail que vous êtes autorisé à faire et le genre de travail qui donne de bons langages est péniblement petit. (Olin Shivers s’est exprimé de manière très éloquente à 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 vrais macros - sans lesquelles, à mon avis, aucun langage ne vaut la peine d’être utilisé.

La tendance n’est pas seulement vers les langages développés en tant que projets open source plutôt que “recherche”, mais aussi vers les langages conçus par les programmeurs d’applications qui ont besoin de les utiliser, plutôt que par les 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, 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 de simplement écrire le programme que vous aimeriez pouvoir écrire, qu’il y ait un compilateur qui peut le traduire ou du matériel qui peut l’exécuter. Lorsque vous faites cela, vous pouvez assumer des ressources illimitées. Il semble que nous devrions être en mesure d’imaginer des ressources illimitées aussi bien aujourd’hui qu’en cent ans.

Quel programme aimerait-on écrire ? Quel que soit le moins de travail. Sauf que pas tout à fait : tout ce qui serait le moins fonctionnerait si vos idées sur la programmation n’étaient pas déjà influencées par les langages auxquels vous êtes actuellement habitué.es. Une telle influence peut être si omniprésente qu’il faut beaucoup d’efforts pour la surmonter. On pourrait penser 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 ont tendance à être si limitées par le langage que nous pensons que les formulations plus faciles de programmes semblent très surprenantes. C’est quelque chose que vous devez découvrir, pas quelque chose dans lequel vous vous enfoncez naturellement.

Une astuce utile ici est d’utiliser la longueur du programme comme une approximation de la quantité de travail qu’il est à écrire. Pas la longueur des caractères, bien sûr, mais la longueur des éléments syntaxiques distincts - fondamentalement, la taille de l’arbre d’analyse. Il n’est peut-être pas tout à fait vrai que le programme le plus court est le moins de travail à écrire, mais il est assez proche pour que vous soyez mieux de viser la cible solide de la brièveté que le flou, à proximité de l’un des moins de travail. Ensuite, l’algorithme de conception du langage devient : regardez un programme et demandez, y a-t-il un moyen plus court d’écrire ceci ?

En pratique, les programmes d’écriture dans une langue imaginaire centenaire fonctionneront à des degrés divers en fonction de votre proximité avec le noyau. Triez les routines 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. On peut supposer que 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 les extraterrestres. À moins bien sûr qu’ils ne soient suffisamment avancés pour qu’ils communiquent 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 faire valoir qu’il a déjà été principalement conçu en 1958.

Si le langage 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 ?

D’une certaine manière, la réponse est non. Les langues d’aujourd’hui supposent une infrastructure qui n’existait pas en 1960. Par exemple, un langage dans lequel l’indentation est importante, comme Python, ne fonctionnerait pas très bien sur les terminaux d’imprimante. Mais en mettant de tels problèmes de côté - en supposant, par exemple, que les programmes étaient tout simplement écrits sur papier - les programmeurs des années 1960 auraient-ils aimé écrire des programmes dans les langues que nous utilisons maintenant ?

Je pense que c’est le cas. Certains des moins imaginatifs, qui avaient des faits d’art des premières langues intégrés dans leurs idées de ce qu’était un programme, auraient peut-être eu des problèmes. (Comment pouvez-vous manipuler les données sans faire de l’arithmétique des pointeurs ? Comment pouvez-vous mettre en œuvre 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 eu.

Si nous avions le langage centenaire maintenant, cela ferait au moins un excellent pseudocode. Que diriez-vous de l’utiliser pour écrire des logiciels ? Étant donné que 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 devrons peut-être donner plus de conseils d’optimisation que les utilisateurs dans cent ans, mais cela pourrait toujours être une victoire nette.

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. Quand vous voyez ces idées présentées comme ça, il est difficile de ne pas penser, pourquoi ne pas essayer d’écrire la langue centenaire maintenant ?

Lorsque vous travaillez sur la conception du langage, je pense qu’il est bon d’avoir une telle cible et de la 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 rayures peintes sur la route, mais en visant un moment donné dans la distance. Même si tout ce dont vous vous souciez, c’est de ce qui se passe dans les dix prochains pieds, c’est la bonne réponse. Je pense que nous devrions faire la même chose avec les langages de programmation