jFD開発したりしなかったり日誌

_ jFD2

ちょっと欲しくなって、カレントディレクトリ以下の空ディレクトリ

（空ディレクトリのみを含むディレクトリも）を削除してくれるスクリプト、

というのを書いてみた。

30行。

簡単ぷう（謎語尾）。

_ Groovyはもう終わりなのか

とkeisuken先生が思ってる模様。

終わりというより、世間的には始まってすらいなかった感が。

個人的には、ある程度充実したクラスライブラリが使用可能な環境で、

僕みたいなJava屋が100行程度までのシンプルなプログラムを書くには

かなり便利な道具だと思う。

書こうと思えばほとんどJavaと同じ文法で書けるから、Javaプログラマなら

慣れるのに時間がかからないのもいい。

ただ、パフォーマンスが悪かったり、初期の頃はエラー文に行番号が無くて

デバッグで死にそうになったり、EclipseみたいなIDEのサポートが無いから

実は素のJavaより手間がかかったり、プリミティブ型作るのがめんどくさかったり、

けっこうイマイチな部分も多かった。

文法の良し悪しはよくわかってないです。

ほとんどJavaだと思って書いてるんで。

_ 美しいソース

その内書こうと思っていたんだけど、いい機会なんで書いてみる。

僕は美しいソースコードとは、

「記憶力を使わないソース」

だと定義している。

汚いソースを読むのには記憶力が必要になる。

汚いソースは色々あるけど、とりあえずリストアップしてみる。

・メソッドがクソ長くて最後まで読む頃には最初を忘れてる
・分岐が多すぎて全体が把握できない
・ネストが深過ぎてそこにたどり着く条件が思い出せない
・一度に把握してなければならない変数が何十個もある
・publicなメソッドが一つのクラスに数十個もあって、しかもそれらが
　妙に依存している
・変数やクラス、メソッド名が省略されすぎたり無意味だったりして
　名前を見てもどういうものか思い出せない
・Javaなのに変数の宣言が全部メソッドの最初で、必要になるまで
　数百行も離れてたりする

_ まだ幾らでもあるけれど、これらは全て記憶力が必要だから

汚く感じるものだ。

前にも書いたけど、人間が一度に把握できる物事は、7個

（個人差によってプラスマイナス2個）と言われているそうだ。

それ以上になると人間の能力を超えてしまい、読むのに酷く苦労するので、

イライラして、汚く感じる。

それを防ぐために考え出されたのが、カプセル化、関数、スコープ、

クラスといった概念だと思う。

巨大なプログラムを、いかに記憶力を使わずに書くか、というのが

目的の技術だ。

_ これらの概念を使ったソースは別の意味でわかりづらいが、

それは読み手に求めるのは記憶力でなく、理解力だからだ。

僕は理解力を求めるソースは否定しない。

一回理解してしまえば後は応用で理解できるからだ。

理解は再利用が出来るので財産になるけれど、記憶はそうじゃない。

_ これを原則としてコードを見ると、コードの良し悪しというのは

けっこうわかりやすいと思う。

_ そういえば昔、

どこかの中学生だか高校生が作った言語というのを見たのを思い出した。

命令が全て二桁の数字で

「こんなにコンパクトに書けます！」

と威張っていたが、マシン語かと思った。

あれは若くて脳みその性能が良くて、記憶力が無限にあるような人

ならではの無茶だと思う。