Confrontando Common Lisp con Gambit w.r.t i loro sistemi di accesso e oggetto della biblioteca

Question

Sono abbastanza incuriosito da Gambit Scheme, in particolare per la sua vasta gamma di piattaforme supportate, e la sua capacità di mettere il codice C nel vostro sorgente Scheme quando necessario. Detto questo, si tratta di uno schema, che ha un minor numero di "batterie incluse" rispetto al Common Lisp. Alcune persone, come la codifica un sacco di cose da zero, (anche noto come vigoroso yak-barba), ma non me!

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

1) che ha effettivamente un migliore accesso alle biblioteche? Schema ha un minor numero di librerie di Common Lisp. Tuttavia, Gambit Scheme ha accesso più agevole per C / C ++ e librerie, che superano di gran lunga le librerie di Common Lisp. Secondo lei, fa la morbidezza della FFI di Gambit superano la sua mancanza di librerie native?

2) In che modo i sistemi oggetto del regime (per esempio TinyCLOS, Meroon) confronta con CLOS di Common Lisp? Se hai trovato li manca, che cosa caratteristica (s) ti è mancato di più? Infine, quanto è importante un sistema di oggetti in Lisp / Scheme, in primo luogo? Ho sentito parlare di intere aziende Lisp-based (ad esempio ITA Software) rinunciando CLOS del tutto. Sono oggetti davvero così facoltativa in Lisp / Scheme? Io temo che se non ha un sistema Gambit oggetto buono, posso perdere loro (il mio background di programmazione è puramente orientata agli oggetti).

Grazie per aiutare un aspirante convertito 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 liscio il C / C ++ integrazione è. Ma tutti Lisps comuni che ho usato sono completamente funzionale C FFI: s. Quindi la disponibilità di librerie C è lo stesso. Ci vuole un certo lavoro di integrazione, ma suppongo questo è il caso di Gambit Schema pure. Dopo tutto, Lisp e C sono diverse lingue ..? Ma forse avete un'esperienza diversa, mi piacerebbe saperne di più in questo caso.

Si può essere interessati a Quicklisp , davvero un buon nuovo progetto Common Lisp - rende molto facile installare un sacco di librerie di qualità.

2) C ++ e Python sono progettati per uso OOP e classi come mezzo tipici di incapsulare e strutturazione dei dati. CLOS non ha questa ambizione a tutti. Invece, fornisce funzioni generiche che possono essere specializzati per determinati tipi di argomenti - non necessariamente classi. Essenzialmente questo permette OOP, ma in Common Lisp, OOP è una caratteristica comodo, piuttosto che qualcosa di fondamentale per fare le cose.

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

Answer 2

Certo Scheme nel suo complesso ha un minor numero di biblioteche del standard definito, ma un dato esecuzione Schema di solito si basa su questo standard per includere più "batterie incluse" tipo di funzioni.

Gambit, ad esempio, utilizza il Neve sistema di pacchetti che vi darà accesso a diverse librerie di supporto.

Altri Schemi la passano meglio ancora, avere accesso a più (o migliori) librerie di supporto. Entrambi Racket (con pianeta ) e di pollo (con uova ) immediatamente venire in mente.

Detto questo, il Common Lisp è piuttosto ricca anche e un gran numero di librerie interessanti e utili sono un semplice asdf-installazione via.

Per quanto riguarda i sistemi di oggetti Scheme, io personalmente tendo a favorire Schema di pollo e hanno preso a favorire cooperative . Detto questo, non c'è assolutamente niente di sbagliato con TinyCLOS. In entrambi i servirebbe bene e in realtà non trovare nulla di essere carente. Anche se l'ultima affermazione potrebbe avere più a che fare con il fatto che io non tendono a fare affidamento su un sacco di Object Oriented-ismi durante la scrittura Scheme. Entrambi i sistemi nella mia esperienza tendono a superficie quando voglio scrivere "protocolli" e poi hanno un modo di specializzarsi sul protocollo, se questo ha un senso.