ライブラリアクセスとオブジェクトシステムに関して Common Lisp と Gambit を比較する

Question

私は Gambit Scheme に非常に興味をそそられています。特に、サポートされている幅広いプラットフォームと、必要に応じて C コードを Scheme ソースに直接配置できる機能に興味があります。とはいえ、これは Common Lisp と比較して「含まれるバッテリー」が少ない Scheme です。多くのことを最初からコーディングするのが好きな人もいます (別名:激しいヤクの毛剃り）でも私は違います！

そこで、Gambit と Common Lisp の両方を使用したことがある人々に向けた 2 つの質問が生まれます。

1) 図書館へのアクセスが効果的に優れているのはどちらですか?Scheme のライブラリは Common Lisp よりも少ないです。ただし、Gambit Scheme は、Common Lisp のライブラリよりもはるかに多い C/C++ コードとライブラリにスムーズにアクセスできます。あなたの意見では、Gambit の FFI のスムーズさは、ネイティブ ライブラリがないことを補っていますか?

2) Scheme のオブジェクト システム (例:TinyCLOS、Meroon) を Common Lisp の CLOS と比較しますか?不足している機能があると感じた場合、最も不足している機能は何ですか?最後に、そもそも Lisp/Scheme におけるオブジェクト システムはどれくらい重要ですか?私は、Lisp ベースの企業全体について聞いたことがあります (例:ITA Software) は CLOS を完全に廃止しました。Lisp/Scheme ではオブジェクトは本当にオプションなのでしょうか?Gambit に優れたオブジェクト システムがない場合、それらを見逃してしまうのではないかと心配しています (私のプログラミングの背景は純粋にオブジェクト指向です)。

C++/Python からの変換を目指す人を支援してくれてありがとう。

-- マット

追伸：リプ数が 1500 を超えている方、「ギャンビット」タグを作成していただけませんか。:) ありがとうジョナス！

Answer 1

1) 私は Gambit Scheme を使用したことがないので、C/C++ の統合がどれほどスムーズであるかを実際には知ることができません。しかし、私が使用したすべての Common Lisp には、完全に機能する C FFI: が含まれています。したがって、C ライブラリの可用性は同じです。統合するには多少の作業が必要ですが、これは Gambit Scheme にも当てはまると思います。結局のところ、LispとCは別の言語です...?しかし、あなたは別の経験をしているかもしれません、その場合はもっと学びたいと思います。

興味があるかもしれません クイックリスプ, 、非常に優れた新しい Common Lisp プロジェクトです。これにより、多くの高品質のライブラリを非常に簡単にインストールできます。

2) C++ と Python は、データのカプセル化と構造化の一般的な手段として OOP とクラスを使用するように設計されています。CLOSにはそのような野心はまったくありません。代わりに、特定のタイプの引数 (必ずしもクラスではない) に特化できる汎用関数を提供します。本質的にこれにより OOP が有効になりますが、Common Lisp では、OOP は物事を成し遂げるための基本的なものではなく、便利な機能です。

CLOS は C++ オブジェクト モデルよりもはるかによく設計されており、柔軟性があると思います。その点では TinyCLOS も違いはありません。

Answer 2

確かに、Scheme 全体として、定義された標準に含まれるライブラリは少なくなりますが、特定の Scheme 実装は通常、その標準に基づいて構築され、より多くの「バッテリーが含まれる」タイプの関数が含まれます。

たとえば、Gambit では、 雪 パッケージ システムにより、いくつかのサポート ライブラリにアクセスできるようになります。

他のスキームはさらに優れており、より多くの (またはより優れた) サポート ライブラリにアクセスできます。両ラケット(あり) 惑星）とチキン（ 卵）すぐに思い浮かびます。

そうは言っても、Common Lisp も非常に豊富であり、多数の興味深く便利なライブラリを簡単に asdf インストールするだけで入手できます。

Scheme オブジェクト システムに関しては、私は個人的に Chicken Scheme を好む傾向があり、それを好むようになりました。 小屋. 。とはいえ、TinyCLOS にはまったく問題はありません。どちらでも十分に機能し、不足するものは特にありません。ただし、最後のステートメントは、私が Scheme を書くときにオブジェクト指向主義にあまり依存しないという事実と関係があるかもしれません。私の経験では、どちらのシステムも、「プロトコル」を書きたいときに表面化し、それが理にかなっていれば、そのプロトコルに特化する方法があることが多いです。