Quelles sont les différences réelles entre Scheme et Common Lisp? (Ou tout autre dialecte de LISP)
Remarque: je ne demande pas ce qu'il faut apprendre, ce qui est mieux, ou quelque chose comme ça.
J'ai choisi la version gratuite de SICP parce que je pensais que ce serait agréable à lire (j'ai entendu de bonnes choses à ce sujet et je suis intéressé par ce genre de programmation).
Je sais que Scheme est un dialecte de LISP et je me suis demandé: quelle est la différence réelle entre Scheme et, disons, Common Lisp?
Il semble y avoir beaucoup de choses sur "CL a un stdlib plus grand ... Le schéma n'est pas bon pour la programmation dans le monde réel .." mais rien de réel ne dit "c'est parce que CL est ceci/a ceci".
C'est une question un peu délicate, car les différences sont à la fois techniques et (surtout, à mon avis) culturelles. Une réponse ne peut que fournir une vue subjective imprécise. C'est ce que je vais fournir ici. Pour quelques détails techniques bruts, voir Scheme Wiki .
Scheme est un langage construit sur le principe de fournir un substrat de langue de base élégant, cohérent et bien pensé qui peut être construit à la fois des langues d'application pratiques et académiques sur.
Vous trouverez rarement quelqu'un qui écrit une application dans un schéma R5RS (ou R6RS) pur, et en raison de la norme minimaliste, la plupart du code n'est pas portable dans les implémentations Scheme. Cela signifie que vous devrez choisir soigneusement votre implémentation Scheme, si vous souhaitez écrire une sorte d'application utilisateur final, car le choix déterminera en grande partie quelles bibliothèques sont disponibles pour vous. D'un autre côté, la relative liberté de conception du langage d'application réel signifie que les implémentations de Scheme fournissent souvent des fonctionnalités inconnues ailleurs; PLT Racket, par exemple, vous permet d'utiliser le typage statique et fournit un IDE très sensible aux langues.
L'interopérabilité au-delà du langage de base est assurée par le biais du processus SRFI piloté par la communauté, mais la disponibilité d'un SRFI donné varie selon la mise en œuvre.
La plupart des dialectes et bibliothèques Scheme se concentrent sur des idiomes de programmation fonctionnels comme la récursivité au lieu de l'itération. Il existe différents systèmes d'objets que vous pouvez charger en tant que bibliothèques lorsque vous voulez faire de la POO, mais l'intégration avec le code existant dépend fortement du dialecte Scheme et de sa culture environnante (Chicken Scheme semble être plus orienté objet que Racket, par exemple).
La programmation interactive est un autre point dans lequel les sous-communautés de Scheme diffèrent. MIT Scheme est connu pour un support interactif puissant, tandis que PLT Racket semble beaucoup plus statique. En tout cas, la programmation interactive ne semble pas être un élément central concerne la plupart des sous-communautés de Scheme, et je n'ai pas encore vu un environnement de programmation aussi interactif que la plupart des Common Lisps.
LISP commun est un langage usé conçu pour la programmation pratique. Il est plein de vilaines verrues et de hacks de compatibilité - tout à fait le contraire du minimalisme élégant de Scheme. Mais il est également beaucoup plus caractéristique lorsqu'il est pris pour lui-même.
LISP commun a engendré un écosystème relativement important de bibliothèques portables. Vous pouvez généralement changer d'implémentation à tout moment, même après le déploiement de l'application, sans trop de problèmes. Dans l'ensemble, Common LISP est beaucoup plus uniforme que Scheme, et des expériences linguistiques plus radicales, si elles sont effectuées, sont généralement intégrées sous forme de bibliothèque portable plutôt que de définir un tout nouveau dialecte linguistique. Pour cette raison, les extensions de langage ont tendance à être plus conservatrices, mais aussi plus combinables (et souvent facultatives).
Les extensions de langage universellement utiles comme les interfaces de fonction étrangère ne sont pas développées par des moyens formels mais reposent sur des bibliothèques quasi standard disponibles sur toutes les principales implémentations LISP communes.
Les idiomes du langage sont un mélange sauvage d'approches fonctionnelles, impératives et orientées objet, et en général, le LISP commun ressemble plus à un langage impératif qu'à un langage fonctionnel. Il est également extrêmement dynamique, sans doute plus que tout autre langage de script dynamique populaire (la redéfinition de classe s'applique aux instances existantes, par exemple, et le système de gestion des conditions a une interactivité intégrée), et la programmation exploratoire interactive est une partie importante de "la voie LISP commune." Cela se reflète également dans les environnements de programmation disponibles pour Common LISP, qui offrent pratiquement tous une sorte d'interaction directe avec le compilateur LISP en cours d'exécution.
LISP commun comprend un système d'objets intégré (CLOS), un système de gestion des conditions nettement plus puissant que la simple gestion des exceptions, la patchabilité au moment de l'exécution et divers types de structures de données et utilitaires intégrés (y compris le notoire LOOP macro, un sous-langage d'itération beaucoup trop laid pour Scheme mais beaucoup trop utile pour ne pas le mentionner, ainsi qu'un mécanisme de formatage de type printf avec GOTO support dans les chaînes de format).
À la fois en raison du développement interactif basé sur l'image et du langage plus large, les implémentations LISP sont généralement moins portables sur les systèmes d'exploitation que les implémentations Scheme. Par exemple, faire fonctionner un LISP commun sur un appareil embarqué n'est pas pour les âmes sensibles. De la même manière que la machine virtuelle Java Virtual Machine, vous avez également tendance à rencontrer des problèmes sur les machines où la mémoire virtuelle est limitée (comme les serveurs virtuels basés sur OpenVZ). Les implémentations de schémas, en revanche, ont tendance à être plus compact et portable.La qualité croissante de la mise en œuvre de l'ECL a quelque peu atténué ce point, bien que son essence soit toujours vraie.
Si vous vous souciez du support commercial, il y a quelques sociétés qui fournissent leurs propres implémentations LISP communes, y compris les constructeurs graphiques GUI, les systèmes de base de données spécialisés, et cetera.
En résumé , Scheme est un langage plus élégant. Il s'agit principalement d'un langage fonctionnel avec quelques fonctionnalités dynamiques. Ses implémentations représentent divers dialectes incompatibles avec des caractéristiques distinctives. Common LISP est un langage multi-paradigme à part entière, très dynamique et doté de diverses caractéristiques laides mais pragmatiques, dont les implémentations sont largement compatibles les unes avec les autres. Les dialectes de schéma ont tendance à être plus statiques et moins interactifs que le LISP commun; Les implémentations LISP courantes ont tendance à être plus lourdes et plus difficiles à installer.
Quelle que soit la langue que vous choisissez, je vous souhaite beaucoup de plaisir! :)
Quelques différences pratiques de base:
- LISP commun a des étendues distinctes pour les variables et les fonctions; alors que dans Scheme il n'y a qu'une seule portée - les fonctions sont des valeurs et la définition d'une fonction avec un certain nom ne fait que définir une variable définie sur le lambda. Par conséquent, dans Scheme, vous pouvez utiliser un nom de fonction en tant que variable et le stocker ou le passer à d'autres fonctions, puis effectuer un appel avec cette variable comme s'il s'agissait d'une fonction. Mais dans Common LISP, vous devez convertir explicitement une fonction en valeur en utilisant
(function ...), et appeler explicitement une fonction stockée dans une valeur à l'aide de(funcall ...) - Dans Common LISP,
nil(la liste vide) est considérée comme fausse (par exemple dansif) et est la seule valeur fausse. Dans Scheme, la liste vide est considérée comme vraie, et (le distinct)#fest la seule fausse valeur
C'est une question difficile à répondre de manière impartiale, en particulier parce que beaucoup de gens LISP classeraient Scheme comme LISP.
Josh Bloch (et cette analogie n'est peut-être pas son invention) décrit le choix d'une langue comme s'apparentant au choix d'un pub local. Dans cette optique, alors:
Le pub "Scheme" compte de nombreux chercheurs en langages de programmation. Ces personnes accordent beaucoup d'attention à la signification de la langue, à la garder bien définie et simple, et à discuter de nouvelles fonctionnalités innovantes. Chacun a sa propre version du langage, conçue pour lui permettre d'explorer son propre coin de langage de programmation. Les gens de Scheme aiment vraiment la syntaxe entre parenthèses qu'ils ont prise de LISP; il est flexible et léger et uniforme et supprime beaucoup les obstacles à l'extension de la langue.
Le pub "LISP"? Eh bien ... je ne devrais pas commenter; Je n'y ai pas passé assez de temps :).
schème:
- à l'origine très peu de spécifications (le nouveau R7RS semble être plus lourd)
- en raison de la syntaxe facile, le schéma peut être appris rapidement
- les implémentations fournissent des fonctions supplémentaires, mais les noms peuvent différer selon les implémentations
lISP commun:
- de nombreuses fonctions sont définies par la plus grande spécification
- espace de noms différent pour les fonctions et les variables (LISP-2)
ce sont quelques points, bien sûr il y en a beaucoup d'autres, dont je ne me souviens pas en ce moment.