ハッカーと画家
ポール・グレアムのハッカーと画家を買ったので、岡山に行く新幹線の中でゆっくり読んだ。
後半からおもしろそうな内容になってたので、最初の章を読んだ後は中盤を飛ばして、後半を中心に読んでみた。
10章「プログラミング言語入門」あたりから著者のプログラミング、言語に対して思っていることをずばずば書いてあって、、おもしろい。
よく出てきた言葉に、「言語は等価じゃない」って言葉が印象的。チューリング完全な言語であるなら、任意のアルゴリズムを書くことができる。でも、それだけじゃ等価とは言えないよね。
確かにアセンブリとJavaとを考えたらどっちの言語つかってもいいんじゃない?とは言えないなーと。言語の力は、プログラマの生産性を飛躍的に高めるし、もし力のない言語をつかっているなら、力のある言語を使ってる人にはいつまでたっても勝てないよ、て感じのことも言っていた。
本の中でも、この本はLispを勉強している人の背中を押すための本だって書いてあったけど、まさにそんな感じ。Lispは他の言語にくらべてこんなにすごいんだぜってのをすごい言ってるから、あ、Lisp勉強してて損はなかったーと思わせるw
その中で、マクロの話も出てたんだけど。ちょっと引用
LispのプログラムコードはLispのデータオブジェクトからできている。それは、ソースコードは文字で出来ていて、文字列は言語でサポートされている、というつまらない意味じゃない。
ん?っと思ったが、
Lispのコードは、ひとたびパーザによって読まれたら、あなたが解析することができるデータ構造になるんだ。・・略
他の言語ならコンパイラが構文解析して内部に作られる構文木を、Lispでは直接プログラムとして書き下すわけだ。しかも、この構文木はプログラムからアクセスできるから、構文木自身を操作するプログラムを書くことができる。Lispではそのようなプログラムをマクロと呼ぶ。いわば、プログラムを生成するプログラムだ。
通常(CやJava)「1 + 2」と書くところをLispでは次のように書くけど、
(+ 1 2)
これは、ポーランド記法そのままなんだね。
ポーランド記法 - Wikipedia
ってことは、普通の言語はコンパイルするときいったん構文木を作って・・・とかやってるところをLispでは構文木そのもの(?)を直接コーディングしているようなものだよね。
まだ、漠然とだけど、、プログラムを生成するプログラム(マクロ)ってのを書けそうな気がしてきた(笑)
LispっぽいRubyがなぜマクロを採用しないのか、という記事(ではないが)を見つけた。
Matzにっき(2003-09-15)
マクロはS式(あの括弧)と強く結びついてるってのは、さっきの引用を読んでそうなのかもと思った。
S式はロジック記述しにくいってのはそうなのかな?どうしてもマクロでなければできないことというのは実はあまり無いってのは、、Matz氏が言うから(?)そうなのかもね。
ま、とは言え、やってみん事には何とも言えないので、やってみる。
あと、本の話に戻るけど、13章「オタク野郎の復讐」の最後にある以下の内容が非常に印象的。
例えば、オブジェクト指向の世界では非常によく「パターン」というのを耳にするだろう。この「パターン」は多くの場合、(c)のケース、すなわち人間コンパイラが実際に動作している証拠なんじゃないかと思う*9。
そして、この*9には以下のような注釈が
ピーター・ノーヴィッグは『デザインパターン』に挙げられた23のパターンのウチ16はLispでは「全く見えないか、あるいは簡潔である」ことを見出した(www.norvig.com/design-patterns)。
ほんとか?!英語訳せるかな。これが、ホントならLispはすげーんじゃない?今まで思ってたパターンの考え方が変わってくるね。
ホントかどうかは実際にLispを使って試してみよう。
しかし、、プログラマーはこの本読むべし。Lisp知らなくても面白いはず。世界が広がる感じがする。
でも、読んだ人はLispを勉強して本にかいてあることがホントかウソか検証してほしい。
ま、
ウソだっていいじゃないか。取り合えずやってみよう。