Strongly static types, not for every task なのは何故なんだ

2017-06-02 / [clojure]

Clojure Rationale

このページにこんな文があった。

Pure functional languages tend to strongly static types * Not for everyone, or every task

「静的型付けは全てのタスクに適しているわけではない。」

そのタスクとは何を想定しているのか、ここでは語られていない。

僕はHaskellが好きだし、GHCの型システムがとても好きだ。コンパイラに怒られながら、コンパイラと協力してプログラムを組み上げていくのはとても楽しい。 データの構造や関数の要求する仮定・制約を忘れっぽい僕にはとてもいいシステムだ。 だから静的型付けは好きだ。

だからこそ、静的型付けがふさわしくないケースを知りたい。

Richがここで言っているように、静的型付けではふさわしくない領域があるはずなのだろう。 それが何なのか知りたい。

関数の再利用性のために

この辺 が背景なのかな。

Rich的には関数の再利用性を促進させるために、具象型に関数を縛り付けないということなのだろうか。

Clojureではユーザ定義型を定義するよりも、リストやマップを頻用して、 関数の再利用性を上げることができるから型が不要ということ?

それでもやっぱり静的型付けではふさわしくない問題が何なのかはまだわからない。

Python書いている時

Pythonも静的型検査がない。 比較的Pythonスクリプトを書く機会があるので自分の感覚を思い出してみる。

「これはHaskellだと無理だなー」って思うようなことがあっただろうか。

小さなスクリプトを書く

bashの延長だと思って書捨てる時に静的型検査は要らないと思うことはある。 そういう時ってあまり問題の構造とか考えなくって、 頭にある「手続き」をPythonのコードに書き下しているだけ。

そんなふうに、問題の分析を飛ばして動くものを書いている時、確かに静的型付けが必要だとは思わない。

中規模のWebアプリを書く

データモデルを考えて、適切なクラスを定義、ってなる。 もう問題の構造を捉えようとしている。

この時初めて型による名前付けが欲しくなる。

付けた名前はプログラマ間で共有することで、意図や意味を伝えていく必要がある。

そのために型注釈が必要になってくるし、それらの意図や意味に沿わない操作を禁止するために静的型検査が必要になってくる。

やっぱり規模が増せば自然と静的型検査を要請してしまう。

PythonでWebアプリを書いていた時、やっぱりそう感じたのを思い出した。

Clojureでも同じように感じるか?

感じると思う。

少なくとも僕はデータの構造をすぐ忘れてしまう。

Land of Lisp読んでても、自分でClojure書いてても思うけど、結構頻繁に扱っているデータの構造を忘れる。Lisp書く人は関数に渡されるデータの構造覚えてるのが普通なんだろうか。

— iM2R::UTC (@ilyaletre) 2017年3月28日

だから長らく自分がメンテしていないコードを見たらきっとどんなデータを扱っているのか解らず苦しむだろう。

それでもClojureが好きなのか?

なんか好き。なんだろ。 大きいもの書き始めたら嫌になったりするのだろうか。

ふとClojure書きたくなる謎の魅力がある。不思議な言語だ。 これが中毒性か。

(Haskellはよっぽど親を殺されたりしない限りずっと好きだと思う)