Porównywanie Common Lisp z Gambit w.r.t ich dostępu do bibliotek i systemów obiektowych

Question

Jestem bardzo zaintrygowany Gambit Scheme, w szczególności dzięki jego szerokiej gamie obsługiwanych platform, i jego zdolności do umieszczenia kodu C bezpośrednio w twoim źródle Scheme kiedy jest to potrzebne. To powiedziawszy, jest to Schemat, który zawiera mniej "baterii w zestawie" w porównaniu do Common Lisp. Niektórzy ludzie lubią kodować wiele rzeczy od zera, (a.k.a. energiczne yak-shaving), ale nie ja!

To prowadzi mnie do dwóch pytań, skierowane do ludzi, którzy korzystali zarówno Gambit i trochę smak Common Lisp:

1) co skutecznie ma lepszy dostęp do biblioteki? Schemat ma mniej bibliotek niż Common Lisp. Jednak Gambit Scheme ma bardziej płynny dostęp do bibliotek kodu C/C++ &, które znacznie przewyższają biblioteki Common Lisp. Czy według ciebie płynność FFI Gambita przeważa nad brakiem bibliotek natywnych?

2) W jaki sposób systemy obiektowe Scheme (np. TinyCLOS, Meroon) są porównywane do CLOS Common Lisp? Jeśli zauważyłeś, że ich brakuje, jakiej funkcji najbardziej Ci brakowało? Na koniec, jak ważny jest system obiektowy w Lisp/Scheme w pierwszej kolejności? Słyszałem o całych firmach opartych na seplenieniach (np. ITA Software) całkowicie rezygnujących z CLOS. Czy obiekty naprawdę są opcjonalne w Lisp/Scheme? Obawiam się, że jeśli Gambit nie ma dobrego systemu obiektowego, mogę go nie zauważyć (moje tło programistyczne jest zorientowane wyłącznie na obiekt).

Dzięki za pomoc początkujący przekonwertować z C++/Python,

- Matt

PS: Ktoś z ponad 1500 rep, mógłbyś stworzyć "Gambit" tag? :) Dzięki Jonas!

Answer 1

1) Nie korzystałem z Gambit Scheme, więc nie mogę powiedzieć, jak gładka jest integracja C/C++. Ale wszystkie używane przeze mnie Lispki mają w pełni funkcjonalny C FFI: s. Zatem dostępność bibliotek C jest taka sama. Integracja wymaga trochę pracy, ale zakładam, że tak jest w przypadku Gambit Scheme. W końcu Lisp i C są różnymi językami ..? Ale może masz inne doświadczenie, chciałbym dowiedzieć się więcej w tej sprawie.

Być może zainteresuje Cię Quicklisp, naprawdę dobry nowy projekt Common Lisp - dzięki temu bardzo łatwo będzie zainstalować wiele bibliotek wysokiej jakości.

2) C++ i Python są zaprojektowane do używania OOP i klas jako typowego sposobu enkapsulacji i strukturyzacji danych. CLOS w ogóle nie ma takich ambicji. Zamiast tego zapewnia ogólne funkcje, które mogą być wyspecjalizowane dla pewnych typów argumentów - niekoniecznie klas. Zasadniczo to umożliwia OOP, ale w Common Lisp, OOP jest wygodną funkcją, a nie czymś podstawowym do załatwiania spraw.

Myślę, że CLOS jest dużo lepiej zaprojektowany i elastyczny niż model obiektowy C++ - TinyCLOS nie powinno się w tym aspekcie różnić.

Answer 2

Sure Scheme jako całość ma mniej bibliotek w zdefiniowanym standardzie, ale każda dana implementacja Schematu zazwyczaj opiera się na tym standardzie, aby uwzględnić więcej funkcji typu "baterie włączone".

Gambit, na przykład, korzysta z systemu paczek Snow, który da ci dostęp do kilku bibliotek wsparcia.

Inne programy są jeszcze lepsze, mając dostęp do większej liczby (lub lepszych) bibliotek wsparcia. Zarówno rakieta (z PlaneT) i kurczaka (z eggs) natychmiast przychodzą na myśl.

To znaczy, że Common Lisp jest dość bogaty, a wiele interesujących i użytecznych bibliotek to prosty asdf-install z dala.

Jeśli chodzi o systemy obiektowe Schematu, ja osobiście staram się faworyzować program kurczaka i postanowiłem faworyzować coops. Powiedział, że nie ma absolutnie nic złego w TinyCLOS. Albo służyłby dobrze i tak naprawdę nie znalazł niczego, czego by brakowało. Chociaż to ostatnie stwierdzenie może mieć więcej wspólnego z faktem, że nie staram się polegać na wielu obiektowo zorientowanych słownikach podczas pisania Schematu. Oba systemy w moim doświadczeniu mają tendencję do wynurzania się, kiedy chcę napisać "protokoły", a następnie mam sposób na wyspecjalizowanie się w protokole, jeśli ma to sens.