博士

やあ、ロボ子。最近、データエンジニアリングの世界でSQLやYAMLの設定ファイルにJinjaみたいなテンプレート言語を使いすぎて、コードがぐちゃぐちゃになっているらしいのじゃ。

ロボ子

あら、博士。それは大変ですね。データエンジニアの皆さんが、ソフトウェアエンジニアのようなAIコーディング支援ツールの恩恵を受けられていないという問題もあるみたいですよ。

博士

そうなんじゃ。データエンジニアリングは状態を持つシステムを扱うから、設定やオーケストレーション、データパイプラインといった運用作業にコードが使われるのが原因みたいじゃな。

ロボ子

設定言語の表現力の限界を補うためにテンプレート言語が導入されることが多いみたいですが、それがコードベースを複雑化させているんですね。

博士

まさにそう言うことじゃ。設定言語にコンポーザビリティ（組み合わせ可能性）がないと、テンプレート言語がどうしても必要悪として登場してしまうんじゃ。

ロボ子

解決策としては、設定やクエリ言語を最初から強力にして、テンプレート層を不要にすることが考えられるみたいですね。でも、ランタイムでの述語評価は必要みたいですが。

博士

その通りじゃ。アーキテクチャの境界線を明確にすることも重要じゃな。それと、悪いテンプレートパターンをチェックするリンターを導入するのも有効じゃ。

ロボ子

Reactの例が参考になりますね。JSXでUIの構造を宣言的に記述し、JavaScriptでロジックを実装することで、UI記述とアプリケーションロジックを分離した、と。

博士

そうじゃ、そうじゃ。jQueryの時代はDOMクエリと状態更新がコード全体に散らばっていたけど、Reactはその問題を解決したんじゃ。

ロボ子

データエンジニアリングに適用するなら、計算層（プログラミング言語を使用）と宣言層（宣言的言語を使用）を分離するのが良いみたいですね。

博士

SQLの構造内に条件ロジックや文字列連結を書く代わりに、Pythonなどのプログラミング言語でロジックを書いて、その結果をSQLクエリに渡す、と。

ロボ子

Malloyを使って、Pythonで計算を行い、Malloyで構造を宣言する、という例もありますね。

博士

テンプレート言語の蔓延は、介入が遅すぎることが原因じゃ。計算を宣言層内で行うことを避けて、適切なツールを使えば、ソフトウェアの柔軟性が高まって、AIがコードを扱いやすくなるんじゃ。

ロボ子

宣言型パラダイムの可能性を最大限に引き出せる、と。

博士

そういうことじゃ！…ところでロボ子、もしデータエンジニアリングの世界がテーマパークだったら、一番人気のアトラクションは何だと思う？

ロボ子

うーん、そうですね…やはり、ビッグデータ・マウンテン、でしょうか？

博士

ブッブー！残念！正解は「ETLコースター」！データの流れに乗って、スリル満点の旅を楽しめるのじゃ！