5
スキームvs Common Lisp:どの特性がプロジェクトに違いをもたらしましたか?[閉まっている]
StackOverflowとこのサイトの両方で、あいまいな「Scheme vs Common Lisp」の質問が不足しているわけではないので、これにもっと焦点を当てたいと思います。質問は、両方の言語でコーディングした人向けです。 Schemeでコーディングしているときに、Common Lispコーディングエクスペリエンスで最も見逃した要素は何ですか?または、逆に、Common Lispでコーディングしているときに、Schemeでコーディングすることから何を逃しましたか? 言語機能だけを意味するわけではありません。以下は、質問に関する限り、見逃してはならない有効なものです。 特定のライブラリ。 SLIME、DrRacketなどの開発環境の特定の機能 CコードのブロックをSchemeソースに直接書き込むGambitの機能など、特定の実装の機能。 そしてもちろん、言語機能。 私が望んでいる種類の答えの例: 「Common LispでXを実装しようとしていたので、もしSchemeの第一級の継続があれば、Yをやっただけでしたが、代わりにZをやらなければならなかったので、苦労しました。」 「Schemeプロジェクトでのビルドプロセスのスクリプト作成は、ソースツリーが成長し、Cライブラリをより多くリンクするにつれてますます苦しくなりました。次のプロジェクトでは、Common Lispに戻りました。」 「既存の大きなC ++コードベースがあり、私にとっては、Gambit SchemeコードにC ++呼び出しを直接埋め込むことができたのは、SchemeがCommon Lispに対して持っていた短所、SWIGサポートの欠如を含めて、まったく価値がありました。」 ですから、「スキームはもっとシンプルな言語です」などの一般的な感情ではなく、戦争の物語を望んでいます。