🏛Clojure考察

🏛Clojure考察

個人的なポエム of Clojure.

refs: 🏷Clojure 📝Clojureモチベ 📝Clojure思想

💡考察: ClojureはJavaよりもシンプルに行数が短く書けるのは本当か? #

同じ主張はScalaでもされている.

Java8 で登場した Stream API記法をつかったコードで比較しているのかは気になる.

for文やif文を多用したJava7以前の記法のコードと比較してClojureはコードが少なく書けるんですよ!といってもそこには比較が片手落ちなきがする.

Java8以降のより関数型に近い記法でJavaを書いたらどうなるのか気になる.

🏷Java

💡考察: Clojureのデータと関数は分けるを深ぼる #

データと操作を1つのデータ構造に納めるのがクラスでありJava流. データと操作は別々に定義するのがClojure流.

操作というものも関数値(Cの関数ポインタ)と捉えれば, 構造体への参照と関数への参照を1つのデータ型にまとめたものがクラス.

しかし整理のために, 具体的にはデータとそれに対する操作は一緒にしておかないと, わたしの脳が忘れるというコーディング上の課題? への解決策としては, 1つのファイルrecordを定義したらその下にそのデータ構造を操作する関数を書く.

仮にnamespaceをアプリのドメインごとに切るとすると, 1つのnamespace,1つのファイルには1つのrecordを定義することになるのかな?そしてそのドメインに対する操作をそのファイルに書く.

この考察の派生として, 悪い書き方は recordに対するprotocolを定義するのだれども, そのprotocolがrecord専用となってしまい, そのnamespaceにbindingsしてしまうことだ.

これをやりそうになったがこれはJavaの呪いであり, OOPからFPへ慣れてないからな気がした.

protocolはドメインのnamespaceではなくて, リスト操作を想定してそのリストの定義するところに定義するべき.

ref: Clojure Architecture Visitor Pattern Iterator Pattern

💡考察: ClojureのImmutable Dataによってprivateという概念はなくなる? #

privateやらカプセル化やらはデータがMutableな世界において以下にバグを出さないかというためのGood Practiceとして発展したので, そもそもデータがImmutableな世界ではその概念が不要か?

それでもnamespaceでprivateな関数を宣言するのはコンピュータというよりは開発やそれを開発する人の都合か?

あるチームの関数を許可なく勝手に使うなよみたいな. 昔組込み開発していたときうちのチームの開発した便利ツールを勝手にみんな使ってさらにそのツールがバグってて苦情を言われるみたいなことがあった, 迷惑.


Tags