🔖Clojureについての個人的なポエム of Clojure.
Journals
- 💭YOASOBI/群青きいて泣いた(2022/09/01)
- 💭最近Clojureで検索するとこのサイトがでてきてけっこう迷惑
- 💭Clojureを学ぶことはSICPの挫折体験を克服すること(2022/10/13)
- 💭Clojureマクロではじめてちょっとしたコードをかけた(2022/10/28)
- 💭Clojureで仕事するならば自分がビジネスオーナーにならないといつか不幸になる
- 💭人類の進化が毒キノコによってもたらされたようにClojureを使う
- 💭Clojureに本格的に取り組んで1年が経過し成長による内的充足感を味わう(2023/01/16)
- 💭Live Codingに胸がドキドキした(2023/01/22)
- 💭マクロの力を極限まで叩き上げてみたい(2022/10/22)
Posts
Zettels
✨ClojureはJavaよりもシンプルに行数が短く書けるのは本当か？
同じ主張はScalaでもされている.
Java8 で登場した Stream API記法をつかったコードで比較しているのかは気になる.
for文やif文を多用したJava7以前の記法のコードと比較してClojureはコードが少なく書けるんですよ!といってもそこには比較が片手落ちなきがする.
Java8以降のより関数型に近い記法でJavaを書いたらどうなるのか気になる.
✨Clojureのデータと関数は分けるを深ぼる
データと操作を1つのデータ構造に納めるのがクラスでありJava流. データと操作は別々に定義するのがClojure流.
操作というものも関数値(Cの関数ポインタ)と捉えれば, 構造体への参照と関数への参照を1つのデータ型にまとめたものがクラス.
しかし整理のために, 具体的にはデータとそれに対する操作は一緒にしておかないとわたしの脳が忘れるというコーディング上の課題? への解決策としては, 1つのファイルrecordを定義したらその下にそのデータ構造を操作する関数を書く.
仮にnamespaceをアプリのドメインごとに切るとすると, 1つのnamespace，1つのファイルには１つのrecordを定義することになるのかな？ そしてそのドメインに対する操作をそのファイルに書く.
この考察の派生として, 悪い書き方は recordに対するprotocolを定義するのだれども, そのprotocolがrecord専用となってしまい, そのnamespaceにbindingsしてしまうことだ.
これをやりそうになったがこれはJavaの呪いであり, OOPからFPへ慣れてないからな気がした.
protocolはドメインのnamespaceではなくて, リスト操作を想定してそのリストの定義するところに定義するべき.
✨ClojureのImmutable Dataによってprivateという概念はなくなる？
privateやらカプセル化やらはデータがMutableな世界において以下にバグを出さないかというためのGood Practiceとして発展したので, そもそもデータがImmutableな世界ではその概念が不要か？
それでもnamespaceでprivateな関数を宣言するのはコンピュータというよりは開発やそれを開発する人の都合か？
あるチームの関数を許可なく勝手に使うなよみたいな. 昔組込み開発していたときうちのチームの開発した便利ツールを勝手にみんな使ってさらにそのツールがバグってて苦情を言われるみたいなことがあった, 迷惑.
✨Clojureの関数の引数はMapだけがいい
最近思うこと. シーケンシャルデータは置いとく.
関数に対する引数でたくさんいろんいろ渡すよりもMapを一つわたしたほうがいろいろ楽な気がしてきた.
2つの引数を渡そうとしてもあとあと考えたら3つわたしたくなったとき, いちいちいろいろな場所を書き直すのが面倒. Mapを一つだけわたしてあとは📝Clojure分配束縛の記法で分解すれば拡張性が高い.
そしてそれよりもClojureの思想的に, あるMapに対して関数を適用して別のMapを返す, その総体がシステムであり, 関数の巨大な集合体がWebサービスというようなきれいな解釈ができる.
ということで関数の引数にMapを一つだけわたしてそれを分配束縛するパターンを積極的につかっていきたい(これが正解とはわからない).