言語ワークベンチ：ドメイン固有言語のキラーアプリ？

言語指向プログラミングの簡単な例

まず、言語指向プログラミングの非常に簡単な例と、それに至る状況の種類から始めます。ファイルを読み取り、これらのファイルに基づいてオブジェクトを作成する必要があるシステムがあると想像してください。ファイル形式は、1行あたり1つのオブジェクトです。各行は異なるクラスにマップでき、クラスは行の先頭にある4文字のコードで示されます。行の残りの部分には、クラスのフィールドのデータが含まれており、これらは対象のクラスによって異なります。フィールドは、区切り文字ではなく位置によって示されます。したがって、顧客ID番号は4〜8文字になる可能性があります。

以下にいくつかのサンプルデータを示します

#123456789012345678901234567890123456789012345678901234567890
SVCLFOWLER         10101MS0120050313.........................
SVCLHOHPE          10201DX0320050315........................
SVCLTWO           x10301MRP220050329..............................
USGE10301TWO          x50214..7050329...............................

ドットは、つまらないデータのいくつかを示しています。上部のコメント行は、文字位置を確認するのに役立ちます。最初の4文字は、データの種類を示します。SVCLはサービスコールを示し、USGEは使用状況の記録を示します。その後の文字は、オブジェクトのデータを表します。したがって、サービスコールの5〜18文字は、顧客の名前を示します。

これらをオブジェクトに変換するには、それぞれの場合に特定のコードを作成したくなるかもしれませんが、数回実行すると、各クラスのフィールドの詳細を使用してパラメーター化できる単一のリーダークラスを作成してタスクを簡略化したいと思うでしょう。

ここに、これを行う簡単なクラスがあります。リーダーはファイルを読み取ります。リーダーは、ターゲットクラスごとに1つずつ、リーダー戦略クラスのコレクションを使用してパラメーター化できます。したがって、この例では、サービスコールに1つの戦略、使用状況に別の戦略があるでしょう。コードでキー設定されたマップに戦略を保持します。

ファイルを処理するコードは次のとおりです

class Reader...

  public IList Process(StreamReader input) {
    IList result = new ArrayList();
    string line;
    while ((line = input.ReadLine()) != null)
      ProcessLine(line, result);
    return result;
  }

  private void ProcessLine(string line, IList result) {
    if (isBlank(line)) return;
    if (isComment(line)) return;
    string typeCode = GetTypeCode(line);
    IReaderStrategy strategy = (IReaderStrategy)_strategies[typeCode];
    if (null == strategy) 
      throw new Exception("Unable to find strategy");
    result.Add(strategy.Process(line));
  }
  private static bool isComment(string line) {
    return line[0] == '#';
  }
  private static bool isBlank(string line) {
    return line == "";
  }
  private string GetTypeCode(string line) {
    return line.Substring(0,4);
  }
  IDictionary _strategies = new Hashtable();
  public void AddStrategy(IReaderStrategy arg) {
    _strategies[arg.Code] = arg;
  }

行をループ処理し、どの戦略を呼び出すかを判断するのに十分な情報を読み取り、次に戦略に処理を渡します。リーダーにジョブを実行させるには、新しいリーダーを作成し、戦略をロードして、処理するファイルで実行させます。

戦略もパラメーター化できます。1つの戦略クラスだけが必要であり、インスタンス化すると、コード、ターゲットクラス、および入力のどの文字位置がターゲットクラスのどのフィールドにマップされるかの詳細でパラメーター化できます。後者をフィールドエクストラクタークラスのリストに保持します。

class ReaderStrategy...

  private string _code;
  private Type _target;
  private IList extractors = new ArrayList();
  public ReaderStrategy(string code, Type target) {
    _code = code;
    this._target = target;
  }
  public string Code {
    get { return _code; }
  }

インスタンス化したら、戦略にフィールドエクストラクターを追加できます。

class ReaderStrategy...

  public void AddFieldExtractor(int begin, int end, string target) {
    if (!targetPropertyNames().Contains(target)) 
      throw new NoFieldInTargetException(target, _target.FullName);
    extractors.Add(new FieldExtractor(begin, end, target));
  }
  private IList targetPropertyNames() {
    IList result = new ArrayList();
    foreach (PropertyInfo p in _target.GetProperties())
      result.Add(p.Name);
    return result;
  }

