これはよく起こります。アプリケーションが十分に広範になっているので、アプリケーションにプログラム可能性を追加して柔軟性を持たせるときが来ました。1つの例として、財務アプリケーションがあります。数式エディタを追加して、コードを再コンパイルせずに独自のカスタム数式を作成できるようにします。
選択する必要があります。独自のトークナイザー、パーサー、およびインタープリター/コンパイラーチェーンを作成しますか。これには時間がかかり、正しく行われない可能性がありますか？または、別のスクリプト言語を埋め込んだだけですか。コードが肥大化し、アプリがセキュリティの脆弱性にさらされる可能性があるという問題があります。
トレードオフのバランスをどのように取り、この決定を下しますか？
トレードオフはありません。十分にテストされ、十分に文書化されたインタプリタを埋め込みます。そうしないと、MAXScriptのような嫌悪感を覚えることになります。
プラグインシステムはどうですか？いくつかの利点があります。
パーサー/インタープリターが 1 つのページに収まるほど DSL が単純でない限り、既存のスクリプト言語を埋め込むことをお勧めします。
私は最近、完全に自家製のスクリプト言語を含む、継承したプロジェクトに数か月を費やしました。バグを修正し、スレッドセーフにし、拡張し、最適化できるように、パーサーとインタープリターを理解することに多くの時間を費やしました。さらに、この新しいスクリプト言語の癖を学び、理解する時間もありました。この新しいスクリプト言語は、私がすでに知っている他のスクリプト言語とほとんど同じではありませんが、目を覚ましました。その時間を、Ruby や Lua などの既存の言語を組み込み、ニーズに合わせて調整することに使用したかったのです。
ユーザーは、プログラミングが簡単で、癖や落とし穴が少ない言語の恩恵を受けていたでしょう。「myScript」で比較的価値のない専門知識を得る代わりに、適切に設計された人気のある言語の内部をより深く理解することで恩恵を受けたでしょう.
既存のパーサージェネレーター（ANTLRやHaskell / Scalaのパーサーコンビネーターなど）を使用して、独自のインタープリターを作成します。それはそれほど難しいことではなく、単純な言語の場合、それは本当に非常に簡単です。私は午後に悪魔のように単純なDSLの実装を作成しましたが、それは最初は完全に実行されました（バグはありません）。
そうは言っても、独自のチューリング完全言語を設計する必要はありません。ニーズがそれほど洗練されている場合は、おそらくスクリプト言語を埋め込む必要があります。JVMを使用している場合、JRubyとClojureは、特に内部DSLの分野での独自の強みを考えると、この種のものの優れた候補です。