Pourquoi est-il si important d'étudier un interprète LISP dans LISP?
J'ai vu de nombreux curriculums CS et des suggestions d'apprentissage pour de nouveaux programmeurs qui appellent le programmeur en herbe à étudier un interprète LISP spécifiquement écrit en LISP. Tous ces sites disent des choses similaires à "c'est une révélation intellectuelle", "c'est une expérience des Lumières que tout programmeur sérieux devrait avoir" ou "il vous montre des relations matériel/logiciel" et d'autres déclarations vagues, en particulier de cet article tiré de ce mode d'emploi réputé .
Le sentiment général de ma question est, comment LISP atteint-il les objectifs ci-dessus et pourquoi lisp? Pourquoi pas une autre langue?
Je pose cette question parce que je viens de terminer l'écriture d'un interpréteur de schéma dans le schéma (tiré de SICP http://mitpress.mit.edu/sicp/ ) et maintenant j'écris un python interprète dans le schéma et j'ai du mal à avoir cette épiphanie légendaire qui est censée provenir spécifiquement du premier. Je cherche des détails techniques spécifiques entre les deux langues que je peux exploiter dans leurs interprètes de schéma pour comprendre comment les programmes fonctionnent.
Plus précisement:
Pourquoi l'étude d'un interprète qui est écrit dans la langue qu'il interprète est-elle si soulignée - est-ce simplement un excellent exercice mental pour garder la langue originale et la langue construite droite ou y a-t-il des problèmes spécifiques dont les solutions ne peuvent être trouvées que dans la nature du langue originale?
Comment les interprètes LISP démontrent-ils de bons concepts d'architecture pour la future conception de logiciels?
Que manquerais-je si je faisais cet exercice dans un langage différent comme C++ ou Java?
Quel est le plus utilisé plats à emporter ou "outil mental" de cet exercice? **
** J'ai choisi la réponse que j'ai faite parce que j'ai remarqué que j'ai gagné de cet exercice plus de compétences dans la conception d'outils d'analyse dans ma tête que n'importe quel autre single et je voudrais trouver différentes méthodes d'analyse qui peuvent mieux fonctionner pour l'interpréteur de schéma que l'interpréteur python.
Au risque de donner une réponse "moi aussi", si vous l'essayez, vous verrez ...
Si vous étudiez les langages informatiques, vous aurez probablement l'impression qu'il s'agit au moins de la moitié de l'analyse. Si vous apprenez LISP, vous vous rendrez compte que l'analyse de la syntaxe de surface n'est rien de plus qu'une commodité pour les personnes (comme la plupart d'entre nous) qui n'aiment pas beaucoup de parenthèses simples irritantes.
Vous pourriez alors réaliser qu'un gros prix a été payé pour cette commodité. Dans LISP, il est trivial pour un programme de construire un autre programme et de l'exécuter. Dans d'autres langues, c'est une technique avancée, comme faire la multiplication en chiffres romains.
Bien sûr, presque tout le monde demanderait "qui doit faire ça?" Eh bien, vous pouvez très bien voir que cela ouvre toute une Vista de choses que vous n'aviez jamais réalisé que vous ne pouviez pas faire auparavant. Vous pouvez le faire dans d'autres langues, mais pas si facilement.
INSÉRÉ pour répondre au commentaire d'Izkata:
- Le programme de compréhension du langage naturel SHRDLU a fonctionné en traduisant une déclaration ou une question en anglais dans un programme dans un dialecte LISP appelé MICRO-PLANNER et en l'exécutant.
- Les programmes qui manipulent des programmes, par exemple pour les simplifier ou les prouver sont naturellement écrits en LISP.
- J'ai utilisé la génération de programme dans un programme pour comprendre des scènes visuelles, où il devait gérer toutes les symétries capables dans les objets tridimensionnels, sans multiplier le code.
- Tout ce qui a à voir avec la logique et la démonstration des théorèmes concerne la manipulation des expressions logiques, qui sont une forme de programme.
- Les mathématiques symboliques, telles que le calcul symbolique intégral ou différentiel, impliquent la manipulation d'expressions mathématiques, qui sont comme des programmes miniatures.
- Tout problème impliquant la génération de code, ou le terme plus élevé "évaluation partielle", est naturel dans LISP. J'ai fait cela pour un programme de pont de base de données il y a longtemps. Je l'ai fait en C, ce qui n'était pas aussi simple que LISP, mais j'ai eu l'idée de LISP. Cela était considéré comme une technique que presque personne ne pouvait faire à l'époque (en particulier les têtes COBOL). Peut-être plus maintenant, j'espère.
... c'est juste quelques-uns ...
Ensuite, vous réalisez que certaines choses qui sont considérées comme "modernes" aujourd'hui sont anciennes dans LISP depuis 40 ans. Comme la programmation fonctionnelle. Comme la collecte des ordures. Comme des fermetures.
Cela ne veut pas dire que les langues modernes n'ont pas de nouvelles bonnes idées, comme la POO, etc. Mais si vous apprenez le LISP, cela élargira votre perspective.
La réponse simple à votre question est d'essayer LISP, de préférence en conjonction avec SICP . Ensuite, vous serez éclairé.
Cela dit...
Le code est une donnée
La plupart des langues font une distinction nette entre le code et les données; LISP ne le fait pas. Cela permet, par exemple, d'écrire trivialement un analyseur LISP dans LISP, et de manipuler le code LISP dans LISP. La meilleure description de ces Lumières que j'ai trouvée est The Nature of LISP .
Cela est vrai en partie parce que la syntaxe de la langue est si simple. Cela rend possible des choses dans LISP (comme la métaprogrammation) qui ne sont pas pratiques dans d'autres langues parce que la syntaxe fait obstacle.
Lectures complémentaires
Battre les moyennes
Pourquoi l'étude d'un interprète écrit dans la langue qu'il interprète est-elle si importante?
En général, étudier un interprète vous donne un aperçu de sa langue et de ses fonctionnalités. En général, étudier le code dans un langage de programmation, c'est comme pratiquer un langage parlé en écoutant et en lisant: il vous familiarise avec ce que ce langage peut faire, comment il est utilisé et les "idiomes" courants. Plus précisément, LISP est un langage homoiconique, ce qui signifie sa syntaxe pour les expressions est la même que sa syntaxe pour les données. L'écriture de code dans LISP ressemble terriblement à l'écriture d'une liste, et vice versa. Ainsi, interpréter le code LISP avec du code LISP est aussi simple que de parcourir des listes avec car et cdr.
Comment dois-je capitaliser sur cet exercice pour en tirer le meilleur parti conceptuellement?
Pensez à la façon dont l'interprète s'interpréterait - dans de nombreuses interprétations méta-circulaires (où un langage homoiconique s'interprète) peut simplement "traverser" la fonction . Par exemple, pour implémenter car, prenez simplement le car de l'argument. Cela met l'accent sur les mécanismes de stockage de données et se concentre sur la fonctionnalité.
Comment les interprètes LISP démontrent-ils de bons concepts d'architecture pour la future conception de logiciels?
Les interprètes peuvent être très compliqués, ce qui encourage une bonne architecture dans leur conception. Dans cet esprit, celui-ci dépend davantage de l'interprète individuel.
Que manquerais-je si je faisais cet exercice dans un langage différent comme C++ ou Java?
Ces langages ne sont pas homoiconiques, ils ne bénéficient donc pas de la grâce et de la simplicité d'un interprète méta-circulaire LISP. Cela rend l'exercice plus difficile et peut-être moins courant, mais je ne dirais pas qu'il est vraiment moins bénéfique.
Quel est le plat à emporter ou "outil mental" le plus utilisé dans cet exercice?
Je ne suis pas sûr d'avoir une bonne réponse pour celui-ci; simplement que cela aide à voir comment l'interprète fonctionne et, peut-être plus important encore, à le bricoler pour voir comment des modifications mineures de la langue peuvent être facilement mises en œuvre.
LISP est lui-même structuré d'une manière qui le rend extrêmement facile à analyser. Si vous essayez d'écrire un compilateur, vous remarquerez que c'est beaucoup plus facile si tout dans votre langue est une expression et a un faible niveau d'ambiguïté. LISP force les parenthèses partout pour éliminer l'ambiguïté et n'a pas d'instructions, seulement des expressions.
Le fait même que LISP soit très facile à analyser encourage les utilisateurs à analyser leur propre code source et à faire des tours de magie avec. La ligne entre les données et le code devient floue et vous pouvez facilement faire des choses qui nécessitent normalement un certain effort, comme la réflexion, la réécriture de code dynamique, les plugins et la sérialisation.
C'est l'essentiel. L'exercice est probablement destiné à vous donner un aperçu de ce qui est possible lorsque le code est facilement analysable par lui-même.
Je ne suis pas sûr que ce soit vraiment important pour tout le monde. Vous pouvez être un développeur performant sans savoir comment fonctionne un interpréteur LISP. Lorsque vous étudiez l'informatique, les idées de base du LISP doivent cependant être apprises.
Les interprètes LISP sont importants pour les programmeurs LISP. Ils doivent comprendre comment fonctionne un interprète ([et un compilateur]1 ), pour bien comprendre comment utiliser le langage.
Un interprète LISP est souvent utilisé comme un outil en informatique pour enseigner aux étudiants quelques choses:
comprendre une définition de langage compacte et minimale grâce à une implémentation: Alan Kay l'a appelée Maxwell’s Equations of Software .
compréhension programmation au niveau de la langue , en changeant et en étendant l'interpréteur
compréhension programmation au niveau méta et les effets qu'elle a sur la conception et l'utilisation d'un langage de programmation. Par exemple, comprendre ce que signifie "citer" et pourquoi il est nécessaire
comprendre l'interprétation du langage de programmation LISP et sa connexion au Lambda Calculus
En tant que dispositif d'enseignement, un interprète LISP est utile, car il peut être appris et compris en peu de temps. Étant donné que peu d'étudiants connaissent déjà LISP, les étudiants sont sur un terrain de niveau lorsqu'il s'agit d'apprendre les concepts ci-dessus.