行を処理するために、戦略はターゲットクラスを作成し、エクストラクターを使用してフィールドデータを取得します。

class ReaderStrategy...

  public object Process(string line) {
    object result = Activator.CreateInstance(_target);
    foreach (FieldExtractor ex in extractors)
      ex.extractField(line, result);
    return result;
  }

エクストラクターは、行の適切なビットからデータを引き出し、リフレクションを使用して値をターゲットオブジェクトに配置します。

class FieldExtractor...

  private int _begin, _end;
  private string _targetPropertyName;
  public FieldExtractor(int begin, int end, string target) {
    _begin = begin;
    _end = end;
    _targetPropertyName = target;
  }
  public void extractField(string line, object targetObject) {
    string value = line.Substring(_begin, _end - _begin + 1);
    setValue(targetObject, value);
  }
  private void setValue(object targetObject, string value) {
    PropertyInfo prop = targetObject.GetType().GetProperty(_targetPropertyName);
    prop.SetValue(targetObject, value, null);
  }

これまで説明したことは、この種の処理を行うための非常に単純なライブラリです。基本的に、具体的な作業を指定するために使用できる抽象化を構築しました。抽象化を使用するには、戦略を構成してリーダーにロードする必要があります。次に、2つの例のケースの例を示します。

public void Configure(Reader target) {
  target.AddStrategy(ConfigureServiceCall());
  target.AddStrategy(ConfigureUsage());
}
private ReaderStrategy ConfigureServiceCall() {
  ReaderStrategy result = new ReaderStrategy("SVCL", typeof (ServiceCall));
  result.AddFieldExtractor(4, 18, "CustomerName");
  result.AddFieldExtractor(19, 23, "CustomerID");
  result.AddFieldExtractor(24, 27, "CallTypeCode");
  result.AddFieldExtractor(28, 35, "DateOfCallString");
  return result;
}
private ReaderStrategy ConfigureUsage() {
  ReaderStrategy result = new ReaderStrategy("USGE", typeof (Usage));
  result.AddFieldExtractor(4, 8, "CustomerID");
  result.AddFieldExtractor(9, 22, "CustomerName");
  result.AddFieldExtractor(30, 30, "Cycle");
  result.AddFieldExtractor(31, 36, "ReadDate");
  return result;
}

私はこれを2つの異なるスタイルのコードとして見ています。ReaderクラスとStrategyクラスは抽象化であり、この最後のビットのコードは構成です。これらの種類のライブラリクラスを構築するときは、抽象化と構成という2つの部分を考えると役立つことがよくあります。抽象化は、クラスライブラリ、フレームワーク、または単なる関数呼び出しのセットである場合があります。抽象化は多くのプロジェクトで再利用可能である可能性がありますが、必須ではありません。構成コードは、特定のものである傾向があります。かなりシンプルで、直接的なコードです。

構成は非常に単純で、抽象化よりも変更される可能性が高いため、一般的なアプローチは、それをさらに分離し、構成をC＃から完全に取り出すことです。現在の流行は、それをXMLファイルに入れることです。

<ReaderConfiguration>
  <Mapping Code = "SVCL" TargetClass = "dsl.ServiceCall">
    <Field name = "CustomerName" start = "4" end = "18"/>
    <Field name = "CustomerID" start = "19" end = "23"/>
    <Field name = "CallTypeCode" start = "24" end = "27"/>
    <Field name = "DateOfCallString" start = "28" end = "35"/>
  </Mapping>
  <Mapping Code = "USGE" TargetClass = "dsl.Usage">
    <Field name = "CustomerID" start = "4" end = "8"/>
    <Field name = "CustomerName" start = "9" end = "22"/>
    <Field name = "Cycle" start = "30" end = "30"/>
    <Field name = "ReadDate" start = "31" end = "36"/>
  </Mapping>
</ReaderConfiguration>

XMLには用途がありますが、正確に読みやすいとは言えません。カスタム構文を使用することで、何が起こっているのかをより簡単に把握できます。おそらくこのようなものです

mapping SVCL dsl.ServiceCall
  4-18: CustomerName
  19-23: CustomerID
  24-27 : CallTypeCode
  28-35 : DateOfCallString

mapping  USGE dsl.Usage
  4-8 : CustomerID
  9-22: CustomerName
  30-30: Cycle
  31-36: ReadDate
  

