DSL(ドメイン固有言語、ドメイン特化言語)と闇と

以前、 [twitter:@sue445] さんから頂いたドメイン特化言語を読んでもやっとしました。

ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目

ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目

DSLドメイン固有言語とか、ドメイン特化言語とか翻訳されていて、特定の業務領域を特殊な言語で記述して作りやすくしよ〜ぐらいの感じのものです。
DSLの詳しい内容としてはWikipediaでも見ていただくとして、上記の本ではDSLいいよー、最高だよーみたいな内容から始まっていました。
その後、DSLの具体例が多々載っていたのですが、昔、多数の有名企業がこぞってPRしていたとあるDSLについての記載がありませんでした。
現在ではDSLの最大の失敗例として知られるBPELについて書きたいと思います。

BPELとは

BPELはBusiness Process Expression Languageの略で、ビジネスプロセスを記述することに特化した言語として作成されました。
ビジネスプロセスという特定領域の問題を解決するために作成された言語ということで、DSLとみなすことが出来ます。
BPELは以下の様な特徴を持っていました。*1

  • だれでも簡単に記述ができるようにXMLでフローを定義することが出来る
  • 外部との連携はSOAPを使用し、疎結合なシステムを開発することが出来る
  • チューリング完全であり、事実上どのようなビジネスプロセスでも定義することが出来る

夢の様な言語として扱われ、一時期多数の製品群が発表され、実際に使われていました。
その名残はgoogleで検索することで見ることが出来ます。

しかし、使われなくなりました。
以下の様な問題があったからです。

  • ビジネスプロセスは千差万別であり、ビジネスフローの記述量が大量に必要だった。ビジネスプロセスというのが特定の領域としては広すぎた
  • XMLでの記述方法が冗長すぎて、単純にJavaソースコードXMLに書き換えただけのようになっていた
  • DSLから実際の処理を行うまでの変換コストが高すぎて、スループットが低くなってしまった

と、こんな感じでの、DSLの失敗例でした。
これにより、DSLを作るときには以下のような点に気をつける必要があると考えます。

  • 再利用は考えない。再利用が必要な時点で、ドメイン特化言語を作る必要があるのかを一度考えるべき。
  • 使うときの記述量は適度に減らすようにする。
  • 汎用言語への変換*2が発生するため、その分パフォーマンスが落ちることは事前に検討するべき。耐え切れない場合はDSL自体をチューニングする必要がある事を頭の隅に置いておく。DSLを一度作ったらあとは使うだけというわけではない。

という感じで。
DSL自体は良い思想で私もよく作るのですが、「DSLが良い!どんどん作っていこう」と言って、BPELを知らないまま汎用DSLとか考え始める人が居るのではないかと非常に心配しています。
汎用、と名前を付けた時点でDSLであるわけがないのですが、歴史が繰り返されそうな気がするのが怖い。

*1:正確にはBPELとその処理プロセッサー

*2:直接バイナリになることもありますが