Une bonne partie de la force (et probablement faiblesse) de Lisp réside dans une idée un peu analogue: tout programme Lisp suffisamment compliqué n'est pas écrit en Lisp, mais dans un dialecte de Lisp. L'apparence homogène d'un programme Common Lisp cache trompeusement qu'il s'agit probablement du langage avec le plus de syntaxe (en compétition avec Racket) déjà dans la spécification, et que cette syntaxe est étendue par tout programme utilisant des macros, donc au final il faut un peu apprendre un langage par programme, et je pense que tout ça y est pour quelque chose dans l'enthousiasme inégal qu'il produit (ce n'est pas uniquement la faute aux parenthèses :) ). L'approche génération de code externe, puis après on regarde le code est moins élégante et expressive, mais l'avantage c'est que le résultat est dans le même langage (donc analysable immédiatement par n'importe qui et par des outils aussi), et plus simple d'un point de vue compilation.
[^] # Re: C'est bien dommage
Posté par anaseto . En réponse au journal C++17 est sur les rails. Évalué à 7.
Une bonne partie de la force (et probablement faiblesse) de Lisp réside dans une idée un peu analogue: tout programme Lisp suffisamment compliqué n'est pas écrit en Lisp, mais dans un dialecte de Lisp. L'apparence homogène d'un programme Common Lisp cache trompeusement qu'il s'agit probablement du langage avec le plus de syntaxe (en compétition avec Racket) déjà dans la spécification, et que cette syntaxe est étendue par tout programme utilisant des macros, donc au final il faut un peu apprendre un langage par programme, et je pense que tout ça y est pour quelque chose dans l'enthousiasme inégal qu'il produit (ce n'est pas uniquement la faute aux parenthèses :) ). L'approche génération de code externe, puis après on regarde le code est moins élégante et expressive, mais l'avantage c'est que le résultat est dans le même langage (donc analysable immédiatement par n'importe qui et par des outils aussi), et plus simple d'un point de vue compilation.