ビジネスで理解できる DSL

DSL を使用すると、ビジネス担当者もプログラマーを介さずにソフトウェアのルールを記述できますか?

DSL について話題になると、ビジネス担当者が自分でコードを記述することがよく話題になります。私はこの考えに COBOL 推論を適用するのが好きです。つまり、COBOL の当初の目的の一つはプログラマーなしでソフトウェアを記述できるようにすることであり、その結果がどうなったかを知っています。そのため、プログラマーなしでコードを記述するスキームが考案されると常に、COBOL（および他の多くのもの）が失敗した中で今回なぜうまくいくのか、そこに特別な点があるのか疑問に思います。

私は、プログラミングには特別な思考様式、つまり機械に正確な指示を与え、大量のそのような指示を構造化して理解可能なプログラムを作成する能力が必要だと思います。そのような才能と、プログラムを理解して構築するために必要な時間は、長い間プログラミングが仲介されないでいた理由です。また、多くの「非プログラミング」環境が最終的に独自の事実上のプログラマーを生み出す理由でもあります。

ただし、DSL の最大の潜在的な利点は、ビジネス担当者が DSL コードの記述に直接関与する場合に得られると思います。しかし、肝心なのは DSL をビジネスで「記述可能」にするのではなく、ビジネスで「読解可能」にすることです。ビジネス担当者が DSL コードを見て理解できれば、ソフトウェア開発と基盤となるドメインとの間に深く豊かなコミュニケーションチャネルを構築できます。これはソフトウェアの「Yawning Crevasse of Doom」であるため、DSL は対処に役立つ可能性がある場合は優れた価値があります。

ビジネスで読解可能な DSL では、プログラマーがコードを記述しますが、そのコードを意味を理解できるビジネス担当者に頻繁に示します。次に、これらの顧客は変更を加えたり、コードの一部をドラフトしたりできますが、それを堅牢にし、デバッグおよびテストを行うのはプログラマーです。

これは、ビジネスで記述可能な DSL に利点がないという意味ではありません。実際、数年前、私の同僚がまさにそれを含んだシステムを構築しましたが、ビジネス担当者から高く評価されました。気の利いた編集環境、有意義なエラーメッセージ、デバッグおよびテストツールを作成する努力は、コストを大幅に上昇させるだけです。

COBOL 推論を使用して、プログラマーを回避しようとする多くのツールをすぐに批判しますが、スプレッドシートという重大な例外を認めざるを得ません。世界中で、驚くほど大規模なビジネス機能が Excel を基盤として実行されています。真面目なプログラマーはこれらの機能を軽視する傾向がありますが、それらをより真剣に受け止め、これほど成功した理由を理解する必要があります。これは、多くの LanguageWorkbench 開発者がソフトウェア開発の別のビジョンを提供する原動力の一部であることは間違いありません。