Greenspunの第10規則、すべての大規模プロジェクトにはLispインタープリターが含まれていますか？[閉まっている]

Greenspunの10番目のルール（実際には唯一のルール）は次のように述べています：

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

私の記憶は、おそらくBorlandのQuattro（スプレッドシート）プロジェクトとおそらく他のもののために、トピックに関するいくつかの論文があるということです。Googleは役に立たず、適切な検索用語が思い浮かばないかもしれません。この主張を支持する論文または記事を探しています。

ステートメントは誇張です。しかし、他の言語でのLispのvy望の明らかな兆候があります。C＃と、それが実際にどのように機能するようになっているかを見てください。プログラムを変更せずにシステムをプログラムできるように、さまざまなビジネスプロセス管理、ワークフロー、およびEAIフレームワークを見てください。

オブジェクト指向言語でメタプログラミングを行う方法について説明しているMartin Fowlerによるドメイン固有言語に関する本があります。したがって、誇張にはいくつかの真実があります。

ポール・グラハムは、Lispに付属する最初のリストを見て、Lispを最も強力な言語と呼びました。多くの言語が比較して見劣りする理由は簡単にわかります。

10番目のルールを回避する方法は、多言語プログラミングです。1つの言語/フレームワークが黄金のハンマーではないことを認識しています。その後、Lispの貧弱なアドホックな実装を作成する代わりに、Lispを使用できます。

Greenspunの「10番目のルール」は、ちょっとしたスナークでした。十分に拡張した場合、「スクリプトまたは構成システム」をカバーする場合、構成はある程度重要なプログラムがある程度必要とするものであるため、明らかにこの質問に対する答えは「はい」でなければなりません。複雑さのスケールを上げると、あまり一般的ではありません。

一方、ゲームプログラミング用にNaughty Dogによって発明されたLispバリアントであるGOALを見てください。それはまったく「古典的な」Lispのようには見えません。これは非常に命令型のシステムであり、オブジェクト指向機能、インタープリターなし、ガベージコレクションの最小限のサポート（代わりにランタイムレベルのクリーンアップ機能に依存）、およびインラインアセンブリの広範なサポートを備えています。

言い換えれば、彼らが十分に複雑なプロジェクトにLispを使用しようとしたとき、彼らは何か便利なことをするには、言語をC ++の半分の非公式で非公式の実装に変えなければならないことに気づいた！;）（そして、誰も彼のコードを理解できなかったので、彼らは最終的に、GOALを設計した人が去った後、それの使用を止めなければなりませんでした。）

奇妙なことに、この質問に対する答えの1つは 既にProgrammers SEにあります。

関連部分を引用するには：

Greenspunのポイントは、（部分的に）多くの複雑なプログラムに組み込みのインタープリターがあることでした。インタプリタを言語に組み込むのではなく、すでにインタプリタ（またはコンパイラ）が組み込まれているLispのような言語を使用する方が意味があるかもしれないと提案しました。

当時私は、カスタム言語用のカスタムインタープリターを使用してユーザー定義の計算を実行するかなり大きなアプリで作業していました。大規模な実験として、Lispでコアを書き直すことにしました。

およそ6週間かかりました。元のコードは〜100,000行のDelphi（Pascalバリアント）です。Lispでは、これは〜10,000行に削減されました。しかし、さらに驚くべきことは、Lispエンジンが3〜6倍速いという事実でした。そして、これはLisp初心者の仕事であったことに留意してください！その経験全体は私にとって非常に驚くべきものでした。パフォーマンスと表現力を単一の言語で組み合わせる可能性を初めて見ました。
-マイケル・レナハン

その部分をさらに明確にするために、マイケルはコメントに次のように応答しました。

うわー、それはなんとかLisp実装よりも3〜6倍遅く実行することができたなら、それは本当に恐ろしいDelphiコードだったに違いない！ Lisp式へのユーザー式-簡単なプロセス-そして、Lisp式をネイティブコードにコンパイルします（完全に最適化されます）これは、Greenspunの第10規則の意味です-Michael
Lenaghan

この回答は他の誰かの回答で構成されているため、コミュニティwikiです。

ルールは冗談ですが、そこには少し真実があります。複雑なシステムには、多数の解釈された部分が含まれます（「インタープリターパターン」は、そのすべてのパターンを信じている人の間で人気がある方法を参照してください）。複雑なシステムは、構造化され、しばしば解釈される構成の手段を提供する必要があります。