これで問題に慣れたので、私の助けなしに構文を読めるはずです。

この最後の例を見ると、ここにあるのは非常に小さなプログラミング言語、つまり、固定長のフィールドをクラスにマッピングする目的（のみ）に適した言語であることがわかります。これは、'リトル言語'というUnixの伝統の典型的な例です。これは、タスクのためのドメイン固有言語です。

この言語はドメイン固有言語であり、DSLの多くの特性を共有しています。第一に、非常に狭い目的にのみ適しています。これらの特定の固定長のレコードをクラスにマッピングする以外に何も実行できません。結果として、DSLは非常に単純です。制御構造やその他の機能はありません。チューリング完全でさえありません。この言語でアプリケーション全体を作成することはできません。できるのは、アプリケーションの小さな側面を記述することだけです。結果として、DSLは何かを行うために他の言語と組み合わせる必要があります。しかし、DSLの単純さは、編集と翻訳が簡単であることを意味します（DSLの長所と短所については後で詳しく説明します）。

ここで、XML表現をもう一度見てください。これはDSLですか？そうだと私は主張します。それはXML構文の中にありますが、それでもDSLです。実際、多くの点で前の例と同じDSLです。

これは、プログラミング言語の分野でよく見られる一般的な区別、つまり、抽象構文と具象構文の区別を紹介するのに良い機会です。言語の具象構文とは、表示される表現における構文のことです。XMLファイルとカスタム言語ファイルには、異なる具象構文があります。ただし、どちらも同じ基本構造を共有しています。つまり、複数のマッピングがあり、それぞれにコード、ターゲットクラス名、およびフィールドのセットがあります。この基本構造が抽象構文です。ほとんどの開発者はプログラミング言語の構文について考えるとき、この分離を行いませんが、DSLを使用する場合は重要です。これは2つの方法で考えることができます。1つの言語に2つの具象構文があると言うことも、同じ抽象構文を共有する2つの言語があると言うこともできます。

この例は、DSLにカスタムの具象構文を使用するのが良いか、それともXMLの具象構文を使用するのが良いかという設計上の問題提起となっています。XML構文は、利用可能なXMLツールが多数あるため、解析が容易な場合があります。ただし、このケースでは、カスタム構文の方が実際には簡単でした。少なくともこのケースでは、カスタム構文の方がはるかに読みやすいと私は主張します。しかし、この選択をどのように考えるかに関わらず、DSLに関する本質的なトレードオフは同じです。実際、XML構成ファイルはすべて、本質的にDSLであると主張することもできます。

さらに一歩戻って、C#の構成コードに戻りましょう。これはDSLなのでしょうか？

それを考えている間に、このコードを見てください。これは、この問題に対するDSLのように見えますか？

mapping('SVCL', ServiceCall) do
	extract 4..18, 'customer_name'
	extract 19..23, 'customer_ID'
	extract 24..27, 'call_type_code'
	extract 28..35, 'date_of_call_string'
end
mapping('USGE', Usage) do
	extract 9..22, 'customer_name'
	extract 4..8, 'customer_ID'
	extract 30..30, 'cycle'
	extract 31..36, 'read_date'
end

この2番目のコードは、C#のコードに関連しています。私の言語の好みをよく知っている人なら、最後の例が実際にはRubyコードであることに気づいたでしょう。実際、C#の例と全く同じ意味を持っています。Rubyのさまざまな機能（最小限に抑えられた構文、範囲のリテラル、柔軟なランタイム評価）により、カスタムDSLのように見えます。これは、ランタイム時にオブジェクトインスタンスのスコープ内で読み込んで評価できる完全な構成ファイルです。しかし、これは依然として純粋なRubyであり、フレームワークコードとは、C#の例のAddStrategyとAddFieldExtractorに対応するメソッド呼び出しmappingとextractを通じてやり取りします。

私は、C#とRubyの例の両方がDSLであると主張します。どちらの場合も、ホスト言語の機能のサブセットを使用し、XMLやカスタム構文と同じアイデアを捉えています。本質的に、私たちはDSLをホスト言語に埋め込み、ホスト言語のサブセットを抽象言語のカスタム構文として使用しています。これは、ある程度、他の何よりも態度に関わる問題です。私は、C#とRubyのコードを言語指向プログラミングの観点から見ています。しかし、これは長い伝統を持つ観点です。Lispプログラマーは、Lisp内でDSLを作成することを考えることがよくあります。これらの内部DSLのトレードオフは、外部DSLのトレードオフとは明らかに異なりますが、多くの類似点が残っています。（これらのトレードオフについても後で詳しく説明します。）

