日々の破片

_ プログラミング言語を1つだけ覚えるなら

選択肢は2つあって、1つは自分が持っているコンピュータのアセンブリを覚える（JVMやCLRはちょっと違う。もっと生なアセンブリじゃないとだめだと思う。だって第1引数についての先入見というかクセがついちゃいそうだし）。あとは、理論を読んで自分で実装する。ロビンソークルーソーだ。もう1つは、LISPだろ（ちゃんと知っていればたぶんSchemeなような気もするが）。

最初に関数型プログラミング言語としてかっちりとプログラム書きまくれるように学ぶ。次にCONDとかLOOPとかを使って普通に手続き組んでプログラムを書きまくれるように学ぶ。

それから次のセルで何でも表すようにしてプログラムを組む。((関数リスト) . データリスト)

これで、型付けされたOOPLはOK。

次に同じプログラムの関数リストの部分をちょいといじって連想リストにして名前で関数を呼ぶように変える。これでダックタイピングなOOPLもOK。

でも、2つ覚えるほうが現実的な気もする。

SQLとJavaだ。おそらくちゃんとSQLを自在にこなせる人はなんなく関数型プログラミングも使えるようになるのではないか。代入なんかないから全部selectしなければならないわけで。それでいくらでも組めれば（というかドメインが制限されているところが問題ではあるが）、関数型プログラミング言語を手にすればあまりの楽さに感動ものなような。

IDEなしのC#というのは両方をいっきに覚えられる（意識的にやれば）かも知れないから、LISPで書いたことを出発地点を手続きに寄らせる方法として立派な選択肢となるかも知れないけど。でも一度代入してループしてという方法を覚えてから関数型へ歩を進めるより、先に関数型プログラミングを学んでから手続きへ進むほうが楽なように思える。小学生が算数で中学生から数学というのは正しそうに思うが、その道をすでにたどって両側（の考え方の違い）を知っていれば、今度は数学やってから算数へ進むほうが楽なように思えるからだ。

それとは別に考えるのだが、OOPLの設計の部分を強調するあまり、手続きの組み方をおろそかにする傾向があれば、それはまずいのではないか。手続きをきちんと組めなければリファクタリングもできないし、それこそへまなVBプログラミングに陥りそうに思える。個々のメソッドの中は手続きが入るわけで、そもそもそこが組めなければ何も作れない。