Laquelle de ces anciennes critiques du lisp commun s'applique encore aujourd'hui?

Dans A Critique of Common Lisp écrit par Rodney A. Brooks et Richard P. Gabriel de Stanford en 1984, certaines décisions de conception retenues par le comité de normalisation de Common Lisp sont discutées. Bien que la plupart des discussions restent valables, deux déclarations font référence à la technologie disponible à l'époque et peuvent être fausses aujourd'hui.

Ces deux déclarations sont:

Trop de coûts de la langue ont été rejetés avec l'avertissement que «tout bon compilateur» peut s'en occuper. Personne n'a encore écrit - et ne le fera probablement pas sans un effort énorme - un compilateur qui fait une fraction des tours attendus de lui.

Comme je suis novice en Common Lisp, ou même apprenti, je ne peux pas être plus précis que les auteurs. Ils semblent indiquer qu'une grande généralité et flexibilité ont été intégrées dans plusieurs aspects du langage, ce qui rend la rédaction d'un bon compilateur assez difficile.

Dans COMMON LISP, un peu trop de contrôle était placé sur l'arithmétique à virgule flottante. Et certainement, bien que le comportement correct d'un programme intensif en virgule flottante puisse être atteint, les performances peuvent varier énormément.

D'après ce que je comprends, il semble que l'écriture de code numérique efficace en Common Lisp soit possible mais plus difficile qu'elle ne doit l'être.

C'était il y a trente ans. Comment devrais-je considérer ces affirmations aujourd'hui si je suis disposé à écrire des programmes Common Lisp pour l'une des implémentations courantes de logiciels libres (CLISP, SBCL et al.)?

Le document est intéressant à bien des égards.

La partie la plus intéressante est la suivante: les auteurs ont falsifié l'article de 1984 deux ans plus tard en 1986 eux-mêmes. Brooks et Gabriel ont développé un compilateur Lisp hautement optimisant et l'ont vendu commercialement avec beaucoup de succès pendant plusieurs années: Lucid Common Lisp (PDF).

La maintenance de ce compilateur Lisp est toujours disponible auprès de LispWorks : il s'appelle désormais Liquid Common Lisp .

Les optimisations du compilateur de Liquid CL sont documentées dans le chapitre 3 du Guide de l'utilisateur avancé : Optimisation des programmes Lisp .

Plusieurs applications commerciales ont été écrites et déployées dans Lucid CL. Par exemple, dans ma ville natale, le premier système d'information sur les transports publics pour le HVV (Hamburger Verkehrsverbund) a été déployé à l'aide de Lucid CL sur une station SUN SPARC. Il était accessible au public dans les gares à l'aide d'un grand écran tactile et dans le centre d'appels.

Lucid CL a réussi parce que son compilateur de mode de production a créé des applications Common Lisp rapides, principalement pour les plates-formes Unix / RISC.

Brooks et Gabriel écrivent sur Lucid Common Lisp en 1986:

Le compilateur retargetable dynamiquement s'est avéré être un moyen par lequel la facilité de compilation pour une variété d'implémentations Lisp peut être effectuée; un moyen de porter les systèmes Lisp sur une variété d'ordinateurs; et un outil pour produire du code de haute qualité et hautes performances pour une variété d'ordinateurs à partir d'une source commune.

Ainsi, ils venaient de mettre en œuvre ce que la Critique du Common Lisp prétendait être difficile ou impossible.

De nos jours, les implémentations les plus avancées font beaucoup d'optimisations, mais le matériel est également 1000 fois plus rapide que ce que nous avions en 1984. Un VAX 11/780 avait alors un MIPS (million d'instructions par seconde) et une machine Lisp était également en cette gamme. Un Motorola 68000 avait une fréquence d'horloge de 8 MHz.

Les critiques concernant les performances en virgule flottante et les performances généralement variables sont toujours valables, mais cela reflète le choix des implémenteurs. Certaines implémentations ne sont pas développées en tant que compilateurs hautes performances. Leur objectif principal pourrait être la portabilité, la compacité ou autre chose et ils ont donc des objectifs de mise en œuvre différents.

En tant qu'utilisateur / développeur, on n'est pas obligé d'écrire du code portable et d'utiliser tous les dix + systèmes Common Lisp actuellement pris en charge. Utilisez l'implémentation la mieux adaptée au problème d'application.

Lorsque ce document a été rédigé en 1984, un ordinateur ayant 1 mégaoctet de RAM et un disque dur de 20 mégaoctets, capable de s'asseoir sur votre bureau, était un gros problème. Naturellement, des différends surgiront sur le caractère pratique d'un langage aussi haut que Lisp sur un matériel spartiate. Les progrès de la technologie matérielle et du compilateur qui ont eu lieu depuis lors ont rendu les programmes Lisp beaucoup plus faciles à écrire et à exécuter, indépendamment de toute inefficacité numérique qui pourrait être présente dans le langage.

Les programmeurs échangent souvent l'efficacité informatique contre l'efficacité de la programmation. Lisp peut être un langage lent (dans certaines implémentations, mais d'autres le peuvent aussi), mais il a également une réputation bien méritée pour un développement rapide, et de nombreux programmes ne nécessitent pas une infrastructure hautement optimisée pour afficher des performances adéquates.

Le choix de l'implémentation de Lisp peut grandement affecter le profil de performances de vos programmes. Par exemple, CLISP admet volontiers que "Si votre code est fortement numérique, vous préférerez peut-être CMUCL." Plusieurs implémentations Lisp (et Scheme) modernes vous permettent de spécifier des indications de type numérique, ce qui augmentera les performances numériques.

Bref, la situation est bien meilleure aujourd'hui qu'elle ne l'était alors.