Clojure設計思想/哲学/Clojure Wayまとめ
Clojureの設計思想についてまとめる.
Clojureらしくソフトウェアを書くときにどうすればいいかを議論するときの指針となる. Clojure開発者同士の合意が取れる, ということ.
できるだけ他者の意見を集め, それに対する自分の考察は, Clojure考察でまとめる.
Rich Hickeyの名言
プログラミングClojure
📚プログラミングClojure - Alex Miller, Stuart Halloway(2nd:2013/3rd:2018)
データ関連
Code is data, data is code
aka. LISPの思想. homoiconicity.
📜Clojure is immutable and persistent
Clojureにおいて値はimmutableでありpersistentである.
Clojureの値は不定で不変.
Prefer data over fucntions
データ > 関数 > マクロの順に選択する.
💡Clojureの全てはマップである(Everything is a Map)
Clojureの全てはマップである.
💡Make Your Data Visible
ref: Thinking in Data
データの非公開は不要, なぜなら不定だ. カプセル化はミュータブルな世界の産物.
💡Thinking in Data
🔗Thinking in Data, Stuart Sierra さんの講演.
おそらくRecordの説明で一番わかりやすかった動画.
以下のことを強烈に主張.
- Everything is a Map，全てはMapである.OOPから来た人たちはすぐにクラスみたいなデータ構造を定義しようとするんだ.
- Record Are Not Schemes，Recordはスキーマではない.
- なぜClojureのMapをつかわないんだ！
- 定義するものはよく考えればだいたい不要でしょう.
- Recordは必要になるまで導入しない.
- defrecordでtypoしたらどうする？
- Recordは以下の場合のみにつかう.
- 単なる性能のための最適化.
- 汎用的な動作を追加する場合のみ利用する
- ポリモーフィックでない操作はいらない!
つまりせっかくClojureのMapが素晴らしいのでなぜそれをつかわないんだ？ということ.
シンプルでどんなケースにも対応できる数個のデータ構造は, クソみたいな100個のクラスよりも力がある.
関数関連
💡少ない抽象データ構造とたくさんの関数
💡関数はSeqかAssociativeを入力しSeqかAssociativeを出力する
ref. Clojureの世界観 - 紙箱
Java的な、クラスベースのオブジェクト指向言語の場合、メソッドを作るにはクラスを定義してそこにメソッドを足すわけなので、メソッド（関数）はあるデータの集まり（オブジェクト）を操作する専用の関数として定義しがち.
Clojureの場合は、言語全体が前提とする抽象データ構造があります。リスト状のものはSeqと呼ばれる抽象データ（代表例は配列）として、マップ状のものはAssociativeと呼ばれる抽象データ（代表例はマップ）として扱います。事実上ほとんどのデータがこの２つで表現されていて、多くの関数が、引数としてSeqまたはAssociativeを受け取る（あるいは内部で自動で変換する）し、SeqまたはAssociativeを出力します。
関数はSequencialやAssociativeなデータを受け取り, それを処理して何かを出力するものに過ぎない.
💡It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures
“It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.” This quote is from Alan Perlis’ Epigrams on Programming (1982).
たまに見かける言葉. これはアランパリスという計算機科学者の言葉であるがClojure設計思想に影響を与えた.
10種類のデータ構造にそれぞれを扱う10個の関数があるよりも、ひとつのデータ構造を扱う100個の関数がある方が良い.
💡preferring to build a large library of functions on a small set of types
単純なデータ型とそれを操作する関数群を好む.
ref. Clojure - マルチメソッド(multimethod)と階層
Clojure は状況ごとに新しいデータ型を定義するような伝統的オブジェクト指向のアプローチを避け、代わりに少ないデータ型に対する関数群からなる巨大なライブラリを構築することを好む。
しかしながら、Clojureも柔軟で拡張可能なシステムアーキテクチャを可能にするランタイムポリモーフィズムの価値は認識している。Clojureはタイプ、値、属性と引数のメタデータ、ひとつ以上の引数の関連性によるディスパッチをサポートするマルチメソッドシステムを通して洗練されたランタイムポリモーフィズムを提供する。
これは Thinking in Data の考えに似ている. つまりOOPの人はすぐにドメインごとに無数のオブジェクトを作りたがるが, 素でマッチョな力があるMapをつかえ, ということかな.
ref. 📝Clojure multimethod
🔦Rich Hickeyはパターンマッチよりもポリモーフィズム(multimethods)が好き
遅延評価戦略
Web開発
References
Clojureの設計思想を探るにはYoutubeに投稿されているClojure Conjの動画をみるのもいいかも. たくさん動画がある.
このClojure界隈では Rationale という用語をよくつかっている. おそらくRich Hickeyが多様しているのかな？
Related
up: 📁Clojure