メッセージ。 - 『Joel on Software』に載っていた「漏れのある抽象化」
# 『Joel on Software』に載っていた「漏れのある抽象化」
お正月休みに『Joel on Software』を読んだ。鋭い考察をした本で、なかなか興味深かったのだけど、とくに面白かったのが「漏れのある抽象化の法則」だった。ちょっと引用してみますね。
P.221
これはほんと、慧眼だよなぁ。ぼくも昔から「プログラミングができるようになるためには、コンピュータの気持ちを理解できるようにならなければいけない」と言っていたのだけど、これではうまく説明できていない。だけど漏れのある抽象化の法則は、これを本当にうまく説明してくれている。
ちょっと前、malaさんや増井さん、荻野さんと飲んだときも同じような話になった。「初心者にも、Ruby on Railsみたいなものを教えるべきだ」、「Ruby on Railsってどこがすごいんですか? あんなの昔からありましたよ。便利なんですかねぇ?」、「簡単なことを簡単にできるようになっていて、かなりうまく抽象化してくれている」、「どの程度うまくやってくれるんでしょう?」、「……」という感じ。
漏れのある抽象化の法則は、まさしくこういった疑問に答を与えてくれる。プログラミングの本質に切り込む重要な理解だと思う。
P.221
漏れのある抽象化の法則が問題である理由の1つは、抽象化が、それが意図されているほどには私たちの生活を楽にはしてくれないことにある。誰かをC++プログラマとして鍛えていると、char*とかポインタ演算とかについて教えずに済めばいいのにと思う。すぐにSTLのstringに進むことができたらいいのに。しかしある日、彼らが"foo"+"bar"のようなコードを書いて、とても奇妙なことが起こり、私は立ち止まってchar*について教えざるを得なくなる。あるいは、彼らはあるとき「OUT LPTSTRを引数に取る」とドキュメントに書かれたWindows API関数を呼ぼうとするのだが、char*、ポインタ、Unicode、wchar_t、TCHARヘッダといった、漏れ出てくるものすべてについて学ぶまでは、その関数をどうやって呼べばいいのかさえ分からない。COMプログラミングについて教えるとき、Visual Studioのウィザードとコード生成機能の使い方について教えるだけで済めばいいのにと思う。しかし何かが上手くいかないとき、彼らには、何が起こっているのか、まったく見当が付かない。そうして私は、彼らにみんな教えなければならなくなる。IUnkownに、CLSIDに、ProgIDに……ああ、慈悲を!ASP.NETプログラミングを教えるとき、いろいろなものをダブルクリックして、それからユーザがそれをクリックしたときにサーバで走るコードを書けばいいのだと教えるだけで済めばいいのにと思う。確かにASP.NETは、ハイパーリンク(<a>)のクリックを処理するHTMLコードを書くことと、ボタンのクリックを書くことの違いを抽象化している。問題は、ASP.NETのデザイナが、HTMLにはハイパーリンクからサブミットする方法がないという事実を隠す必要があったことだ。彼らはそれができるようにするために、数行のJavaScriptを生成して、それをハイパーリンクのonClickハンドラに付けた。しかし抽象化は漏れて、エンドユーザーがJavaScriptを無効にしているとASP.NETは正しく動かない。ASP.NETが何を抽象化しているのか理解していなかったら、プログラマには何が悪いのか見当も付かない。(中略)今日、CityDeskに取り組んでいて、私が知っていなければならないことは、Visual Basic、COM、ATL、C++、InnoSetup、Internet Explorerの内部構造、正規表現、DOM、HTML、CSS、XML—いずれも、古い『K&R』にあるものに比べて高レベルのツールであるが、しかし私は依然として『K&R』に載っていることを知っている必要があり、そうでなければトラブルに見舞われる。10年前、私たちは、将来は新しいプログラミングパラダイムによってプログラミングが簡単になっているだろうと想像していた。確かに、何年にもわたって私たちが築き上げてきた抽象化は、GUIプログラミングやネットワークプログラミングのような、10年、15年前には扱う必要がなかった、ソフトウェア開発の新しいレベルの複雑さを取り扱うことを可能にしてくれた。そして、現代的なオブジェクト指向のフォームベースの言語のような素晴しいツールは、たくさんの仕事を驚くほど早く成し遂げられるようにしてくれる。しかし、ある日突然、抽象化が漏れているところで問題を解明する必要が生じ、それには2週間もかかるのだ。そして、あなたがプログラマを雇うとき、仕事のほとんどがVBプログラミングであっても、VBプログラマを雇ったのでは十分ではない。VBの抽象化が漏れているところに出会うたび、彼らはタールにはまりこんで動けなくなってしまうからだ。
これはほんと、慧眼だよなぁ。ぼくも昔から「プログラミングができるようになるためには、コンピュータの気持ちを理解できるようにならなければいけない」と言っていたのだけど、これではうまく説明できていない。だけど漏れのある抽象化の法則は、これを本当にうまく説明してくれている。
ちょっと前、malaさんや増井さん、荻野さんと飲んだときも同じような話になった。「初心者にも、Ruby on Railsみたいなものを教えるべきだ」、「Ruby on Railsってどこがすごいんですか? あんなの昔からありましたよ。便利なんですかねぇ?」、「簡単なことを簡単にできるようになっていて、かなりうまく抽象化してくれている」、「どの程度うまくやってくれるんでしょう?」、「……」という感じ。
漏れのある抽象化の法則は、まさしくこういった疑問に答を与えてくれる。プログラミングの本質に切り込む重要な理解だと思う。
Comment
Trackback
# ソフトウェア開発の思考
タイトルからお察しがつくとおり、海外の原書を和訳したテの本で … 最初は読みづらい www 。
読み終わらせたのも、途中から意地になったからなのです。
# Joel on Software