2010/12/12
マイナー言語でお仕事
これすんごくおもしろい。
実用規模で使ったときにどんな感じかなあ、っていうのは、 試しに触ってる時の感触と違うことが多いから、 複数言語のバックグラウンドを持つ人による現場での体験談はとても参考になる。
オフサイドルールについて:
もうおじさんはこれだけ行が離れると横の位置が同じかどうか目がチカチカしてわかりません。
この目のチカチカを避けるためか、どうか、出来るだけ間隙を狭くするために、Haskellプログラマーは無意識にワンライナーになります。例えば上の例だと 2 のケースをだらだらーと一行に書きたがるのですね。その結果、一行500文字の Haskellコードなどが産み出されるのです。
わはは。
Common Lisp書いてるとなぜかSchemeに比べて一関数がどうも長くなりがちで、 やっぱり木構造の次のノードが上下に離れて見づらくなる。 C-M-SPC C-M-\ による自動インデントと C-M-f C-M-b による移動で 確認してる感じ。これが完全自動で使えないとちょっと辛いだろうなあ。
Haskellのtype classによるオーバロードはかっこいいなあと思ってたんだけど、 強力な型機能と組み合わさると、意図しないコードでも型検査を通ってしまって 見つけるのが厄介なバグになる、意外な落とし穴、というにのはへぇ〜と感心。
基本的に強静的型付に慣れたプログラマの心は、型システムに依存しすぎているため、一旦型システムを突破してしまったこういうバグに対し非常に脆弱です。もし Haskell の型システムがここまで強力ではなく、IO a と [a] での >> の多重定義が無ければ、事前に型エラーとしてレポートされていたのですが…
最後の、Haskellプログラマは個人プレーヤーとして最適化されてるので 3人集まると船頭が山に登る危険が、というのはこれはLisp界でも とてもよく見られる現象だなあ。
Lispで仕事が出来たからって全てがバラ色になるわけじゃないってのもまた然り。 実用プログラムは泥臭い現実を相手にしてるんだから、 どんな言語で書いたって泥水の沼を進むようなものになるのは避けがたい。 ただまあ、沼に突っ込んでゆく装備にはいろいろあるよね、ってわけで。
Tags: Programming, Lisp, Haskell, OCaml
Post a comment