La métaprogrammation fait référence aux différentes façons dont un programme a connaissance de lui-même ou peut se manipuler.
Dans des langages comme le C#, la réflexion est une forme de métaprogrammation puisque le programme peut examiner des informations sur lui-même. Par exemple, il peut retourner une liste de toutes les propriétés d'un objet.
Dans des langages comme ActionScript, vous pouvez évaluer des fonctions au moment de l'exécution pour créer de nouveaux programmes tels que eval("x" + i). DoSomething() affecterait un objet appelé x1 lorsque i est égal à 1 et x2 lorsque i est égal à 2.
Enfin, une autre forme courante de métaprogrammation est celle où le programme peut se modifier lui-même de manière non triviale. LISP est bien connu pour cela et c'est une chose dont Paul Graham s'est fait le champion il y a une dizaine d'années. Il faudra que je recherche certains de ses essais spécifiques. Mais l'idée est que le programme modifie une autre partie du programme en fonction de son état. Cela permet un niveau de flexibilité pour prendre des décisions au moment de l'exécution, ce qui est très difficile dans la plupart des langages populaires aujourd'hui.
Il convient également de noter qu'à l'époque de la programmation en langage assembleur, les programmes qui se modifiaient au moment de l'exécution étaient nécessaires et très courants.
Extrait de l'essai de Paul Graham "Ce qui a fait la différence de Lisp :
De nombreuses langues ont macro. Mais les macros Lisp sont uniques. Et je croyez-le ou non, ce qu'elles font est lié aux parenthèses. Le concepteurs de Lisp n'ont pas mis toutes ces parenthèses dans le langage juste pour être pour être différents. Pour le programmeur Blub, le code Lisp a l'air bizarre. Mais ces parenthèses sont là pour une raison. Elles sont la preuve extérieure d'une différence fondamentale entre Lisp et les autres langages.
Le code Lisp est constitué de données Lisp Lisp. Et pas dans le sens trivial que les fichiers sources contiennent des et que les chaînes de caractères sont l'un des types de données pris en charge par le langage. Le code Lisp, après avoir été lu par l'analyseur syntaxique, est constitué de structures de données. par l'analyseur, est constitué de structures de données que vous pouvez parcourir.
Si vous comprenez comment ce qui se passe en réalité n'est pas tellement que Lisp a une syntaxe étrange, mais plutôt que Lisp n'a pas de syntaxe. Vous écrivez des programmes dans les arbres d'analyse générés dans le compilateur lorsque d'autres d'autres langages sont analysés. Mais ces arbres sont entièrement accessibles à votre programmes. Vous pouvez écrire des programmes qui les manipuler. En Lisp, ces programmes sont appelés macros. Ils sont des des programmes qui écrivent des programmes.
Des programmes qui écrivent des programmes ? Quand voudriez-vous faire cela ? Pas de très souvent, si vous pensez en Cobol. Tous les tout le temps, si vous pensez en Lisp. Il serait serait pratique ici si je pouvais donner un exemple de macro puissante, et dire : "Voilà, qu'en pensez-vous ? Mais si je le faisais, cela ressemblerait à du charabia pour quelqu'un qui ne connaîtrait pas le langage Lisp ; il n'y a pas assez de place ici pour expliquer tout ce qu'il faut savoir pour comprendre comprendre ce que cela signifie. En A Common Lisp J'ai essayé de faire bouger les choses aussi vite que possible, et même ainsi je n'ai pas abordé les macros avant la page 160.
Mais je pense que je peux donner un coup de pouce. argument qui pourrait être convaincant. Le code source de l'éditeur Viaweb était était probablement composé de 20 à 25 % de macros. Les macros sont plus difficiles à écrire que les fonctions Lisp ordinaires, et les [ ] nécessaires. Ainsi, chaque macro de ce code est là parce qu'elle doit l'être. Ce qui signifie qu'au moins 20-25% du code du code de ce programme fait des choses des choses que l'on ne peut pas faire facilement dans autre langage. Aussi sceptique que soit le programmeur de programmeur Blub soit sceptique quant à mes mes affirmations sur les pouvoirs mystérieux de Lisp, cela devrait le rendre curieux. Nous n'avons pas écrit ce code pour notre pour nous amuser. Nous étions une minuscule start-up, programmant aussi fort que nous le pouvions afin de mettre des barrières techniques entre nous et nos concurrents.
Une personne suspecte se demander s'il n'y a pas une corrélation ici. Une grande partie de notre code était faisait des choses qui sont très difficiles à faire dans d'autres langages. Le logiciel qui en résulte logiciel résultant faisait des choses que les concurrents ne pouvaient pas faire. Il y avait peut-être qu'il y avait une sorte de lien. Je vous encourage à suivre ce fil. Il y a peut-être plus à ce vieil homme qui clopine sur ses béquilles.
