Et c'est vrai qu'il vaut mieux faire attention à ne pas écrire des macros pour tout et n'importe quoi, mais la contrepartie est qu'il est possible d'atteindre des niveaux d'abstraction plus élevées que dans d'autres langages.
Oui, la théorie est simple.
La plupart des langages généralistes essaient d'identifier les éléments de syntaxe qui leur semblent les plus importants pour leurs objectifs. Ils favorisent certaines constructions, rendent plus faciles certains motifs et un peu plus verbeux d'autres. Certains langages sont plus ou moins conservateurs avec l'ajout de nouvelles syntaxes qui seront utilisées peu souvent, mais l'idée reste quand même d'identifier l'important, encourager des idioms et définir une syntaxe qui sera concise pour la plupart des usages de prédilection du langage, tout en essayant d'étudier les usages moins fréquents pour s'assurer que ça ne devient pas trop verbeux non plus, même si pas totalement naturel ou optimal.
Lisp de son côté, partant du principe qu'il est impossible de savoir à l'avance ce qui sera vraiment important pour tous les utilisateurs, plutôt que de prendre parti et décider si telle ou telle syntaxe sera plus demandée qu'une autre, met tout sur un même niveau, et propose un potentiel d'adaptabilité impressionnant. Le prix (d'un point de vue langage, mettant de côté les conséquences sur la complexité du compilo), c'est que tout se ressemble, le simple et le compliqué sont difficiles à distinguer, la syntaxe n'encourage pas certaines approches par rapport à d'autres, et les idioms ont tendance à être moins prévisibles.
Il y a sûrement des programmes où ce degré d'adaptabilité fait vraiment la différence, où il n'est pas possible de prévoir un langage généraliste suffisamment adapté à l'avance, sinon des livres comme le « On Lisp » de Graham n'existerait pas, je suppose, mais je ne suis pas convaincu que le gain soit déterminant aussi souvent que le laissent penser les introductions philosophiques à ce langage.
Et pour les macros on peut afficher le code qu'elles génèrent, si on veut voir les détails :) .
Bien sûr, avec un bon éditeur de texte (je dirais emacs en général pour du Lisp), il y a moyen, avec de l'entraînement, de démêler la syntaxe, mais c'est quand même une étape de plus par rapport à une syntaxe qui se voit et fait partie du langage de base: il faut vraiment une factorisation significative pour que ce soit rentable (et qu'il n'existe pas d'alternative sans macros qui factorise presque autant, quitte à être moins élégante, ce qui néanmoins l'avantage de signaler qu'effectivement c'est un point délicat du programme). Et analyser du Lisp avec un outil externe statiquement semble peu évident.
[^] # Re: C'est bien dommage
Posté par anaseto . En réponse au journal C++17 est sur les rails. Évalué à 3.
Oui, la théorie est simple.
La plupart des langages généralistes essaient d'identifier les éléments de syntaxe qui leur semblent les plus importants pour leurs objectifs. Ils favorisent certaines constructions, rendent plus faciles certains motifs et un peu plus verbeux d'autres. Certains langages sont plus ou moins conservateurs avec l'ajout de nouvelles syntaxes qui seront utilisées peu souvent, mais l'idée reste quand même d'identifier l'important, encourager des idioms et définir une syntaxe qui sera concise pour la plupart des usages de prédilection du langage, tout en essayant d'étudier les usages moins fréquents pour s'assurer que ça ne devient pas trop verbeux non plus, même si pas totalement naturel ou optimal.
Lisp de son côté, partant du principe qu'il est impossible de savoir à l'avance ce qui sera vraiment important pour tous les utilisateurs, plutôt que de prendre parti et décider si telle ou telle syntaxe sera plus demandée qu'une autre, met tout sur un même niveau, et propose un potentiel d'adaptabilité impressionnant. Le prix (d'un point de vue langage, mettant de côté les conséquences sur la complexité du compilo), c'est que tout se ressemble, le simple et le compliqué sont difficiles à distinguer, la syntaxe n'encourage pas certaines approches par rapport à d'autres, et les idioms ont tendance à être moins prévisibles.
Il y a sûrement des programmes où ce degré d'adaptabilité fait vraiment la différence, où il n'est pas possible de prévoir un langage généraliste suffisamment adapté à l'avance, sinon des livres comme le « On Lisp » de Graham n'existerait pas, je suppose, mais je ne suis pas convaincu que le gain soit déterminant aussi souvent que le laissent penser les introductions philosophiques à ce langage.
Bien sûr, avec un bon éditeur de texte (je dirais emacs en général pour du Lisp), il y a moyen, avec de l'entraînement, de démêler la syntaxe, mais c'est quand même une étape de plus par rapport à une syntaxe qui se voit et fait partie du langage de base: il faut vraiment une factorisation significative pour que ce soit rentable (et qu'il n'existe pas d'alternative sans macros qui factorise presque autant, quitte à être moins élégante, ce qui néanmoins l'avantage de signaler qu'effectivement c'est un point délicat du programme). Et analyser du Lisp avec un outil externe statiquement semble peu évident.