Clojure/conj 2017 上映会 #1 に参加してきた

NOTE ただの参加ログです。雑な情報の再生産なのでちゃんとしたやつとか本家を読んでください。

clj-nakano.connpass.com

に参加してきた。開催者様、会場の準備、ピザとコーラ、そしてそもそも開催自体していただいたこと、ありがとうございました！みたことある人がチラホラいる感じだった。

Rich Hickeyの話をちょっと再生しては訳が入る形式だったので、正直言ってRich Hickeyが何言ってるかは5%くらいしかわからなかったけど話についていけた。

Rich Hickeyについて

Rich Hickey、突然現代に現れた未来人だと思ってたけど大学卒業後18年間ふつうに（？）開発者やってた。 Rich Hickeyは「Situated」なプログラムをイメージしている。ビジネス要件で簡単に自分が心血を注いだアルゴリズムが無意味になるのはよくあること。

現実世界は対応を迫られる不整合に満ちている

現実のアプリケーションでは純粋なアルゴリズムはほんのすこしで、残りはほとんど情報処理用のプログラムである。しかもその純粋なアルゴリズムも、ビジネス要件で簡単に翻る。情報処理というのは、たとえば外部ライブラリを使用したり、DBと通信したり、別システムと連携したりすることを指す。

これに時間軸を加えれば、システムが対応しなければいけない変化には「ライブラリがメンテされなくなった」「DB製品が変わる」「システムのI/Fが変わる」「要件が変わる」ことも含まれると分かる。

RichはORMでRDBMSのプロトコルをラップしてあたかもプログラミング言語の世界のプロトコルであるかのように使えるのは努力の方向性が違うと言っている。んー、Datomicならいいのか？どういうORMを想定しているんだろう。

現実の複雑さ

talk-transcripts/00.29.49.png at master · matthiasn/talk-transcripts · GitHub

上の図がわかりやすい。

Rich Hickeyは上の図で型を間違えることを些細な問題と表現しているが... Clojureを触っていてもMapがくるかListがくるかそれとは別の何かが来るか気にしなければいけない。とはいえそれは瑣末な問題で、プログラミング言語のレイヤーで解決しないことにした、ということかな。今仕事でRubyを触っているけど、Rubyはメッセージ中心だから型が何かは気にしない、という思想があるのに対してClojureはそもそもそんなところ瑣末な問題だから気にしないわ、と切り捨てているのが、設計思想の違いを感じて面白いと思う。

Pythonとかの他の動的型付け言語はどんな思想で作られてるんだろう。

Immutabilityの背景

RichはPLOP(PLace Oriented Programming)という言葉を出している。 PLOPはイミュータビリティと相反するプログラミング手法で、メモリやディスクのアドレスと結合したプログラミング。しかしそれではイミュータブルにできない。メモリのアドレスの中身に入ってる情報は刻一刻と変わる。

Clojureを支えるイミュータブルなシーケンスが以下らしい。

clojure/PersistentHashMap.java at master · clojure/clojure · GitHub

全然知らなかった。

情報は変化し続ける

静的型付け言語では、情報を操作するのがめんどくさすぎる。クラスはデータのコンテナが意味を持ってしまったものだが、これを使ってEffectiveなプログラムを書くには情報を一つ一つクラス化しなければいけない。具象を必要以上に持ち込んでしまったのが問題だ。

うーん...。ドメインが多くて複雑なら、その分だけ扱う意味が増えてクラスが増えるのは自然なことだと認識してたけど...。ていうか意味のないデータ構造だけでは、結局プログラマーは巨大なシーケンスのネストしたハッシュマップを指差して「ここにはユーザーのデータを変換したものが入ってるんだよ」とか話すことになる気がする。

巨大なシーケンスだとしても、その連想配列のキーに適切な名前をつければいいじゃない、ってことか、な？