これでDSLの例を示したので、言語指向プログラミングをより適切に定義できます。言語指向プログラミングとは、複数のDSLを通じてシステムを記述することです。これは段階的なものであり、システムの一部の機能がDSLで表現されているシステムでは少しの言語指向プログラミングを使用できます。または、ほとんどの機能をDSLで表現し、多くの言語指向プログラミングを使用することもできます。言語指向プログラミングをどれだけ使用するかを測定することは困難です。特に、言語内のDSLを使用する場合はそうです。通常、再利用可能なコードと同様に、自分でDSLをいくつか記述し、他の場所から別のDSLを使用します。

言語指向プログラミングの伝統

私の例が示すように、言語指向プログラミングは新しいものではありません。人々はかなり前から言語指向プログラミングを行っています。したがって、言語ワークベンチが何をもたらすのかを見る前に、現在の言語指向プログラミングの現状を見てみる価値があります。

言語指向プログラミングには、いくつかのスタイルが存在します。ここでそれらをいくつか要約するのが良いでしょう。

言語指向プログラミングの長所と短所

これらのスタイルを振り返ると、さまざまな形式の言語指向プログラミングが非常に普及していることがわかります。大まかに一般化すると、それらを2つのより広範なスタイルに分けると便利だと感じます。外部DSLは、アプリケーションのメイン（ホスト）言語とは異なる言語で記述され、何らかの形式のコンパイラまたはインタープリターを使用して変換されます。Unixの小さな言語、アクティブデータモデル、XML構成ファイルはすべてこのカテゴリに分類されます。内部DSLは、ホスト言語自体をDSLに変えます。Lispの伝統がこの最良の例です。

私はこの記事のために外部/内部という用語を作成しました。私が有用だと感じる区別に対する明確な用語のペアがないためです。内部DSLは「埋め込みDSL」と呼ばれることもよくありますが、「埋め込み」という用語は、アプリケーションに埋め込まれた言語（Wordに埋め込まれたVBAなど、どちらかといえば外部DSLである）と混同されるため、避けてきました。ただし、DSLに関する他の記事を調べると、埋め込みという用語に遭遇する可能性があります。

外部DSLと内部DSLのトレードオフはかなり異なるため、個別に検討するのが最善です。

今日の言語ワークベンチ

まず最初に、この言語ワークベンチのカテゴリーに当てはまるツールについて、いくつか簡単に触れておきます。これらのツールはすべて開発の初期段階にあることを覚えておいてください。大規模なソフトウェア開発に利用できる言語ワークベンチが登場するには、まだ数年かかるでしょう。

言語ワークベンチの要素

これらのツールはすべて異なりますが、いくつかの共通の特徴と類似した部分を共有しています。

言語ワークベンチの最も強力な特性の1つは、プログラムの編集とコンパイルの関係を変えることです。本質的に、テキストファイルの編集からプログラムの抽象表現の編集へと移行します。この最後の文を説明するために、いくつか段落を費やしましょう。

従来のプログラミングでは、テキストファイル上のテキストエディターを使用してプログラムのテキストを編集します。次に、そのファイルを、コンピュータが理解して実行できるものに変換するトランスレータを実行して、実行可能にします。その変換は、PythonやRubyのようなスクリプト言語のように実行時に行われることもあれば、Java、C#、Cのようなコンパイル言語のように別々のステップとして行われることもあります。

図1：従来のコンパイルの概要。

このプロセスを少し分解してみましょう。図1は、コンパイルプロセスを簡略化したものです。foo.csを実行可能なものにするには、コンパイラを実行します。この議論のために、コンパイルプロセスを2つのステップに分解することができます。最初のステップでは、ファイルfoo.csからテキストを取得し、抽象構文木（AST）に解析します。2番目のステップでは、この木をたどり、アセンブリ（exeファイル）に入れるCLRバイトコードを生成します。

