Attention, "dialecte de Lisp" désigne en général un langage de la famille Lisp (Common Lisp, souvent appelé Lisp, Scheme (dont Racket est une des implémentations/variantes), Emacs Lisp, Clojure, ...).
C'est vrai pour la création de langages basés sur Lisp, mais si tu utilises une bibliothèque de fonctions dans n'importe quel langage il faut apprendre les fonctions et le traitement qu'elles réalisent. En Lisp il y a en plus des macros et de la même manière il faut apprendre ce qu'elles font. Il s'agit juste de poser des couches d'abstraction par-dessus le langage de base.
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. Donc de programmer dans un langage plus spécifique au domaine et en écrivant moins de choses. Et en relisant du code plus clair quand on doit relire/modifier le programme, avec moins de détails à apprendre. Avec les avantages classiques associés aux fonctions par exemple : écrire une macro c'est capturer une syntaxe, une forme qui revient dans le programme, et avoir du code généré (de manière transparente, sans le voir étalé partout) toujours de la même manière plutôt que du code de bas niveau qui se ressemble à différents endroits. Donc moins pratique pour quelqu'un qui arrive et qui veut faire une petite modification parce qu'il y a plus de choses à apprendre avant de commencer mais plus pratique pour faire des modifications à plus long terme. Et encore, si la modification est d'assez haut niveau il faut juste comprendre le langage construit sur la syntaxe de base et on peut se dispenser d'en connaître tous les détails : faire des modifications de haut niveau, même mineures, sur le code est plus commode.
Évidemment écrire des macros qui servent deux fois dans un programme et truffer un petit programme de macros et spécificités diverses n'est pas une bonne idée. Mais si le programme est important capturer certaines formes qui n'entrent pas dans des fonctions et écrire le programme à l'aide de concepts de plus haut niveau est un gains de temps important, y compris pour le relire et comprendre ce qu'il fait ou même faire des modifications de haut niveau.
On note que dans divers langages on voit passer l'expression "langage spécifique au domaine" (ou "domain specific language" / "DSL" parfois) mais en général on a soit une syntaxe moche soit un langage externe comme un truc à base de XML.
Et pour les macros on peut afficher le code qu'elles génèrent, si on veut voir les détails :) .
[^] # Re: C'est bien dommage
Posté par ylsul . En réponse au journal C++17 est sur les rails. Évalué à 2.
Attention, "dialecte de Lisp" désigne en général un langage de la famille Lisp (Common Lisp, souvent appelé Lisp, Scheme (dont Racket est une des implémentations/variantes), Emacs Lisp, Clojure, ...).
C'est vrai pour la création de langages basés sur Lisp, mais si tu utilises une bibliothèque de fonctions dans n'importe quel langage il faut apprendre les fonctions et le traitement qu'elles réalisent. En Lisp il y a en plus des macros et de la même manière il faut apprendre ce qu'elles font. Il s'agit juste de poser des couches d'abstraction par-dessus le langage de base.
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. Donc de programmer dans un langage plus spécifique au domaine et en écrivant moins de choses. Et en relisant du code plus clair quand on doit relire/modifier le programme, avec moins de détails à apprendre. Avec les avantages classiques associés aux fonctions par exemple : écrire une macro c'est capturer une syntaxe, une forme qui revient dans le programme, et avoir du code généré (de manière transparente, sans le voir étalé partout) toujours de la même manière plutôt que du code de bas niveau qui se ressemble à différents endroits. Donc moins pratique pour quelqu'un qui arrive et qui veut faire une petite modification parce qu'il y a plus de choses à apprendre avant de commencer mais plus pratique pour faire des modifications à plus long terme. Et encore, si la modification est d'assez haut niveau il faut juste comprendre le langage construit sur la syntaxe de base et on peut se dispenser d'en connaître tous les détails : faire des modifications de haut niveau, même mineures, sur le code est plus commode.
Évidemment écrire des macros qui servent deux fois dans un programme et truffer un petit programme de macros et spécificités diverses n'est pas une bonne idée. Mais si le programme est important capturer certaines formes qui n'entrent pas dans des fonctions et écrire le programme à l'aide de concepts de plus haut niveau est un gains de temps important, y compris pour le relire et comprendre ce qu'il fait ou même faire des modifications de haut niveau.
On note que dans divers langages on voit passer l'expression "langage spécifique au domaine" (ou "domain specific language" / "DSL" parfois) mais en général on a soit une syntaxe moche soit un langage externe comme un truc à base de XML.
Et pour les macros on peut afficher le code qu'elles génèrent, si on veut voir les détails :) .