JavaScriptベースのSKKを書くべきかもな。やってみるか。。。

ってのはできないかなあ。

The Productive Programmerを読んで、Launchyを試してみた。いい感じだ。似たような物を作ってみたいな。ソースは公開されているのかしら。。。

scimがうまく起動しなくなってしまった。CPUを食い潰してしまうのだ。aptでアンインストールして、再インストールしたが、やっぱりうまく起動しない。ということはホームディレクトリにある設定ファイルのどこかが壊れて無限ループに入っている気がする。前にどこかで読んだ事例のような気がするのだが、うまく見つけられない。

しょうがないからuimを使ってみた。ついでにanthyを捨ててuim-skkにする（もともとemacsではskkを使ってるんでね）。あっさり動く。anthyの馬鹿っぷりにもイライラしてたんで、これでいいのか、な。

Eiffelは、もっとも優れたOOPLのひとつだろう。だが、実際に使ってみると、ひとりで使ってもしょうがないと感じる。

Eiffelの強みはDesign by Contractにある。だが、DbCが役に立つのはどういうときか。再利用可能なコンポーネントを書くときである。

再利用可能なコンポーネントは、そうでないプログラム部品を作るよりもコストがかかる。ある種の課題に数年に渡って取り組んでいるのであれば、再利用可能なコンポーネントに取り組みたくもなるのだろうが...。

もちろん、品質の高いソフトウェアを書こうと思えば、Eiffelがかなり有望なのはわかる。だが、DbCにしたところで、Eiffelでしか実現できないわけではない。

Eiffelの素晴らしさは、設計思想がしっかりしていること、そして長年に渡って実務に使われ、磨き上げられていること、にあると思う。言語仕様も安定しており、実行時性能も申し分ない。ただ、ウォーターフォール向きの言語だという印象は拭えない。

EiffelでRADするための技法もありそうな気がする。だが、何にしても、自分のためのプログラミングのためにEiffelを使おうという気持ちにはなれない。バグを出してしまったときのコストがきわめて高いプロジェクトがあれば採用してみたい気持ちもあるが、どうもそういうプロジェクトにはあまり出くわさない。むしろ品質よりも早いリリースを期待されているプロジェクトばかりだ。それではEiffelの出番はない。

EiffelでOSを記述するのはおもしろそうだけどね。

技評から出ていた「LLフレームワークBOOKS#01 TurboGears×Python」を読んだのだが、何というか拍子抜けしつつも、ここしばらくずっと感じていたことが具体化した思いがした。

まず、この本は悪くない本だと思う。Pythonも、僕は好まないが、悪い言語ではない。TurboGearsも良くできたWebアプリケーションフレームワークだと感じた（まだ実際には使っていないので、細かい使用感はわからない）。

ただ、Railsにインスパイアされて作られたWebアプリケーションフレームワークは、どれも大同小異だ。個々に出来不出来や得手不得手はもちろんあるんだが、言語の壁を越えて習得すべきものはない。RubyistならRailsを使えばいいし、Python使いならDjangoかTurboGears、PHPerならSymfonyかCakePHPを使えばいい。わざわざ慣れない言語を学ぶほどのアドバンテージはない、と、ここは言いきってしまおう。

ただ、これらのWebアプリケーションフレームワークは「アジャイルな開発」をサポートしているのだが、アジャイル陣営の指導者たちが常々叫んでいるように、アジャイルな開発においても設計や仕様の文書化は依然として重要なのだ。ともするとアジャイルな開発のチュートリアルは顧客の言葉を聞きながら、リアルタイムっぽく、インクリメンタルに開発しているような印象を受ける。いや、それはそれで間違いではないんだが、それはそれとして仕様書を作る作業は別途、できれば同時進行で進めるべきだし、顧客の決断は記録をとるべきだし、コーディングする前に仕様レベルで矛盾がないかどうか、最適な設計はどのようなものか、確認しないといけない（あるいはコーディングを通じて探索的に仕様の矛盾と最適な結果を追求しないといけない）。

