フォームベースのRIAの代わりにDSLを作成するのはなぜですか？
最近、ドメイン固有言語（DSL）に関するいくつかの論文を読んでいますが、リッチインターネットアプリケーション（RIA）に対するDSLの利点を扱っている論文はありません。 RIAでは、ドメイン言語を学習する代わりに、ユーザーにフォームフィールドとしてドメインオブジェクトが提供されます。これにより、ドメイン言語の字句定義が抽象化されます。これはもっと使いやすいようです。私が欠けているものは何ですか？
これは、ドメインの複雑さに依存します。主に構造化データで構成されている場合、ビジュアルエディターの方が直感的に使用できますが、ドメインに大量のロジックが含まれている場合、ビジュアルエディターはそのためのツールとしては不十分であることが何度も経験されています。
さらに、文字ベースの言語では簡単な、非常に一般的で非常に便利なタスク（コピー＆ペースト、検索＆置換など）がいくつかありますが、ビジュアルエディターで実装するには多大な労力が必要であるため、多くの場合欠落しています。
フォームは、可能な式を1つのタイプのみに制限します。自然言語では、想像できることなら何でも英語で書くことができます。フォームで表現できるものははるかに限られています。たとえば、MadLibsを考えてみてください。
私は反対者であり、DSLはプログラマーにとってより自然で柔軟なインターフェースであり、プログラマーは自分たちが使いやすいシステムを作成することを好むため、不適切に推奨されることが多いことを指摘します。
つまり、DSLは、プログラマーやIT部門などの高度なトレーニングを受けた専門ユーザー向けに設計された機能に最適です。サイト固有の構成/カスタマイズ、スクリプトの自動化、または比較的頻繁に変更されないビジネスロジックなど。
DSLは中間表現としても役立ち、エンドユーザーに表示されない場合でも、プログラマーがよりコンパクトで適切な言語で上位層にコードを記述できるようにします。
DSLはテキストなので、テキストベースのツールを使用できます。最も注目すべきは、メタプログラミングを介してシェルスクリプトを使用してDSLのコードを生成できることです。他の人が言っているように、DSLはRIAを持つことも妨げません。
DSLを完全なプログラミング言語（Python、Ruby、Groovyなど）に埋め込む場合は、DSLを使用してタスクを自動化できます。
従来のプログラムよりもコンパクトに一連のステップを表現する「スクリプト」の必要性を想像できる場合は、DSLシステムを作成します。また、プログラマー以外の人が「現場で」構成できるようにしたいが、ユーザーが必要としそうなことを達成するために必要なすべての能力を備えている場合にも、DSLを作成します。明らかな例はHTMLです。
以前は、自動化されたタスクを実行するのに役立つスクリプト言語を作成することがよくありました（現在は古い例ですが）：WANでファイルをコピーおよび削除して、入力ファイルが分散され、出力ファイルが出力されるようにする収集して削除しました。ネットワーク上でファイルをコピーするように設計された言語と「ランナー」を作成しました。これは、Cで同様のプログラムを作成するよりもはるかに少ない労力とデバッグでした（これは25年前のことです）。