🥇Paul Graham a annoncé un nouveau langage de programmation Bel

La langue Bel s'écrit en langue Bel.

En 1960, John McCarthy décrit Lisp, un nouveau type de langage de programmation. Je dis « nouveau type » parce que Lisp n’était pas seulement un nouveau langage, mais une nouvelle façon de décrire les langages.

Pour définir Lisp, il a commencé avec un petit ensemble d'énoncés, des sortes d'axiomes, qu'il a ensuite utilisé pour écrire un interprète pour le langage lui-même.

Il n’avait pas pour objectif de décrire un langage de programmation au sens habituel du terme – un langage utilisé pour dire à un ordinateur quoi faire. Dans ses travaux de 1960, Lisp était considéré comme un modèle formel de calcul semblable à la machine de Turing. McCarthy n'a pas pensé à l'utiliser sur des ordinateurs jusqu'à ce que Steve Russell, son étudiant diplômé, le suggère.

Lisp en 1960 n'avait pas les fonctionnalités communes aux langages de programmation. Par exemple, il n'y avait aucun numéro, erreur ou E/S. Ainsi, les personnes qui utilisaient Lisp comme base pour les langages utilisés pour programmer les ordinateurs ont dû ajouter elles-mêmes ces fonctionnalités. Et ils l’ont fait en abandonnant l’approche axiomatique.

Ainsi, le développement de Lisp s'est déroulé en deux étapes - et apparemment tout à fait indépendantes - : une étape formelle, introduite dans un article de 1960, et une étape de mise en œuvre, au cours de laquelle le langage a été adapté et étendu pour fonctionner sur des ordinateurs. L'essentiel du travail, mesuré par le nombre d'opportunités mises en œuvre, a eu lieu au stade de la mise en œuvre. Lisp de 1960, traduit en Common Lisp, ne contient que 53 lignes. Il ne fait que ce qui est nécessaire pour interpréter les expressions. Tout le reste a été ajouté au stade de la mise en œuvre.

Mon hypothèse est que, malgré son histoire difficile, Lisp a bénéficié du fait que son développement s'est déroulé en deux phases ; que l'exercice original consistant à définir un langage en y écrivant son interprète a donné à Lisp ses meilleures qualités. Et si oui, pourquoi ne pas aller plus loin ?

Téléphone est une tentative de répondre à la question : et si, au lieu de passer le plus tôt possible du stade formel au stade de l'exécution, cette transition se faisait le plus tard possible ? Si vous continuez à utiliser l’approche axiomatique jusqu’à ce que vous ayez quelque chose qui se rapproche d’un langage de programmation complet, de quels axiomes aurez-vous besoin et à quoi ressemblera le langage résultant ?

Je veux être clair sur ce qu’est Bel et ce qu’il n’est pas. Bien qu'il ait beaucoup plus de fonctionnalités que le Lisp de McCarthy de 1960, Bel est encore un produit dans sa phase formelle. Comme Lisp, décrit dans un article de 1960, ce n’est pas un langage que vous pouvez utiliser pour programmer. Principalement parce que, comme le Lisp de McCarthy, il ne se soucie pas de l'efficacité. Lorsque j'ajoute quelque chose à Bel, je décris la signification de l'ajout sans chercher à fournir une implémentation efficace.

Pour quoi? Pourquoi prolonger la phase formelle ? Une réponse est de voir où l’approche axiomatique peut nous mener, ce qui est un exercice intéressant en soi. Si les ordinateurs étaient aussi puissants que nous le souhaiterions, à quoi ressembleraient les langues ?

Mais je crois aussi qu'il est possible d'écrire une implémentation efficace basée sur Bel en ajoutant des restrictions. Si vous voulez un langage doté d’une puissance expressive, claire et efficace, cela vaut peut-être la peine de commencer par la puissance expressive et la clarté, puis d’ajouter des restrictions, plutôt que d’aller dans la direction opposée.

Donc, si vous voulez essayer d'écrire une implémentation basée sur Bel, allez-y. Je serai l'un des premiers utilisateurs.

En fin de compte, j'ai reproduit certaines choses des dialectes précédents. Soit leurs concepteurs ont bien compris, soit étant influencés par des dialectes précédemment utilisés, je ne vois pas la bonne réponse - le temps nous le dira. J'ai également essayé de ne pas trop m'éloigner des conventions Lisp. Ce qui signifie que si vous constatez un éloignement des conventions Lisp, il peut y avoir une raison à cela.

Description continue de la langue ici.

Merci pour la traduction : Denis Mitropolsky

PS

Une sélection de 143 traductions des essais de Paul Graham (sur 184)

Source: habr.com