それこそ、ペアプログラミングしているプログラマーと、顧客の言葉を仕様書に書き起こすライターと、両者の成果物をチェックするアーキテクトが必要なんじゃないか。コストダウンの圧力からアジャイルを選択するとまず失敗する。アジャイルは「真の品質」を追求する方法論としてとらえないとね。

去年の夏頃は毎日Erlangばかりいじっていた。習得しやすく、実用的な言語だと感じた。

そのErlangの解説書の決定版が出たので、買ってきた。まだ全部を読んではいないが、素晴らしい出来だと思う。

Erlangは関数型言語としては純度の低い言語で、ちょっとキモいんだが、実際にプログラムを書いてみるとなかなか快適なのである。役に立つプログラムがサクッと書けるし、バグのないプログラムを書けるように言語仕様が支援してくれているのも感じとれる。

メリットもハッキリしているし、関数型言語の未経験者が最初に取り組むのに最適の言語じゃないかなあ？

設計力を鍛えるために、絵を習ってはどうかと思う。

自分は小学生から高校生にかけてアトリエに通っていたのだが、そこで得た知見は大いにプログラミングに役立っている。

たとえば、ある程度大きなキャンバスに絵を描く場合には、より小さいキャンバスに習作を描くと有効である...プログラミングに直せば、プロトタイピングだ。習作を描く方が「早く」仕上るわけではない。完成度が高まるのである。

大きなプログラムはデバッグが難しい。完成度の低い大きなプログラムとなれば、その難しさは船を沈没させかねないほどだ。そこで苦労するより、プログラムの完成度を高める努力をする方が遥かにいい。

絵を描く経験が足りない人は、最初から確定的な線を一発で引こうとする傾向がある。いってみれば人物画を描こうとするとき、最初に顔の輪郭から描こうとする感じだ。だが、経験者はいきなり最適な線が得られるとは思っていない。まずは構図を検討する。また、油彩画やアクリル画であれば重ね塗りができるので、細部のことは後回しにして大雑把に色を載せていく。そしてキャンバスを逆さまにしたり、遠くから離れて見たりしながら、いろいろな角度でキャンバスを眺める。絵を描くことに集中し過ぎると、客観的にモノが見れなくなるので、時々こうやって頭をリセットしてたることで、自分の「思い込み」に気づけるようになるからだ。

こういう手法は、トップダウンプログラミングに見えるかも知れないが、そうではない。トップダウンプログラミングでは、上部構造をカッチリと決めるのだが、絵画の場合、上部構造すら流動的なのだ。むしろ、習作を描いたり、下絵を描いたりしながら、モチーフと対話し、キャンバスと対話し、絵の具と対話することを通じて、心の中に完成図を積み上げていくことそのものが大事なのだ。

初心者と経験者の違いは、初心者が対象を軽く一瞥しただけで「見たとおりに描けばいいんだな」と思うのに対し、経験者は「見る」という行為の難しさを知っている、ところにあると思う。絵を描くためには、対象をよく観察しなければならない。「ここは明るい。ここは暗い」では不十分である。明るさ、暗さには様々な「程度」があるし、それだけでなく「どのような印象を受ける明るさ、暗さなのか」というような感覚的な部分も忘れてはならない。観察から得たものが充実すればするほど、良い絵を描けるのである。

プログラムの設計で、もっとも大事なのは、第一印象を疑うことであろう。一見、かつて解決したものと似たような問題のように見えるかも知れない。しかし、本当にそうだろうか？

設計において試行錯誤することは、大いに報われる。プログラミングやデバッグが楽になるし、設計力の鍛錬にもなるからだ。あるプロジェクトで設計に起因するトラブルに出くわしたら、次のプロジェクトでは設計に充てる時間を大きく取ることだ。目新しいテクニックも使ってみるべきだ。そのテクニック自体はバズワードかも知れないが、そこでの体験が古くからのテクニックに新しい光をもたらすことがある。鍛錬なしに設計力は高まらない。プロスポーツの選手だって、いろいろなトレーニング方法を試す。またトレーニングは就業時間中に取り組んでよろしい。むしろコーチを求めたり、自らコーチになったりした方が良いのだ。

