拡張可能でインタラクティブなシステムの設計
Steve Yeggeの Pinoccio Problem は、非常に特殊なタイプのプログラムについて説明しています。プログラムは、作成者の本来の目的を果たすだけでなく、任意のユーザー定義の計算を実行することもできます。
また、通常はコンソールをホストします。これにより、実行時にソフトウェアを再プログラムし、変更を永続化することができます。
この問題を推論するのは非常に難しいと思います-プログラムの「コアモジュール」の実装と、システムを実際に実装に依存しないようにすること（つまり、機能がハードコーディングされていないこと）との間に矛盾があるようです。
では、そのようなプログラムをどのように構築するか-どのような手法が役立つでしょうか？それはよく研究されたトピックですか？
ほとんどの人は自分が何を望んでいるのかわからず、自分が何を望んでいるのかを知っている人は、それを次のように説明する方法を知りません。
- コンピュータが理解できる、
- 単なる人間にとって十分にユーザーフレンドリーであり、
- 5分ごとにクラッシュしないほど堅牢であり、
- 将来のビジネスの変化に耐えるのに十分な柔軟性があります。
それがプログラマーが存在する理由です。
ユーザーは自分のプログラムを書くことにあまり興味がないので、結局は構成可能なシステムを書くことです;つまり、次のような設定がありますユーザーが操作できるシステムによってすでに理解されています。運が良ければ、そのような設定の数は十分に少ないので、それらが提供する柔軟性は、あまり複雑にすることなく、問題のドメインに十分です。
Pdrが指摘しているように 彼の答えで 、ドメイン固有言語は、構成が提供できる以上のパワーと柔軟性を必要とする人々にとって良い架け橋です。
これは、「内部プラットフォーム」（アンチ）パターンのように疑わしく聞こえます。
基本的な考え方は、構成やコマンド仕様の自由形式の手段をそれ自体に組み込んだソフトウェアを作成することです。この方法は通常、他の人が正しく指摘しているように、「ドメイン固有言語」またはDSLであり、ソフトウェアによって、作成したより静的なコードに解釈されます。そのような言語はすでにたくさんあります。 VBA、SQL、QuakeおよびSourceエンジンの背後にあるスクリプトなど。
ただし、DSLの例を見ると、このようなパターンの欠陥が明らかになります。 SQL Management Studioのコピーを渡して、独自のレポートクエリを実行させるのに十分なほど、経理の誰もが信頼できるDBAが地球上にいるとは思えません。反対に、カスタムレポートの必要性に対する有効な解決策であると考える会計士が地球上にいるとは思えません。 99％のユーザーは、QuakeまたはSource-engineゲームで何かを自動化するスクリプトを作成する方法がわかりません。それらのエンジンがあなたにできないことの穴を見つけ続けて、不当な利点を与える何かをするもの。
カスタムクエリの作成を簡素化し、ユーザーが独自のクエリ以外のものを台無しにすることのない独自のDSL（グラフィカルまたはテキストベース）を実装することはできますが、DSLを設計する際には非常に細かい線があります。ユーザーが、合法的に必要なことを実行することを妨げたり、有害なことを実行したりすることなく、理解した方法で必要なことを実行できるようにします。多くの場合、そのような解決策はありません。存在する場合でも、できるはずのことをすべて実行できるDSLを提供しても、DSLを変更して、これまで誰も考えたことのない新しいことを許可する必要がなくなります。それは完全に受け入れられ、有害ではありません。そのため、内部プラットフォームは、意図した問題を実際には解決しません。ユーザーが独自の「プログラミング」を行えるようにすることで、実際の開発者はUIやレポートのレイアウト/コンテンツをカスタマイズするよりも興味深いことを実行できます。開発者は常に、ユーザーに提供したDSLを「説明」（つまり、ユーザーの手を握る）し、避けられない「なぜ私はこのようにできないのか」という質問に答えるよう求められます。
プログラマーでさえ、サードパーティソフトウェアとの相互作用のために設計されたDSLを扱う際に、常にこれに対処します。 「ねえ、なぜ私はXを実行できないのか、それは十分に単純に聞こえ、ユーザーが望んでいることを実行するために本当に必要です」...アップ、そして私たちも」。私たちプログラマーは、ある程度のことを期待しています。エンドユーザーは、もう少し使いやすさを期待しています。それが私たちがここにいる理由です。
残念ながら、well研究されたトピックではありませんが、これは研究されたトピックです。このようなシステムは通常、Self-Sustaining Systems、Self-Supporting Systemsまたは（特にSmalltalkコミュニティでは）Lively Systemsと呼ばれます。
当然のことながら、Smalltalk自体はそのようなシステムであり、Smalltalkコミュニティ（特にAlan Kay博士自身）は、これまで以上に強力であると同時に、これまで以上にシンプルなシステムの構築に絶えず取り組んでいます。アランケイ博士の研究グループは現在、完全なパーソナルコンピューティングシステム（すなわち、オペレーティングシステム、プログラミング言語、コンパイラ、VM、IDE、エディタ、Officeスイート、Webブラウザ、リアルタイムコラボレーションなど）を提供する新しい言語と新しいシステムの設計に取り組んでいます。 。）合計20000未満のSLOC。
「....時間の充満、プログラミングの流暢さはリテラシーと同じくらいユビキタスになると私は信じているので、それは問題ではありません.....」
彼は誰もがプログラマーになる運命にあると信じています、私は同意しません。現実の世界では、時間が経つにつれて、人々は自分が毎日行うことについての知識が少なくなっています。以前はダイヤルを回してテレビチャンネルを調整し、「周波数」を理解し、各チャンネルがどこにあるかを知っていたので、今度は「自動プログラム」ボタンを押します。あなたは車を所有していたときに自分のオイルを交換して自分のパンクを修正していましたが、故障を修正する方法を知っている必要がありましたが、今ではほとんどそれを行う必要はなく、ガレージに持って行くか、AAAに電話します。以前は自分で野菜を育てて自分で料理を作っていましたが、今ではマクドナルドとテレビディナーになっています。
個人的には、最終的にはプログラマーがプログラミングし、ユーザーが使用すると思います。奇妙な愛好家はアマチュアプログラマーになりますが、現実の世界と同じように、彼らが使用するツールは、専門家が使用するものと実質的に同じです。ナットとボルトの一部しか処理できない「ドメイン固有のツール」を使用して自分の車を作成しようとしたり、ナイフや高温の表面がない「安全で使いやすい」キッチンで夕食を作ったりすることを想像してみてください。誤って使用すると多くの損傷が発生します。
あなたの質問への答えはブートストラップです。まず、非常にシンプルで柔軟性があり、拡張可能な言語を設計します。 （動的言語はうまく機能します。）あなたはそれを実装します。次に、その言語で、必要な言語が得られるまでその言語の拡張機能を記述します。次に、アプリケーション自体をその言語で記述します。完了したら、最初に使用した言語を公開します。
すべてがその言語で書かれており、拡張機能は実行時に利用できるため、アプリケーションに対してやりたいことは何でもできます（賢明でないことも含む）。
たとえば、emacsがeLispでどのように記述されているかをご覧ください。またはSmalltalkを見てください。またはスキーム。
それが原則です。詳細は非常に複雑になる傾向があります。したがって、これがうまくいくと思われるコードを研究することを強くお勧めします。そして、LISPでのような本を読んでください。適切な種類の再帰的にねじれた心を持っている場合、最終的にはこの原則に基づいて独自のシステムを構築できるようになります。 （しかし、何がそれをクールにするのかを誰かに説明する幸運...）