La comparaison Common Lisp avec Gambit w.r.t leur accès aux bibliothèques et systèmes objets

Question

Je suis assez intrigué par Gambit Scheme, notamment par sa large gamme de plates-formes prises en charge, et sa capacité à mettre le code C directement dans votre source de régime en cas de besoin. Cela dit, il est un schéma qui a moins de « piles incluses » par rapport à Common Lisp. Certaines personnes aiment coder beaucoup de choses à partir de zéro, (Yak-rasage a.k.a. vigoureuse), mais pas moi!

Cela me amène à mes deux questions, destinées aux personnes qui ont utilisé à la fois Gambit et un peu de saveur de Common Lisp:

1) qui a effectivement un meilleur accès aux bibliothèques? Système a moins de bibliothèques que Common Lisp. Cependant, Gambit Scheme a accès plus lisse au code C / C & bibliothèques, qui sont beaucoup plus nombreuses bibliothèques de Common Lisp. À votre avis, est-ce la douceur des FFI de Gambit l'emportent sur son manque de bibliothèques natives?

2) Comment les systèmes ne objet de Scheme (par exemple TinyCLOS, Meroon) comparer aux CLOS Common Lisp? Si vous les avez trouvés manque, ce dossier (s) avez-vous manqué le plus? Enfin, quelle est l'importance d'un système d'objet dans Lisp / Scheme en premier lieu? Je l'ai entendu parler de l'ensemble des entreprises basé sur Lisp (par exemple ITA Software) Renoncer à tout CLOS. Les objets vraiment facultatif dans Lisp / Scheme? Je crains que si Gambit n'a pas bon système d'objets, je les manquer (mon arrière-plan de programmation est purement orienté objet).

Merci pour aider un converti en herbe de C ++ / Python,

- Matt

PS: Quelqu'un avec plus de 1500 représentant, pourriez-vous s'il vous plaît créer un tag "gambit"? :) Merci Jonas

Answer 1

1) Je ne l'ai pas utilisé Gambit Scheme, donc je ne peux pas vraiment dire comment lisser l'intégration C / C ++ est. Mais tous Lisps communs que j'ai utilisés ont pleinement fonctionnel C IFF: s. Donc, la disponibilité des bibliothèques C est le même. Il faut un certain travail à intégrer, mais je suppose que c'est le cas avec Gambit Scheme ainsi. Après tout, Lisp et C sont des langues différentes ..? Mais peut-être vous avez une expérience différente, je voudrais en savoir plus dans ce cas.

Vous pouvez être intéressé par Quicklisp , un très bon nouveau projet Common Lisp - il est très facile à installer un grand nombre de bibliothèques de qualité.

2) C ++ et Python sont conçus pour utiliser les classes POO et que les moyens typiques de l'encapsulation et la structuration des données. CLOS n'a pas cette ambition du tout. Au lieu de cela, il fournit des fonctions génériques qui peuvent être spécialisés pour certains types d'arguments - pas nécessairement des classes. Essentiellement, cela permet POO, mais en Common Lisp, POO est une caractéristique pratique plutôt que quelque chose de fondamental pour faire avancer les choses.

Je pense que beaucoup CLOS plus bien conçu et souple que le modèle objet C ++ -. TinyCLOS devrait pas être différent dans cet aspect

Answer 2

Bien sûr, le schéma dans son ensemble a moins de bibliothèques dans la norme définie, mais toute mise en œuvre schéma donné construit habituellement sur cette norme pour inclure plus « piles incluses » type de fonctions.

Gambit, par exemple, utilise le système de package de neige qui vous donnera accès à plusieurs bibliothèques de soutien.

D'autres systèmes encore mieux en sortent, avoir accès à des bibliothèques de soutien plus (ou mieux). Les deux Racket (avec PlaNet ) et poulet (avec oeufs ) viennent immédiatement à l'esprit.

Cela dit, le Common Lisp est assez riche et aussi un grand nombre de bibliothèques intéressantes et utiles sont un moyen simple asdf installer loin.

En ce qui concerne les systèmes d'objet Scheme, je tends personnellement à favoriser le schéma de poulet et ont prises pour favoriser coops. Cela dit, il n'y a absolument rien de mal avec de TinyCLOS. Soit servirait bien et ne pas vraiment trouver quelque chose à faire défaut. Bien que cette dernière affirmation pourrait avoir plus à voir avec le fait que je tendance à ne pas compter sur un grand nombre d'objets orientés-ismes lors de l'écriture Scheme. Les deux systèmes dans mon expérience ont tendance à surface quand je veux écrire des « protocoles » et une façon de se spécialiser sur le protocole, si cela est logique.