プログラムには、コンパイラが表現の間で変換を行う多くの表現があると考えられます。ソースファイルは編集可能な表現です。つまり、プログラムを変更したいときに操作する表現です。また、ストレージ表現でもあります。これは、ソースコード管理に保持され、プログラムに再度アクセスしたい場合に使用されます。コンパイラを実行すると、最初のフェーズでは編集可能な表現が抽象表現（抽象構文木）にマッピングされ、次にコードジェネレーターがそれを実行可能な表現（CLRバイトコード）に変換します。

（実行可能コードになるまでには、実行可能コードに対してさらに多くの変換が行われます。しかし、バイトコードを手に入れた時点でコンパイラの作業は完了し、残りはすべてコンパイラの範囲外の後の段階で行われます。）

抽象表現は非常に一時的なものであり、コンパイラが実行されている間のみ存在し、コンパイルを2つの論理ステップに分離する役割を果たすだけです。この一時性は、もちろん、外部DSL間でシンボリック統合を行うのが非常に難しい理由の大部分を占めています。各言語は別々のコンパイルを通過するため、抽象表現間のリンクはありません。重要な抽象化が失われた時点で、生成されたコードで初めて物事がまとまります。

より洗練されたIntelliJ以降のIDEは、このモデルに大きな変化をもたらします。IDEがファイルをロードすると、ファイル編集を支援するために、インメモリに抽象表現が作成されます。（Smalltalkもこの限定版を行っていました。）この抽象表現は、メソッド名の補完のような単純なものから、リファクタリングのような洗練されたものまでを支援します（自動リファクタリングは抽象表現に対する変換です）。

私の同僚であるMatt Foemmelは、IntelliJで作業中にこのことがどのように彼を襲ったかを語っています。彼はこれらの機能によって強力に支援された変更を行い、突然、テキストを入力しているのではなく、抽象表現に対してコマンドを実行していることに気づきました。IDEは、抽象表現でのこれらの変更をテキストに変換しましたが、実際に操作していたのは抽象表現でした。最新のIDEで作業中に同じような感覚を味わったことがあるなら、言語ワークベンチが何をするのかがわかるでしょう。

図2：言語ワークベンチによる表現の操作。

図2は、言語ワークベンチでこのプロセスがどのように機能するかを示しています。ここでの重要な違いは、「ソース」が編集可能なテキストファイルではなくなったことです。操作する主要なソースは、抽象表現自体です。編集するために、言語ワークベンチは抽象表現を何らかの形式の編集可能な表現に投影します。しかし、この編集可能な表現は純粋に一時的なものであり、人間の助けとなるためだけに存在します。真のソースは、永続的な抽象表現です。

編集可能な表現が抽象表現の単なる投影であるという事実は、いくつかのポイントにつながります。おそらく最も重要なのは、編集可能な表現が完全である必要がないということです。つまり、目の前のタスクにとって重要でない場合は、抽象表現の一部の側面が欠落している可能性があります。さらに、複数の投影を持つことができ、それぞれが抽象表現の異なる側面を示しています。投影は言語ワークベンチ内にあるため、編集可能な表現はテキストファイルよりもはるかにアクティブです。この投影エディターは言語自体と密接に結びついています。その結果、編集可能な表現について考える際には、エディターがどのようにそれらと連携するかを積極的に考えます。これにより、テキストのような純粋に受動的な編集可能な表現から得られるものとは異なるアイデアが得られます。

言語ワークベンチは、ストレージ表現と編集可能な表現を分離します。ストレージ表現は、抽象表現のシリアライズになりました。これを行う一般的な方法はXMLですが、このXMLは人間が編集するように設計されていません。ストレージ表現としてXMLを持つことは、ツールの相互運用性に役立ちますが、そのような相互運用性は非常に難しい可能性があります。

コード生成はほぼ同じですが、このようなツールは従来のソースを実行可能な表現として扱う傾向があります。通常の言語ソースファイルを生成する場合は、これらのファイルは実際にはソースではなく、他の生成されたコードと同様に直接編集しないでください。言語ワークベンチが成熟するにつれて、バイトコードのような編集不可能な構造の生成への依存度が高まるはずです。

言語ワークベンチにおいて、自明ではない重要な機能の一つは、抽象表現がエラーや曖昧さに対応できる必要があるということです。従来、抽象表現を持つのであれば、それを正しく保つ必要があり、誤った情報を入れるべきではないと考えられてきました。しかし、この前提は使い勝手の悪さにつながりました。IntelliJ以降のIDEはこれを認識し、エラー状態にうまく対応しています。例えば、コンパイルエラーがあるプログラムでもリファクタリングを実行できます（これは使いやすさのために非常に重要です）。

