注: 私は、どちらを学ぶべきか、どちらが優れているか、またはそのようなことを尋ねているわけではありません。
SICP の無料版を手に取ったのは、それが読みやすいと感じたからです (私はそれについて良いことを聞いたことがあり、プログラミングのその種の側面に興味があります)。
私はSchemeがLispの方言であることを知っています.SchemeとCommon Lispの実際の違いは何ですか?
「CLにはより大きなstdlibがあります...スキームは実際のプログラミングには適していません..」についてはたくさんあるようですが、「これはCLがこれ/これを持っているためです」という実際のことはありません。
違いは技術的なものと (より重要なこととして、私の意見では) 文化的なものであるため、これは少し難しい質問です。答えは、不正確で主観的な見方しか提供できません。これが私がここで提供するものです。生の技術的な詳細については、Scheme Wikiを参照してください。
Schemeは、エレガントで一貫性があり、よく考え抜かれた基本言語基盤を提供するという原則に基づいて構築された言語であり、実用的なアプリケーション言語と学術的なアプリケーション言語の両方を構築できます。
純粋な R5RS (または R6RS) スキームでアプリケーションを書いている人を見つけることはめったにありません。最小限の標準のため、ほとんどのコードはスキームの実装間で移植できません。これは、何らかの種類のエンドユーザー アプリケーションを作成する場合、Scheme の実装を慎重に選択する必要があることを意味します。その選択によって、利用できるライブラリが大きく決まるからです。一方、実際のアプリケーション言語の設計は比較的自由であるということは、Scheme の実装が他の場所では前代未聞の機能を提供することが多いことを意味します。たとえば、PLT Racket を使用すると、静的型付けを利用できるようになり、非常に言語を認識する IDE が提供されます。
基本言語を超えた相互運用性は、コミュニティ主導の SRFI プロセスを通じて提供されますが、特定の SRFI の可用性は実装によって異なります。
ほとんどのSchemeの方言とライブラリは、反復ではなく再帰のような関数型プログラミングのイディオムに焦点を当てています. OOP を実行したいときにライブラリとしてロードできるさまざまなオブジェクト システムがありますが、既存のコードとの統合は、Scheme 方言とその周囲の文化に大きく依存します (たとえば、Chicken Scheme は Racket よりもオブジェクト指向のようです)。
対話型プログラミングは、Scheme サブコミュニティが異なるもう 1 つのポイントです。MIT スキームは強力な対話型サポートで知られていますが、PLT Racket はより静的に感じられます。いずれにせよ、対話型プログラミングはほとんどの Scheme サブコミュニティにとって中心的な関心事ではないようであり、ほとんどの Common Lisp と同様に対話型のプログラミング環境を私はまだ見たことがありません。
Common Lispは、実用的なプログラミング用に設計された、戦場で使用される言語です。それは醜い疣贅と互換性ハックでいっぱいです-Schemeのエレガントなミニマリズムとは正反対です. しかし、それ自体を使用すると、はるかに機能的になります。
Common Lisp は、ポータブル ライブラリの比較的大きなエコシステムを生み出しました。通常、アプリケーションのデプロイ後でも、それほど問題なく、いつでも実装を切り替えることができます。全体として、Common Lisp は Scheme よりもはるかに統一されており、より急進的な言語実験が行われたとしても、通常、まったく新しい言語の方言を定義するのではなく、移植可能なライブラリとして組み込まれています。このため、言語拡張はより保守的である傾向がありますが、より組み合わせ可能でもあります (多くの場合、オプションです)。
外部関数インターフェイスのような普遍的に有用な言語拡張は、正式な手段によって開発されたのではなく、すべての主要な Common Lisp 実装で利用可能な準標準ライブラリに依存しています。
言語イディオムは、関数型、命令型、およびオブジェクト指向のアプローチが乱雑に混ざり合ったものであり、一般的に、Common Lisp は関数型言語というよりは命令型言語のように感じられます。また、非常に動的であり、おそらく一般的な動的スクリプト言語のどれよりも動的です (たとえば、クラスの再定義は既存のインスタンスに適用され、条件処理システムには対話機能が組み込まれています)。 「Common Lisp のやり方」これは、Common Lisp で利用可能なプログラミング環境にも反映されており、実質的にすべての環境で、実行中の Lisp コンパイラと何らかの直接対話が行われます。
Common Lisp は、ビルトイン オブジェクト システム (CLOS)、単なる例外処理よりもはるかに強力な条件処理システム、ランタイム パッチ可能性、さまざまな種類のビルトイン データ構造とユーティリティ (悪名高いLOOPマクロ、反復マクロを含む) を備えています。サブ言語は、Scheme にはあまりにも醜いですが、言うまでもなく便利すぎます。また、書式文字列でGOTO をサポートする printf のような書式設定メカニズムもあります)。
イメージベースのインタラクティブな開発とより大きな言語の両方のために、Lisp 実装は通常、Scheme 実装よりもオペレーティング システム間での移植性が低くなります。たとえば、Common Lisp を組み込みデバイスで実行することは、気弱な人向けではありません。Java 仮想マシンと同様に、仮想メモリが制限されているマシン (OpenVZ ベースの仮想サーバーなど) でも問題が発生する傾向があります。一方、スキームの実装は、よりコンパクトで移植性が高い傾向があります。ECL 実装の品質が向上したことで、この点はいくらか軽減されましたが、その本質は依然として真実です。
商用サポートが必要な場合は、グラフィカル GUI ビルダー、特殊なデータベース システムなどを含む独自の Common Lisp 実装を提供している会社がいくつかあります。
要約すると、Scheme はよりエレガントに設計された言語です。これは主に、いくつかの動的機能を備えた関数型言語です。その実装は、独特の機能を持つさまざまな互換性のない方言を表しています。Common Lisp は、さまざまな醜いが実用的な機能を備えた、本格的で高度に動的なマルチパラダイム言語であり、その実装は相互にほぼ互換性があります。Scheme の方言は、Common Lisp よりも静的でインタラクティブではない傾向があります。Common Lisp の実装は、インストールがより重く、トリッキーになる傾向があります。
どの言語を選んでも、楽しく過ごせますように！:)
いくつかの基本的な実際の違い:
(function ...)て値に格納された関数を明示的に呼び出す必要があります。(funcall ...)nil(空のリスト) は false (たとえば ) と見なされif、唯一の false 値です。Scheme では、空リストは true と見なされ、(distinct)#fは唯一の false 値です。特に、LISP 関係者の多くが Scheme を LISP として分類するため、これは公平に答えるのが難しい質問です。
Josh Bloch (この例えは彼の発明ではないかもしれません) は、言語を選択することは地元のパブを選択することに似ていると説明しています。その観点から、次のようになります。
「Scheme」というパブには、プログラミング言語の研究者がたくさんいます。これらの人々は、言語の意味、明確に定義されたシンプルな言語を維持すること、および革新的な新機能について議論することに多くの注意を払います。誰もが独自のバージョンの言語を持っており、プログラミング言語の特定のコーナーを探索できるように設計されています。Scheme の人々は、LISP から取った括弧付きの構文をとても気に入っています。柔軟性があり、軽量で統一されており、言語拡張に対する多くの障壁を取り除きます。
「LISP」パブ？ええと...コメントするべきではありません。私はそこに十分な時間を費やしていません:)。
図式：
Common lisp：
それはいくつかのポイントです、確かにもっとたくさんありますが、私は今覚えていません。