[解決済み] SchemeとCommon Lispの実際の違いは何ですか？(または、他の2つのLispの方言でもかまいません。）

質問

注：どちらを学ぶべきか、どちらが優れているか、などという質問ではありません。

SICPの無料版を手に取ったのは、読んでもいいかなと思ったからです（いい話を聞いたし、プログラミングのそういう方面にも興味があります）。

SchemeがLispの方言であることは知っていますが、Schemeと例えばCommon Lispの実際の違いは何でしょうか。

CLはstdlibが大きいから...Schemeは実世界のプログラミングには向かない...」というのはよく聞く話ですが、「CLはこうだから／こうだから」というのは、実際にないような気がします。

どのように解決するのですか？

この違いは、技術的なものと (私が考えるより重要なことですが) 文化的なものの両方であるため、これは少し厄介な質問です。 答えは、不正確で主観的な見解しか提供できません。 そこで、このページでは、このような答えを提示しようと思います。 技術的な詳細については スキームWiki .

スキーム は、エレガントで一貫した、よく考えられた基本言語を提供するという原則のもとに作られた言語で、その上に実用的で学術的な応用言語を構築することができます。

R5RS(あるいはR6RS)の純粋なSchemeでアプリケーションを書いている人はめったにいませんし、 最小限の規格しかないため、ほとんどのコードはSchemeの実装を越えて移植可能ではありません。 つまり、エンドユーザ向けのアプリケーションを書こうと思えば、Scheme処理系を慎重に選択しなければならない。 一方、実際のアプリケーション言語の設計が比較的自由であるため、Scheme処理系は他では見られないような機能をしばしば提供する。例えばPLT Racketでは、静的型付けが利用でき、言語を意識したIDEが提供されている。

基本言語以外の相互運用性は、コミュニティ主導のSRFIプロセスを通じて提供されますが、任意のSRFIを利用できるかどうかは、実装によって異なります。

Schemeの方言やライブラリの多くは、反復処理ではなく、再帰処理などの関数型プログラミングのイディオムに重点を置いています。 オブジェクト指向を実現するために、様々なオブジェクトシステムをライブラリとして読み込むことができますが、既存のコードとの統合はScheme方言とその周辺の文化に大きく依存します(例えば、Chicken SchemeはRacketよりもオブジェクト指向的なようです)。

インタラクティブなプログラミングも、Schemeのサブコミュニティによって異なる点です。 MIT Schemeは強力なインタラクティビティサポートで知られていますが、 PLT Racketはより静的な印象を受けます。 いずれにせよ、インタラクティブなプログラミングは多くのSchemeサブコミュニティにとって中心的な関心事ではないようで、多くのCommon Lispsのようなインタラクティブなプログラミング環境にはまだお目にかかったことがありません。

Common Lisp は、実用的なプログラミングのために設計された、使い古された言語です。 Schemeの優雅なミニマリズムとは正反対に、醜い弊害や互換性のためのハックに満ちている。 しかし、それ自体としてみれば、より多くの機能を備えているのも事実です。

Common Lispは比較的大きな移植可能なライブラリのエコシステムを育んできた。

Common Lispは比較的大きな移植可能なライブラリのエコシステムを育てました。 全体として、Common LispはSchemeよりもずっと均一であり、より過激な言語実験を行うとしても、全く新しい言語方言を定義するのではなく、通常、ポータブルライブラリとして組み込まれます。 このため、言語拡張はより保守的になりがちですが、より組み合わせやすくなっています(多くの場合、オプションです)。

外部関数インタフェースのような普遍的に有用な言語拡張は、正式な手段で開発されるのではなく、すべての主要なCommon Lisp実装で利用可能な準標準ライブラリに依存する。

言語イディオムは関数型、命令型、オブジェクト指向が混在しており、一般にCommon Lispは関数型言語というより命令型言語のように感じられる。 また、非常に動的であり、一般的な動的スクリプト言語よりも動的である（例えばクラスの再定義は既存のインスタンスに適用され、条件処理システムには対話性が組み込まれている）、対話的・探索的プログラミングは「Common Lisp流」の重要な部分である。

Common Lispは、組み込みのオブジェクトシステム（CLOS）、単なる例外処理よりはるかに強力な条件処理システム、実行時のパッチ適用性、さまざまな組み込みデータ構造およびユーティリティ（悪名高き LOOP マクロ、Schemeにはあまりに醜いが言及しない方がよいほど便利な反復処理サブ言語、printfのような書式設定機構を持つ GOTOのサポート をサポートするprintfライクな書式設定機構もあります)。

Lispはイメージベースの対話的な開発を行うため、また言語が大きいため、Schemeに比べOS間の移植性が劣るのが普通です。 例えば、Common Lispを組み込みデバイスで動作させるのは、気の弱い人には無理です。 Java仮想マシンと同様に、仮想メモリに制限のあるマシン(OpenVZベースの仮想サーバなど)では問題が発生しがちです。 一方、Schemeの実装は、よりコンパクトで移植性が高い傾向がある。 ECL処理系の品質が向上したことで、この点は多少緩和されていますが、本質は変わりません。

商用サポートにこだわるなら、グラフィカルGUIビルダーや特殊なデータベースシステムなど、独自のCommon Lisp実装を提供する会社がいくつかあります。

まとめ , Schemeはよりエレガントに設計された言語です。 主に関数型言語だが、動的な機能もある。 その実装は、特徴的な機能を持つ様々な非互換な方言を表しています。 Common Lispは、本格的な、高度に動的な、マルチパラダイム言語であり、 様々な醜い、しかし実用的な特徴を持ち、その実装は互いにほぼ互換性がある。 Schemeの方言はCommon Lispよりも静的で対話的でない傾向があり、 Common Lispの実装は重く、インストールが面倒な傾向があります。

どの言語を選んでも、楽しくなることを祈っています。:)