複数のソースから複雑な情報を取得したい場合は、さらに重要になります。すべてを常に一貫して正しく保つことはできません。そのため、曖昧でエラーのある状態に対処し、入力を拒否するのではなくエラーを強調表示する必要があります。また、計算不能な情報（ドキュメントなど）をモデルに簡単に入力できるようにする必要があります。これにより、スキャンしたメモ書きを結果のDSLコードに直接リンクできます。

言語ワークベンチの定義

言語ワークベンチを構成する要素についての一般的に受け入れられている定義はありません。この記事のために私がこの用語を作ったばかりなので、驚くことではありません！しかし、ソフトウェア業界の多くのトピック（例：コンポーネント、サービス指向アーキテクチャ）を取り巻く蔓延する曖昧さを回避するために、言語ワークベンチの本質的な特性について最初に試してみるべきだと感じています。必要な背景を提供したので、簡単に述べることができます。

• ユーザーは、相互に完全に統合された新しい言語を自由に定義できます。
• 情報の主要なソースは、永続的な抽象表現です。
• 言語設計者は、DSLをスキーマ、エディター（複数可）、およびジェネレーター（複数可）の3つの主要な部分で定義します。
• 言語ユーザーは、投影型エディターを通じてDSLを操作します。
• 言語ワークベンチは、不完全または矛盾する情報を抽象表現に永続化できます。

言語ワークベンチが言語指向プログラミングのトレードオフをどのように変えるか。

少し前に、言語指向プログラミングのトレードオフについて議論しました。言語ワークベンチは、考慮すべき多くの新しい要素とともに、そのトレードオフに明らかに影響を与えます。

言語ワークベンチが方程式にもたらす最も明白な変化は、外部DSLの作成の容易さです。パーサーを作成する必要はもうありません。抽象構文を定義する必要がありますが、それは実際には非常に簡単なデータモデリングのステップです。さらに、DSLには強力なIDEが与えられます。ただし、エディターの定義にはある程度の時間が必要です。ジェネレーターは依然として行う必要があるものであり、私の感覚では以前よりはそれほど簡単ではありません。しかし、優れたシンプルなDSLのジェネレーターを構築することは、演習の中で最も簡単な部分の1つです。

言語ワークベンチの2つ目の大きな利点は、シンボリック統合が得られることです。Excelのような数式言語を取り入れて、それを独自の専門言語にプラグインできることは非常に便利です。また、1つの言語でシンボルを変更し、それらの変更をシステム全体に波及させることもできます。これは、言語ワークベンチでは考えられることです（まだそれを行うことができるものがあるかどうかはわかりません）。

リファクタリングの問題は、言語ワークベンチにおける大きな問題の1つです。言語ワークベンチの使用を説明する際、「最初にDSLを定義し、次にそれを使用して何かを構築する」という罠に陥りやすいです。過去に私が書いたものを読んだことがあるなら、その概念は多くの警鐘を鳴らすはずです。私は進化的なデザインの大ファンです。この文脈では、DSLとDSLで構築されたコードを一緒に進化させることができる必要があることを意味します。それは難しい問題ですが、Intentionalの開発の初期段階から認識されていました。成熟した言語ワークベンチでDSLをその使用と並行して進化させることがどれほどうまくいくかはまだわかりませんが、この機能の欠如はそれらに対する大きなマイナスになるでしょう。

私が言語ワークベンチで見ている最大の短期的な問題は、ベンダーロックインのリスクです。スキーマ、エディター、およびジェネレーターの3つを定義するための標準はありません。言語ワークベンチで言語を定義すると、その言語ワークベンチに縛られます。異なる言語ワークベンチ間のインターチェンジの標準はありません。言語ワークベンチを変更したい場合は、3つを再実装する必要があります。時間が経つにつれて、DSLをインターチェンジするために設計された特別なストレージ表現、つまりインターチェンジ表現が見られる可能性があります。しかし、ここで堅牢な話が現れない限り、ベンダーロックインは依然として大きなリスクです。（MDAはこれに対する答えを提供すると主張していますが、せいぜい部分的です。）