Webアプリケーションの設計をするとき、Schemeでいう継続(continuation)の概念を理解しておくと非常に役に立つ。

継続の概念は、なかなか理解が難しい。概念として理解できても、それが何に役立つのかわからないという人も多いだろう。実際、僕も継続の有効活用についてわかるようになるまで、何年もかかったし、今でも十分に馴染んでいると自負できるまでには至っていない。

しかし、最近になって気付いたのだが、Webアプリケーションというものは、ちょっと見方を変えてみると、GOTO文とグローバル変数の塊なのだ。そして継続はこういった問題を制御するための武器になる。

セッションに値を格納するとき、それが不変の値であれば良いが、状態を持つ場合、それはまったくグローバル変数そのものである。しかもWebアプリケーションの場合、複数のURIにまたがる処理はブラウザの「戻る」ボタンやブックマークによって、プログラマーの意図しないポイントへGOTOしてくる可能性がある。利用者がプログラマーの意図した通りの操作をするとしても、個々のURIとURIの関係は「構造化」されてはいない。ちょうどKnuthのArt of Computer Programmingに書かれているプログラムのように、GOTO使いまくりの構造にならざるを得ないのである。

こういった問題に取り組むためには、もちろんセッションに格納する値の取り扱いについてきっちり文書化することが必要だ。また、各URIにおいてセッションの値、リクエストパラメータについて事前条件、事後条件を文書化しておくべきだ。そこまでは良いのだが、それが「適切・妥当な設計かどうか」をどのように評価すべきだろうか。

設計不在よりは設計がある方が良いが、やはり設計には良い設計もあれば悪い設計もある。だから設計を文書化したら評価しなければならない。試行錯誤なしにいきなり優れた設計を手に入れられると思うのは虫のいい話だ。

かくして設計の良し悪しを判定する視点が必要になる。そのとき、継続がわかっていると良いのだ。

継続とは、一連の処理のある時点において、以降の処理と以降の処理に必要な状態をパッケージ化したものだ。

継続をファーストクラスオブジェクトとして他の関数への引数にしたり、あるいはデータベースに永続化できたりすると、いろいろなことができるようになる。たとえば、一連の処理をある時点において中断し、他の処理を先に済ませてから、中断した処理を再開したりできる。例外処理が発生するような場合、例外処理の発生するブロックの直前で継続を取得しておけば、例外処理が発生したときにはその継続を評価すればブロックを脱出できることになる。

継続がわかるようになると、一連の処理のある時点において、以降の処理と以降の処理に必要な状態(つまり継続に含まれる情報)を見極められるようになる。Schemeでは継続の取得は処理系に任せることができるのだが、注意深く考えれば手作業で継続を取得することもできないわけではない(だからCommon Lispではマクロで継続を取得することができる)。

継続を手作業で取得できるようになると、Webアプリケーションにおける各URIの事前条件、事後条件を決定することができるようになるし、各URIの関係を関数と関数の関係にマッピングして、リファクタリングすることができるようになる。

こういうことができるとわかってみると、画面遷移図すら書かずにWebアプリケーションを書いていた頃のことを思い出して冷や汗が出る。フィーリングオンリーでGOTO文プログラムを書いていたのだ。たぶん、想定外のトラブルに遭うたびにアドホックなIF文を追加していたに違いない。

Webアプリケーションは、たぶん皆が思っているより、ずっと設計が難しい。Webアプリケーション設計の現場は、Dijkstraが構造化プログラミングを提唱する前の状態にあるのだ。

やっぱり凄いな、Ivan Lins。凄いってことはわかってたけど、複雑・緻密で奔放・情熱だもん。