WIP:Clojure のデータ駆動のメリット
動機
データ駆動のメリットについてを理解するのに、下記を紹介いただいた
Google 翻訳にブチ込んでみるもよく分からなかったので、言語化して整理をしたい
翻訳でもないし、正確でもないです。
データ駆動のメリット
可用性、透明性、扱いやすさ
マクロ
実行時に扱えない。つまり可用性が低い。
展開されてしまうと、どこからがマクロによるものなのか分からなくなる。見通せなくなるためマクロは不透明である。
マクロを書くのは大変だ。なぜなら
コンパイル時と実行時の2つのフェーズを分離します。
それらの違いを意識して追跡する必要がある。
デバックしやすさのことを言ってるのだろうか?
関数
実行時に扱えるが、操作できるのは呼び出しのみ。例えば、閉包には
中身はブラックボックスで不透明。
A function, too, is opaque in its way. A function, at runtime, is a black box. What does it do? You can’t tell. You can’t even tell how the function got there. Was it a fn defined in code? Or was it the result of function composition using comp? That information is not available at runtime.
ここ意味わからんかった
どう到達したか?スタックトレースのこと?スタックトレースを利用するのはどうなん?
fn でも定義されようと comp で定義されようとどっちでもいい気がする
デバックしやすさのことを言ってるのだろうか?
データ
コンパイル時でも実行時でも使える。
ブラックボックスは何もなく透明。見たままである。
データを操作するための便利な機能が豊富にあり扱いやすい
どう駆動するかを宣言的に書くだけなので、それをどう実装するかは自由に作れる
データが意味体系になっている
予想される反論
データであるコードを使えば良いのでは?
確かに Homoiconicity は素晴らしいがケースバイケースである。
一定の形式に沿ったデータによる表現では、多くの場合できることが減る(チューリング完全でなくなる) が、それがメリットでもある。
「なんでもできる」は「扱いきれない 」に繋がる
制限することで扱いやすくなることは普遍的なこと
データの意味付けは曖昧だが、コードの意味付けは明確だ。コード使った方が良くない?
しかしコードには文書化されていないエラーメッセージ、不適切なケース、マップの特定のキー必要など、あらゆる種類の仮定が存在している。
コードにしても意味付けは明確にならないと言っている?
うーん、透明でない(暗黙的な前提がある)ことの説明であって、意味付けに対する解答になっていないような?
Haskell をしっかり使うと例に上げられたら暗黙の前提が全部防げるな……すげぇ。
Hasn’t this discussion happened many times before? I mean, Ant started off ok, but then it was its own programming language and it sucked.
さっぱり分からん。Ant が何を指してるのか分からん。Ant がビルドツールなのは分かったけど、 そうじゃないだろう。Java界では代表的な内部DSLを使ったツールだったりするのだろうか?
内部DSLと外部DSL。そして外部DSLは失われる。 さっぱり分からん
最初からデータ駆動にするんじゃなくて、関数とかマクロとかで完成させてから、リファクタリングでデータ駆動にするのが俺のガイドライン???さっぱり分からん。
結論
多くの場合、データはストレートコードよりも冗長でエラーが発生しやすいです。
しかし、データが非常に優れているスイートスポットがあります。そのような場合、
コードが読みやすくなります。
分析に適しています。
ワイヤーを介して渡すことができます。
ワイヤーを介して渡すってなんだー!わからん
ドチャクソ分かりやすいです!ありがとうございます!
データ駆動がキマってるライブラリを紹介いただいた。ありがとうございます! ルーティングの bidi
クエリビルダーの Honey SQL
ORMより作りも使い方もシンプルそう。すごそう。