これに対する緩和策の1つは、言語ワークベンチをソースの生成を支援するツールと見なすことです。この例としては、言語ワークベンチを使用して、すべてのJava XML構成ファイルを管理下に置くことです。最悪の事態が発生し、言語ワークベンチを放棄する必要がある場合でも、生成された構成ファイルは残っています。生成されたファイルの見栄えに注意を払えば、自分で書くよりも悪くなることはないかもしれません。より深い機能についても、構造化されたJavaコードを生成できます。これによりリスクはある程度軽減されますが、少なくとも完全に途方に暮れることはありません。ただし、ベンダーロックインは依然として考慮すべきことです。

ツールに関するこの問題は、ソースとしてテキストファイルから離れることの結果の1つです。他の問題が発生します。テキストでは解決できたが、抽象表現の中心的な役割で再考する必要がある問題です。リストの最上位にあるのは、バージョン管理です。テキストソースに対して、優れたdiffおよびマージ機能を備えた効果的なバージョン管理を行う方法を知っています。効果的な言語ワークベンチでは、抽象表現自体のdiffとマージを提供できる必要があります。理論的にはこれは解決可能であり、真のセマンティックdiffの機会を開きます（シンボルの名前変更が、テキストで行うようにその結果から推測する必要があるだけではなく、その行為として理解される場合）。Intentionalはここで良い解決策を持っているように見えますが、まだ実際に試していません。

ポジティブな点に戻ると、カスタム言語とエディターの組み合わせにより、DSLをプログラマー以外の人も編集できるようになるかもしれません。さらに、シンボリック統合により、ユーザーコードとコアプログラムの同期が取れなくなるという問題が解消されます。エディターの使用は、COBOL推論を打破するのに役立つ最大のツールである可能性があります。つまり、ツールがユーザーインタラクション用にカスタマイズされた環境を提供することです。

ドメインエキスパートを開発作業に直接参加させるというこの約束は、おそらく言語ワークベンチの約束の中で最も魅力的な部分です。プログラマーが生産性を向上させるためにどのようなツールを使用しても、アイドルループを最適化しているという感覚があることが何度もわかります。私が訪問するほとんどのプロジェクトでは、最大の問題は開発者とビジネス間のコミュニケーションです。それがうまくいっていれば、二流の技術でも進歩することができます。その関係が壊れていれば、Smalltalkでも救うことはできません。

言語指向プログラミングの支持者のほとんどは、ドメインエキスパートをもっと関与させることについて話します。実際、秘書がLispの内部DSLで楽しそうにプログラミングしているという主張さえ聞いたことがあります。しかし、ほとんどの場合、これらの努力は本当にうまくいきませんでした。焦点を絞った外部DSLの利点と、洗練されたエディターおよび開発環境を組み合わせることで、この問題についに取り組み始めることができるかもしれません。もしそうなら、その見返りは莫大になるでしょう。実際、このユーザーの関与が、Charles Simonyiの仕事の主な原動力であり、Intentional Softwareのほとんどの決定を支えていることがどれほど重要であるかは驚くべきことです。

これらのツールの最大の短期的制限は成熟度です。これらのツールが開発者の最先端に到達するまでにはしばらく時間がかかるでしょう。しかし、ご存知のとおり、それはすぐに変わる可能性があります。10年前のツールや言語の選択を今と比較してみてください。

DSLの概念を変える

この記事で使用した例は、実際にはDSLの非常に面白くない例です。それらは、話しやすく構築しやすかったため使用しました。しかし、より複雑な合意DSLでさえ非常に慣例的です。それが従来のテキストDSLとしてどのように行われるかは簡単にわかります。多くの人はグラフィカルDSLの作成を考えていますが、これらでさえその可能性を十分に捉えているわけではありません。「言語」という用語を使用する上で最大の危険性は、言語ワークベンチで実際に何ができるかのポイントを見逃してしまう可能性があるということです。

OOPSLA 2004について同僚と話していたとき、最大の話題はJonathon EdwardsによるExample Centric Programmingのデモンストレーションでした。重要なアイデアは、プログラムコードだけでなく、そのコードでのサンプル実行の結果も示すエディターでした。私たちは抽象化を操作しますが、具体的なケースで考える方が簡単であることが多いという考えでした。例に傾倒することは、テスト駆動開発の魅力の大部分です。私はそれをSpecification by Exampleと呼んでいます。

