Rich HickeyによるClojureの設計判断を読んだメモ
kip2Clojure作者であるRich Hickeyによる、Clojure設計判断の記事を見つけたので、読み込んでいく。
設計判断記事
Rich Hickeyとは
英語が読めないので、翻訳をかませて読むことにしようと思う。
kip2目次から全体の構成を掴もう。
おおまかに4章ある。
- FP vs OOP
- Clojure Design
- Clojure Features
- Learning, Process and Community
設計判断に関するところはこの内2つ目のClojure Designのところだろうか。
こうしてみると、設計判断を答えただけの記事ではなさそう。
kip2What is the meaning of data?
データは本来、「事実や観測結果の記録」を指す。
観測結果を記録することが「データ」であり、それをどう解釈するかは別の話。
データは静的であることが本質。
「42」という数値はデータではなく、それが意味する「事実」や「観測結果」が重要。
事実を動的に変更可能なシステムで扱うと、データの概念が損なわれる。
例として、「生年月日」はデータだが、「年齢」はデータではない。年齢は状況によって変わる派生情報。
データが静的であることが、重要である。
動的な情報や意見のように、常に変わるものであれば信頼性が低い。
データの静的性質こそが、再現可能な科学や推論を支えている。
感想
データの不変性を説いたものかな？
静的な情報こそをデータとして扱えということだと思う。
Clojureで言うところのイミュータブルなものに結びつく概念だろうか。（違うかも）
この記事で言ってることが近いのかもしれない。
Java的な、クラスベースのオブジェクト指向言語の場合、メソッドを作るにはクラスを定義してそこにメソッドを足すわけなので、メソッド（関数）はあるデータの集まり（オブジェクト）を操作する専用の関数として定義しがちです。そりゃ、「そのオブジェクトを操作するためのメソッド」なのだから当たり前です
一方、データと関数が分離している場合は、関数を特定のクラスやオブジェクトに結びつける意味はないですし、逆に、ある関数のために専用のクラスを作る意味もない。極端に考えれば、すべての関数が共通のデータ構造を処理するようにした方が、多様な関数を柔軟に活用できるようになる。
というよりも、オブジェクトに関数が結びついているからこそ「このメソッドはこのオブジェクト構造を処理するためのものだ（他の用途には使えない）」という風に専門化できていたんであって、データと関数を個別のものと扱う以上は、「この関数はこのオブジェクトだけを扱う」という前提を置けないのです（当たり前です）。あるオブジェクトと別のオブジェクトが、型であったりクラスであったりが異なったとしても、関数は、そのオブジェクトが、関数の処理できる構造であれば、処理できるべきなんです。関数とオブジェクトが独立しているというのはそういう意味であるべきです。であれば、すべての関数にまたがるような、共通の汎用データ構造があって、すべてのデータはその汎用性を担保してたほうがいい。