複雑なシステムでは、ビルドプロセスにいくつかのコード生成パスとさまざまなカスタマイズされたプリプロセッサが存在する可能性が非常に高くなります（mocQtやtablegen LLVM）。

多くのシステムは、Common Lispのライブラリ機能によく似た（ほとんど常に）設計が不十分なツリーウォーキングおよび変換ツールのセットを使用して、複雑なツリーのようなデータ構造をジャグリングしています。

これらはすべてLispで無料で提供されます。ほとんどの場合、そのようなアドホックで計画外の、十分に十分な実装では考えられないものはすべて完全に劣っています。

十分に複雑なシステムには、作業中の言語の抽象化では表現するのが非常に難しいドメイン固有の概念と要件があります。これにより、プログラミング言語間のセマンティックギャップを埋める負担を軽減するために、プログラマーがドメイン固有の抽象化を強制的に作成するように強制されますおよび特定のドメイン。これらの抽象化が十分にできたら、基本的にドメイン固有の言語のインタープリターができます。これは、ソフトウェア開発の避けられない部分です。

「動的な振る舞いを実装するには、すべての大規模なソフトウェアベースのシステムが必要になる」ため、ルールはおそらくより正確に（そしてそれほど面白くない）できます。

これには2つの方法があります。

1. 数十のパラメーターと数百の定義を持つ大規模で複雑な構成ファイル。

2. AD-HOCスクリプト言語。

「sendmail」は、おそらくタイプ「1」の標準的な例です。Warcraft / LUAまたはNetscape / Javascriptに「本物の」スクリプト言語を埋め込むことを伴わないタイプ「2」の良い例は考えられません。

問題は、いくつかのパラメータが設定ファイルを使用して迅速かつ簡単に実行できることですが、このソリューションは実際には拡張できません。ただし、構成ファイルに1つまたは2つのオプションを追加するときに、スクリプトによるアプローチを優先して構成ファイルをダンプすることは、決して経済的ではありません。そのため、設定ファイルを解釈するコードは、本当にひどく書かれたインタープリターになってしまいます。

他の人が述べたように、それは真実かもしれませんが、多くのプログラムは設定可能性を必要とするため、さまざまなLispのようなインタプリタが含まれています。

しかし、この文は、あなたがプログラムを作るのに必要なのはLispだけであり、他のすべての言語はそれに劣っていることをにやにやと暗示しています。

しかし、それは間違っています。Lispは表現力豊かかもしれませんが、抽象的すぎて、プラットフォームの詳細を隠して、コンピューターの世界にリストが存在するふりをしようとします。

高性能プログラミングの現実は、時々ビットとバイトを混ぜる必要があり、OS固有のことをする必要があるため、ステートメントが示すようにLispだけですべてを行うことは不可能です。

それはむしろ逆であり、あなたが発明する言語がどれほど複雑で、賢く、洗練されていても、アセンブリを書くための単なる別の方法です。

真剣に受け止めるつもりであったかどうかにかかわらず、私が取り組んできた最大のCおよびC ++プロジェクトに当てはまります。

真実ではないのは、カスタムスクリプト言語がCommon Lispに似ているということです。ポジティブな例はSchemeに似ています（よりスマートなデザイナーは、独自の言語を発明するのではなく、Guile、SpiderMonkey、Luaを統合したためです）。

別の例（Greenspunningとしてカウントされるかどうかはわかりませんが、確かにWTF）は、汎用スクリプトに使用されるXSLTインタープリターです。これは、出力が2回目にXSLT変換されるフィードバックループを追加したため、よりLispに似ていました。したがって、マクロを効果的に使用できるようになりました。
ここでの動機は、lispy機能へのアクセスではなく、会社のコードQA手順を回避することでした（すべてのバグ修正に3週間の遅延を追加しました。XMLは「データ」と見なされ、プロセスから除外されます）。

残念ながら違います！

本物のlisp（y）インタープリターを埋め込むのが最善ですが（javascriptまたはlua alosは素晴らしい仕事をします）、homebrew 4glをプロジェクトに追加すると、全体的なサイズが小さくなり、柔軟性が増します。

「すべてをコーディング」するプロジェクトは、モジュール数が非常に多く、扱いにくく柔軟性に欠けます。