論理的思考と芸術的創造
例の考えずにプログラムを書くという話について、わたしは当該記事の続きもちゃんと読んでないし、反応を詳細に見たわけではないから、似たようなことを言っている人がいるのかもしれないけれど、あそこで登さんが書いていることは Paul Graham に似ているなあ、と思った。
どこで書いてたっけ?って思ったんだけど、あれだった、「ハッカーと画家」。
ハッカーは科学者よりももの創りに似ているのだから、メタファーを探すのは科学者よりも他のもの創りの分野からの方が良い。絵を描くことは、ハッキングに対して他にどんなことを教えてくれるだろうか。 >
絵画の例からひとつ学べること、少なくとも確認できることは、ハックをどうやって学んだら良いかということだ。絵を描くことは、絵を描きながら学ぶ。大抵のハッカーは、大学のプログラミングコースを履修してハックを学ぶのではない。13歳の頃から自分でプログラムを書くことによって学ぶのだ。
とか、
絵画から学べるもうひとつの例は、次第に詳細化しながら創ってゆく方法だ。絵画はたいてい、スケッチから始まる。そして次第に細かい部分が埋められてゆく。だがそれは、単に隙間を埋めてゆくだけの過程ではない。ときには元の計画が間違いだったことが分かることもある。 X線で見てみると、手や足の位置が動かされたり表情が変えられたりしている絵画は数え切れないくらいある。 >
この点で絵画から学ぶことができる。私はハッキングもそうあるべきだと思う。プログラムの仕様が完璧であるなんて期待するのは非現実的だ。そのことをまず最初に認めて、仕様がプログラムを書いている最中に変わっていっても、それを受け入れられるような書き方をすべきなんだ。
とか、
ハッカーが単なる実装者で、仕様をコードに直しているだけなら、溝を掘る作業者みたいに端から別の端まで順番に仕上げてゆくだろう。でもハッカーが創造者ならば、インスピレーションを考えに入れなければならない。 >
ハッキングには、絵を描く時と同じように、周期がある。ある時は新しいプロジェクトに夢中になって、1日16時間それをやり続ける。別の時には何も面白いと感じられない。
とか、うむ、引用してみるとまるっきり逆だな(笑)。
彼の文章を読んで思ったのは、プログラミングについてイメージを広げるってことなんだろうな、ということだ。あそこをああして、ここをこうして、ここはたぶんこうなるとできる、みたいなイメージを持つこと。あとはそのイメージを書き下していけばいい……のだが、そのとき細部は少しずつ変化し、細かい部分が埋められていくように書かれる。そういう意味で同じことを言ってるんじゃないかなあ……と思ったんだけど、思ったほど似たことは書いたなかった、かな。