Confronto di Common Lisp con Gambit w.r.t loro accesso alle librerie e ai sistemi degli oggetti

Question

Sono piuttosto incuriosito da Gambit Scheme, in particolare dalla sua vasta gamma di piattaforme supportate e dalla sua capacità di inserire il codice C nella propria origine Scheme quando necessario. Detto questo, è uno Schema, che ha meno "batterie incluse" rispetto a Common Lisp. Ad alcune persone piace codificare molte cose da zero, (ad esempio una vigorosa rasatura degli yak) ma non io!

Questo mi porta alle mie due domande, orientata a persone che hanno utilizzato sia Gambit e un certo sapore di Common Lisp:

1) che ha effettivamente un migliore accesso alle biblioteche? Scheme ha meno librerie di Common Lisp. Tuttavia, Gambit Scheme ha un accesso più agevole alle librerie C/C++ del codice &, che superano di gran lunga le librerie del Common Lisp. Secondo te, la scorrevolezza della FFI di Gambit supera la sua mancanza di librerie native?

2) Come si confrontano i sistemi oggetto di Scheme (ad esempio TinyCLOS, Meroon) con il CLOS del Common Lisp? Se li hai trovati carenti, quali caratteristiche ti sono mancate di più? Infine, quanto è importante un sistema di oggetti in Lisp/Scheme in primo luogo? Ho sentito parlare di intere aziende basate su Lisp (ad es. ITA Software) che rinunciano completamente a CLOS. Gli oggetti sono davvero così facoltativi in ​​Lisp/Scheme? Temo che se Gambit non ha un buon sistema di oggetti, potrei mancarli (il mio background di programmazione è puramente orientato agli oggetti).

Grazie per aiutare un aspirante convertire da C++/Python,

- Matt

PS: Qualcuno con più di 1500 rep, la prego di creare un tag "gambit"? :) Grazie Jonas!

Answer 1

1) Non ho usato Gambit Scheme, quindi non posso davvero dire quanto sia fluida l'integrazione di C/C++. Ma tutti i Common Lisp che ho usato hanno C FFI completamente funzionale: s. Quindi la disponibilità delle librerie C è la stessa. Ci vuole del lavoro da integrare, ma presumo che questo sia il caso anche del Gambit Scheme. Dopotutto, Lisp e C sono lingue diverse ...? Ma forse hai un'esperienza diversa, mi piacerebbe saperne di più in quel caso.

Potresti essere interessato a Quicklisp, un ottimo nuovo progetto Common Lisp: semplifica l'installazione di molte librerie di qualità.

2) C++ e Python sono progettati per utilizzare OOP e classi come mezzo tipico per incapsulare e strutturare i dati. CLOS non ha questa ambizione. Invece, fornisce funzioni generiche che possono essere specializzate per determinati tipi di argomenti - non necessariamente classi. Essenzialmente questo consente OOP, ma in Common Lisp, l'OOP è una funzionalità utile piuttosto che qualcosa di fondamentale per fare le cose.

Penso che CLOS sia molto più ben progettato e flessibile rispetto al modello a oggetti C++ - TinyCLOS non dovrebbe essere diverso in questo aspetto.

Answer 2

Sure Scheme ha un numero inferiore di librerie nello standard definito, ma qualsiasi implementazione di Schema di solito si basa su tale standard per includere più tipi di funzioni "batterie incluse".

Gambit, ad esempio, utilizza il sistema di pacchetto Snow che consente di accedere a diverse librerie di supporto.

Altri schemi vanno anche meglio, avendo accesso a più (o meglio) librerie di supporto. Vengono subito in mente sia Racket (con PlaneT) che Chicken (con eggs).

Detto questo, il Common Lisp è abbastanza ricco e un gran numero di librerie interessanti e utili è una semplice installazione di asdf.

Per quanto riguarda i sistemi di oggetti Scheme, personalmente tendo a favorire il regime di pollo e ho preso a favorire lo coops. Detto questo, non c'è assolutamente nulla di sbagliato in TinyCLOS. O servirebbe bene e in realtà non troverebbe nulla da mancare. Anche se quest'ultima affermazione potrebbe avere più a che fare con il fatto che non tendo a fare affidamento su un sacco di isistemi orientati agli oggetti durante la scrittura di Scheme. Entrambi i sistemi nella mia esperienza tendono a emergere quando voglio scrivere "protocolli" e quindi avere un modo di specializzarmi sul protocollo, se questo ha senso.