最強の設定記述言語はすでにある
これはユーザー・設定ファイルを記述する人向けの視点ではなく、主に設定ファイルの書き方を選ぶ・作る人向けの視点の記事です。
「設定」を記述するための書き方はこれまでさまざまなものが提案されてきました。たとえばパッケージのメタデータを宣言するための JSON や TOML、クラウドの構成のテンプレートを書くための YAML、サーバーの細かい設定やルーティングを扱うための独自言語などです。今日もまた新たに新しい書き方が提案されているかもしれません。
このように「設定」を記述するための書き方が氾濫するのはなぜでしょうか？
私なりの考えとしては「それぞれが必要とするもっともシンプルで平易な書き方を求めるから」だと思います。つまり ON/OFF の一覧があれば良いものはフラグのリストのみを書かせ複雑な文法は必要ありませんし、再利用や拡張性を必要とするものはプログラミング言語に近いものを必要とします。
「設定」を記述するための書き方はシンプルさと柔軟さのトレードオフがあり、そのために多様な書き方が提案されていると考えられます。
このような一側面だけを切り取った見方は早計かもしれませんが、私にはさまざまな書き方がそのようなトレードオフの中で戸惑った結果のように見えてしまいます。私はこのトレードオフの間のバランスが適切であることはそれほど重要でないと考えており、最適を考えるあまり新たな書き方を覚えさせられることの方が負担に感じてしまいます。
このトレードオフの間の最適解を選ぶのが難しい結果、さまざまな書き方を試すしかないという問題に解決方法はないのでしょうか？私はそうではないと考えています。
最適解を選ぶのが難しいのは解決できないと思いますが、トレードオフの間で揺れるたびに新しい書き方を考える必要はないと思います。というのは JSON を JavaScript の中から「発見」したように、シンプルな設定記述言語を既存のプログラミング言語の中から「発見」すれば良いからです。
既存の汎用プログラミング言語はおそらく人類が持っているもっとも柔軟な書き方ができる設定記述言語です。柔軟さを求めていくとおそらくここに近づいていきます。そこをトレードオフの片方の端とし、もう片方をそのプログラミング言語のサブセット言語とし、その間でバランスを取ることができれば、新たな書き方を覚える必要はないのではないかと考えています。ユーザーはそのプログラミング言語をすでに知っているので新たな書き方を覚える必要がないか、新たに覚えるとしてもどこかで使うかもしれないプログラミング言語を覚えているのでモチベーション高く取り組めます。
一例としては JavaScript と JSON です。JavaScript は JSON のサブセット言語であり、JSON は JavaScript の一部です。JSON の柔軟さに物足りなくなれば JavaScript の言語仕様の一部を取り入れて拡張した言語を作れば良いのです。JSON にコメント機能がほしければ JavaScript から取り入れれば良いのです。
幸いにも JSON, JavaScript, TypeScript はそれぞれ十分な普及率を持っています。これらの関係はまさに私が考える最適解の 1 つです。JSON は JavaScript の、JavaScript は TypeScript のサブセットです。JSON の柔軟さで物足りなくなれば (YAML にするのではなく) JavaScript の一部の言語仕様を取り入れた設定言語を作れば良いのです。
TypeScript に拘りませんが、既存の汎用プログラミング言語とそのサブセットで設定記述言語を作るというアプローチが良いやり方だと考えています。
おそらくこのような考え方と似た発想で作れられたのが Dhall ではないかと考えます。
余談ですが私は最近この考え方が根底にある OpenAPI Code というツールを作りました。
新たな設定ファイルの書き方を選ぶ・作る際は既存の汎用プログラミング言語のサブセットを使うべきです。言語仕様はそのままに使うのであれば Configuration as Code と言えるのでしょうが、制限する場合は JSON のようなサブセットを定義します。いずれにしろバランスはサブセットの中から選ぶべきです。
ユーザーは新たに書き方を覚える必要はありません。最強の設定記述言語はすでにあるのです。
Discussion