グリーンスパンの第10の規則、すべての大規模プロジェクトにはLISPインタープリターが含まれていますか？
グリーンスパンの10番目のルール（実際には唯一のルール）は次のように述べています。
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common LISP.
私の記憶は、おそらくボーランドのクアトロ（スプレッドシート）プロジェクトとおそらく他のトピックについて、このトピックに関するいくつかの論文があることです。グーグルは役に立たない、おそらく正しい検索用語が頭に浮かばない。もしあれば、この主張を裏付ける論文や記事を探しています。
ステートメントは誇張です。しかし、他の言語にはLISPの羨望の徴候があります。 C＃を調べて、C＃がより機能的になるようにしてください。プログラムを変更せずにシステムをプログラミングできるようにするために、さまざまなビジネスプロセス管理、ワークフロー、およびEAIフレームワークを見てください。
Martin Fowlerによるドメイン固有言語に関する本があり、オブジェクト指向言語でメタプログラミングを行う方法について説明しています。したがって、誇張にはいくつかの真実があります。
Paul Grahamは、LISPを LISPに付属する最初のリスト を見て最も強力な言語と呼び、多くの言語が比較して見劣りする理由を簡単に理解できます。
10番目のルールを回避する方法は、ポリグロットプログラミングです。 1つの言語/フレームワークがゴールデンハンマーではないことを理解する。次に、LISPの貧弱なアドホック実装を作成する代わりに、LISPを使用できます。
グリーンスパンの「第10の規則」は、ひっそりとしたところにありました。十分に引き延ばした場合、「任意のスクリプトまたは構成システム」を対象とする場合、構成はある程度の重要なプログラムとスクリプトで必要なものであるため、この質問に対する答えは「はい」でなければなりません。複雑さのスケールを上げると、一般的ではなくなります。
一方、ゲームプログラミング用にNaughty Dogが発明したLISPの変形である [〜＃〜] goal [〜＃〜] を見てください。 「クラシック」なLISPとはまったく異なります。オブジェクト指向の機能、インタープリターなし、ガベージコレクションの最小サポート（ランタイムレベルのクリーンアップ機能に依存）、インラインアセンブリの広範なサポートを備えた、非常に命令型のシステムです。
言い換えると、十分に複雑なプロジェクトでLISPを使用しようとしたときに、有用なことを行うには、言語をアドホックで非公式に指定されたC++の半分の実装に変換する必要があることがわかりました。 ;）（そして、誰も彼のコードを理解できなかったため、GOALを設計した人が去った後、彼らは最終的にそれを使用しなければならなくなりました。）
不思議なことに、この質問に対する1つの答えは プログラマーSEで既に です。
関連部分を引用するには：
Greenspunの要点は、（部分的に）多くの複雑なプログラムにインタープリターが組み込まれているということでした。インタープリターを言語に組み込むよりも、インタープリター（またはコンパイラー）がすでに組み込まれているLISPのような言語を使用する方が理にかなっている可能性があると彼は提案しました。
当時、私はカスタム言語のカスタムインタープリターを使用してユーザー定義の計算を実行する、かなり大きなアプリに取り組んでいました。大規模な実験として、LISPでコアを書き直すことにしました。
およそ6週間かかりました。元のコードはDelphi（Pascalバリアント）の約10万行でした。 LISPでは約10,000行に削減されました。しかし、さらに驚くべきことは、LISPエンジンが3〜6倍高速であるという事実でした。これはLISPの初心者の作品であることを忘れないでください！その全体の経験は私にとってかなり目を見張るものでした。初めて、パフォーマンスと表現力を単一の言語で組み合わせる可能性を見ました。
- Michael Lenaghan
その部分をさらに明確にするために、マイケルはコメントに次のように答えました。
うわー、なんとかしてLISP実装よりも3〜6倍遅く実行できたとしたら、それは本当に恐ろしいDelphiコードだったに違いありません！」ユーザー式を簡単にLISP式に変換し、LISP式をネイティブコードに（完全に最適化して）コンパイルします。これがGreenspunの10番目の規則の意味です。
-マイケルレナガン
この回答が他の誰かの回答で構成されているとすると、それはコミュニティーwikiです。
ルールは冗談ですが、少し真実があります。複雑なシステムには、解釈された部分が多数含まれます（「インタプリタパターン」がそのすべてのパターンを信じる人の間で人気がある方法を参照してください）。複雑なシステムは、何らかの構成手段を提供する必要があり、多くの場合、構造化され、解釈されます。
複雑なシステムでは、ビルドプロセスにいくつかのコード生成パスとさまざまなカスタマイズされたプリプロセッサが含まれている可能性が非常に高くなります（QtのmocやLLVMのtablegenなどを考えてください）。
多くのシステムは、Common LISPのライブラリ機能によく似た（ほとんどの場合）不十分に設計されたツリーウォーキングツールと変換ツールのセットを使用して、複雑なツリー状のデータ構造を調整しています。
これらすべてはLISPで無料で提供されます。ほとんどの場合、アドホックで計画外で、十分に十分な実装を検討しなかった場合は、まったく劣ります。
十分に複雑なシステムには、使用している言語の抽象化では表現するのが非常に難しいドメイン固有の概念と要件があります。これにより、プログラマーはドメイン固有の抽象化を作成し、プログラミング言語間のセマンティックギャップを埋める負担を軽減します。そして特定のドメイン。これらの抽象化が十分に行われると、基本的にドメイン固有言語のインタープリターができます。これはソフトウェア開発の避けられない部分です。
「動的な動作を実装するには、大規模なソフトウェアベースのシステムがすべて必要になる」ので、ルールはおそらくより正確（かつ面白味が少ない）になるでしょう。
これには2つの方法があります。
数十のパラメーターと数百の定義を持つ大規模で複雑な構成ファイル。
AD-HOCスクリプト言語。
「sendmail」は、おそらく「1」型の標準的な例です。 Warcraft/LUAやNetscape/Javascriptに「実際の」スクリプト言語を埋め込むことを含まないタイプ「2」の良い例は思いつきません。
問題は、いくつかのパラメーターについて、構成ファイルを使用してすばやく簡単に実行できることですが、このソリューションは実際には拡張できません。ただし、構成ファイルに1つまたは2つのオプションを追加するときに、スクリプトアプローチを優先して構成ファイルをダンプすることは決して経済的ではありません。そのため、構成ファイルを解釈するコードは、最終的には本当にひどく書かれたインタプリタになってしまいます。
真剣に受け止めるべきかどうかに関係なく、私が取り組んだ最大のCおよびC++プロジェクトに当てはまります。
事実ではないのは、カスタムスクリプト言語がCommon LISPに似ていることです。肯定的な例は、Schemeに似ています（より賢い設計者は、独自の言語を発明する代わりに、Guile、SpiderMonkey、およびLuaを統合したためです）。
別の例（Greenspunningとしてカウントされるかどうかはわかりませんが、確かにWTF）は、汎用スクリプトに使用されるXSLTインタープリターです。これは、出力が2回目にXSLT変換されるフィードバックループを追加したため、よりLISPに似ていました。つまり、マクロが効果的に使用できるようになりました。
ここでの動機は、lispy機能にアクセスすることではなく、会社のコードQA手順を回避することでした（すべてのバグ修正に3週間のレイテンシが追加されました。XMLは「データ」と見なされ、プロセスから除外されました）。
他の人が述べたように、それは本当かもしれません、多くのプログラムは設定可能性を必要とするので、様々なLISPのようなインタープリターを含みます。
ただし、この記述は、プログラムを作成するために必要なのはLISPだけであり、他のすべての言語はそれよりも劣っていることを暗示しています。
しかし、それは間違っています。LISPは表現力豊かかもしれませんが、あまりにも抽象的であり、プラットフォームの詳細を隠し、コンピュータの世界にリストしか存在しないふりをしようとします。
高性能プログラミングの現実は、ビットとバイトを混ぜて、OS固有のものを実行する必要がある場合があるため、LISPだけですべてを実行することは不可能です。
それはむしろ逆ですあなたが発明した言語がどれほど複雑で、巧妙で、洗練されていても、結局それはただアセンブリを書くための別の方法にすぎません。