状態、型、抽象化についていろいろ

pokarim @pokarim

FRPの双方向性もRDBのVIewのUpdateも明らかに常にできるわけではないけれども、常に出来るわけではないから役に立たないわけではなくて、いつ出来ていつ出来ないのかをはっきりさせたり、ヒントを与えることを可能にしていく必要があるということ

m2ym @m2ym

状態とは何ぞやを問うてみる

m2ym @m2ym

正規化されていないDBの更新が難しいことと、状態の更新を明示的に記述するのがダメなことを、形式的に同じロジックに従うとすれば、状態とはつまり正規化されていない冗長な情報であると言うことができる

m2ym @m2ym

例えば、「私は立っている」と「私は座っている」は同時に状態に含み得るが、普通は矛盾しないように更新しなければならない。

m2ym @m2ym

上のような単純な例なら間違いなく更新できるだろうけど、より複雑な例では間違うこともある

m2ym @m2ym

人間の脳は変化に対して瞬時に反応するために状態を冗長に保存しているのだと思う。これはDBにおいて速度のために非正規化されるのと似ている

m2ym @m2ym

人間の脳は状態をなんとなく辻褄が合うように更新する。間違っていても後で訂正すればさほど問題はない。それより(不完全であっても)情報の利用可能性のほうが重要なのだろう。

m2ym @m2ym

一方、ソフトウェアにおいて、なんとなく辻褄が合う、という曖昧なものは基本的に存在せず、システムとして矛盾のないように状態遷移する必要がある

m2ym @m2ym

つまり、いわゆる「状態」というものは、実世界のメンタルモデルを強く反映した高利用可能性な情報、と言えると思う。

m2ym @m2ym

ここで考えている「状態」は状態マシンの「状態」とは全く関係がない。後者はただのデータ。

m2ym @m2ym

状態マシンで実世界的な「状態」をモデル化するのは、かなり難しいと思う。実世界的な「状態」は冗長であるから、状態マシンが必然的に複雑になってしまう。

m2ym @m2ym

そこを考慮せずに、状態を不変にしさえすれば状態マシンにするのは簡単だから、従って状態の管理は簡単、と言うのはさすがに飛躍がある

m2ym @m2ym

だから取り得る最初のステップは、実世界のメンタルモデルでソフトウェアを設計しないことだと思う

m2ym @m2ym

ただ、現実的な要請として(例えば速度)のために冗長な状態を持つ必要がある場合も当然ある

m2ym @m2ym

例えばサーバーに問い合わせて、部分的な情報を例えばJSONで取得し保持するのは、冗長な情報を保持することに他ならないと言える

m2ym @m2ym

そのようなことを考えると、一般的な状態管理というのは、とても難しく感じる

m2ym @m2ym

その点を踏まえると、現時点において状態を持つのは必然であると言えると思う。そのため、状態に注目するのではなく、矛盾のない状態遷移を(暗黙的に)記述できるかどうかに注目するほうが、現実的にうまくいく可能性がある、という結論になる

pokarim @pokarim

@nagise すみません、見落としていました。すでに解決済みかもしれませんが、ちょっと説明を考えてみます。

pokarim @pokarim

明示的な状態遷移の記述とは、記録してあったデータ（通常状態と呼ばれるもの）と、新しく手に入ったデータ（入力や他の状態）、この両方を元に、記録してあったデータとの差分、もしくは新しいデータそのものを計算する方法の記述だと言えると思います。 @nagise

pokarim @pokarim

可変な状態というものは、変化する前と後で、ある観点からは「同じもの」であるとみなせるもののことだと思うので、（暗黙的な場合もあるけれど）常になんらかの同一性の概念とセットなんだと思う。

pokarim @pokarim

@salmonsnare 私もそれは聞いたことがありますし、それはもっともだと思います。しかし、ここは文脈から、そのことにあえて懐疑的に考えてみたいというのと、自由の概念も固定されたものではないと考えているからでもあります。（しかし所謂相対主義的な考えを主張するわけではありません

Yuta Okamoto @okapies

@pokarim Clojure の作者の人が提唱してる "Epochal Time Model" に近い考え方かもしれませんね。 cs.ox.ac.uk/ralf.hinze/WG2…

pokarim @pokarim

@okapies まさに、そのp6あたりで"Epochal Time Model"というタイトルの付けられた図に登場する、Process events (pure functions) というところが、今回の議論で否定的な意見を述べたかった対象です。

pokarim @pokarim

@okapies つまり、その"Epochal Time Model"では、状態から次の状態の遷移を、純粋な関数として記述するようですが、それでは効果的でないのではないか、というのが今日主張したかったことです。

Yuta Okamoto @okapies

@pokarim あー、なるほど。ただ、ここでは v1〜v4 を一つの identity の継続として表現しているので、まさにおっしゃってる事と同じなのではと思ったのです。要は永続データ構造ですが。