エドワーズは、自身のアイデアをさらに発展させ、Subtextというツールを開発しました。Subtextは、言語ワークベンチのいくつかの原則、特にテキスト形式のソースコードからの脱却という考え方を共有しています。Subtextは、新しい言語を簡単に定義するという点ではそれほど興味深いものではありませんが、言語ワークベンチが言語とツールを深く絡み合ったものとして考えさせるようになるにつれて、どのような思考が発展する可能性があるのかを示す興味深い一例となります。

実際、これが言語ワークベンチがCOBOLの推論による悪影響を回避できる最も強力な理由かもしれません。以前に述べたように、私たちは常にユーザーをアマチュアプログラマーとして力を与える技術を生み出してきましたが、定期的に失敗しています。アマチュアプログラマーを効果的に成功させている技術の1つであるスプレッドシートを考えてみましょう。

ほとんどのプログラマーはスプレッドシートをプログラミング環境とは考えていません。しかし、多くのアマチュアプログラマーはそれらを使用して高度なシステムを作成しています。スプレッドシートは、アマチュアプログラミングツールに必要な特性を示唆する、魅力的なプログラミング環境です。

• 即時フィードバック - 計算例の結果をすぐに表示することを含みます。
• ツールと言語の深い統合
• テキスト形式のソースがない
• すべての情報を常に表示する必要がない - 数式はそれらを含むセルを編集するときにのみ表示され、それ以外の場合は値が表示されます。

スプレッドシートは非常にフラストレーションがたまるものでもあります。それらの構造の欠如は実験を促しますが、少し構造があれば特定の問題をより簡単に処理できると感じることがよくあります。

したがって、言語ワークベンチのDSLについて考えるとき、ここで示してきたような言語やモデラーに愛されるグラフィカル言語を考えるのではなく、次世代のスプレッドシートのようなものを考えるべきです。

結論

この記事を書いた主な目的は、言語ワークベンチの概要を紹介することでした。少なくとも、もしあなたのマネージャーがプログラミング環境全体をそれらに置き換えるように求めてきた場合に、それに対応できる程度には理解していただけたことを願っています。

私の見るところ、言語ワークベンチは2つの主な利点を提供します。1つは、より良いツールを開発者に提供することによって、プログラマーの生産性を向上させることです。もう1つは、ドメインエキスパートが開発ベースに直接貢献する機会を増やすことによって、ドメインエキスパートとのより密接な関係を築き、開発の生産性を向上させることです。これらの利点が実際に実現するかどうかは、時間が経てばわかるでしょう。2つを見ると、生産性の向上がより可能性が高いと思いますが、影響は少ないと思います。言語ワークベンチが開発とドメインエキスパートの関係に深刻な影響を与えれば、それは計り知れない効果をもたらす可能性がありますが、成功するためにはCOBOLの推論を克服する必要があります。

おそらく、私が気づいた最も興味深いことは、言語ワークベンチの経験を積んだ後、DSLがどのようなものになるのか、おそらくほとんど見当もつかないということです。これまでのところ、私の考えは、テキスト形式およびグラフィカルな言語がどのようなものであるかという考えに大きく制約されています。しかし、エディターとスキーマの相互作用は、ほとんどの人が外部DSLについて持っている考えとはまったく異なる可能性を切り開きます。言語ワークベンチが期待に応えることができれば、10年後には、私たちが今DSLはどうあるべきだと考えているかを振り返って笑うでしょう。

私が示唆したように、言語ワークベンチはまだ開発の非常に初期段階にあります。本格的にそれらを試すことができるようになるには、数年かかるでしょう。私は、それらがその支持者が期待するように、ソフトウェア開発の様相を変えるかどうかについて予測をするつもりはありません。私はテクノロジー未来学者ではありません。私が信じているのは、言語ワークベンチが私たちの視野の端にある最も興味深いアイデアの1つであるということです。もしそれらがその潜在能力を実現すれば、私たちの職業に間違いなく大きな影響を与えるでしょう。たとえそうでないとしても、私はそれらが多くの興味深いアイデアにつながると確信しています。

ですから、この分野に注目しておくことをお勧めします。それは興味深い分野であり、長年にわたって興味を持ち続けるのに十分な活気があります。私はここ数ヶ月でそれらをよく見て、これからも関心を持ち続けるつもりです。