最初にさらっと書いた効率の悪いプログラムを、数学的帰納法を使い、プログラムを変形し、メモリ消費の少ない、実行スピードの速いコードにしていくところは、おお、素晴らしいと感動した。法でも、それよりずっと少ない割合のプログラマがやっている、プロファイラでプロファイリングしてホットスポットを書き換える方法でもないが、数学的に正しい変形をしていくことで、元のプログラムの意味は変えず、効率だけがアップしていく。この部分の訳注では、原書は、日本人にはわかりにくい数学的帰納法の使い方なので、著者の許可を得て書き直したなどということが書いてあった。それで、この前、Haskellナイトに行ったときに、和彦君に訊いたの。イギリスじゃ、日本とは違う数学的帰納法の教え方をしているの?」と。すると、「イギリスでも日本と同じ数学的帰納法の教え方だが、原書のやり方は、逆適用が多くてわかりにくかったので、書き直した」ということだった。大体、訳者まえがきに、内容の変更を快く許諾してくれてありがとう、著者のHuttonさんに感謝などと書いてあるから、何かなとは思っていた。文の間違いを直すのに、わざわざそんなこと書かないからね。Haskellは遅延評価による無限リストがリスト内包表記で簡単に使えるので有名。コード例で、無限リストが使えると、なるほど、話が簡単になるなと思う例はあれこれあったが、一番ウケたのが、長さがバラバラのビット列をある桁のビット列に揃えるコード。渡されたビット列の後ろに、無限に0が続くビット列を無限リストでくっつけて、頭から揃えたい桁だけビット列を取るだけ。好きなだけ食っていいというバイキング、ビュッフェ(ブッフェ)だね。日本語なら、食べ放題、食い放題。よし、今後は無限リストを使ったプログラミングを「食べ放題プログラミング」と命名することを、本日、閣議決定します。\(^O^)/本書をじっくり読みつつ、手を動かしてコード例を試して行くと、Haskellでのプログラミング感覚がつかめるようになると思う。そのときに、問題になるのが、本書で使われているコード例の記号。くっついた記号になっている。いう例をさらにいくつか並べると、等しくないは「≠」、条件の「かつ」と「または」は、「∧」と「∨」、否定は「¬」になっている。これらは、JISの漢字コードにはあるが、ASCIIにはないから、「≠」は「/=」、「∧」は「&&」、「∨」は「||」、「¬」は「not」と入力しないといけない。親切なことに、付録Bには、記号表がついているから、それをみて入力すればいいし、この程度はすぐ覚えるから大した手間ではない。それに、前述のhttp://www.cs.nott.ac.uk/~gmh/book.html原書サポートページに行けば、コードもあるわけだし。思っていたら、世間的にはそうじゃないのね。Haskellナイトでも話題になったが、和彦君は、この表記はTwitterで評判が悪いといってたし、山下さんも、やっぱ、そのまま素直に入力したいでしょうねなどといっていた。変換の手間なんて大したことではないし、とにかく、本として読むときに読みやすく、きれいで、美しい。本書を読んで目がこれに慣れると、他の本やネットに転がっているASCIIだけで書いたHaskellのコードが汚くみえてしょうがない。自分でも驚くのだが、全く同じコードでも、ASCIIによるコードは、貧相で貧乏くさく、出来の悪いコード、腐ったコードにみえる。逆に、本書の表記によるコードのほうが高級で立派であり、出来のいいコードにみえる。ベストセラーになった「人は見た目が9割」にならえば、「コードは見た目が9割」を実感した。\(^O^)/おれ、こんなに簡単に見た目に左右されるんだ、情動を操作されるんだと、それに驚いた。変数名に使えるといいね。x''とダッシュを使うことが多い。変数名に使えないから、x'といった変数が使えない。はあ、おれも大学でプログラミングを習い始めたとき、数学と違う記法にいろいろ違和感を感じたはずなのに、今回、改めて、すっかり既存のプログラミング言語の記法が染みついちゃってる自分を発見した次第。関数名や変数名に使えるが、積極的に使ってる様子はない。LispはコードがS式だから、どう転んでも数学的な表記にはみえないしね(爆)。活躍の場が多いんだなと思った。編集者の鹿野さんが、がんばったなあと思うのは、Haskellナイトでも強調していたが、上製本のように机に開きっぱなしにして読める製本になっていること。読み飛ばす本じゃないから、じっくり読んでほしい。そのために、パタンと本が閉じないようになっている。電子出版ではなく、紙で出版する意味は何か。読者のために、一体、何をやれるか。それを考えた結果がこの製本。それだけじっくり読み込んでほしいという編集者の熱い思い、心意気を感じるね。編集者の心意気といえば、値段のこと。原書は、出版当初、80ドル以上していたそうな。アメリカは日本と違って、書籍の再販価格維持制度がないから、人気がなくなれば、在庫を減らすためにどんどん値下げする。いま、本家Amazonでは、42.32ドル。いまは14年ぶりに1ドル=85円くらいの超円高になって騒ぎになっているが、それで換算しても、3597.2円。ところが、本書の値段は、驚きの2800円(税抜き)。編集者としては、「持ってけ、泥棒!」の心境だろうが、それだけ、多くの日本のプログラマに読んでもらい、プログラミングという知的作業のレベルを引き上げてほしいという熱い思い、心意気なんだね。値段に関しては、Haskellナイトで面白い話があった。驚きの3990円(税込み)。(Author)は、いま、42.33ドルだから1ドル=85円の超円高で換算すれば3598.05円。本のアマゾンでは、いま、4629円。720ページの本で、翻訳やらもろもろのコストを考えると、これもかなりの「持ってけ、泥棒!」状態。鹿野さん、当初は、「プログラミングHaskell」は、内容からして8000円にしたいと思ったそうだが、そうもいかないだろうから、4000円くらいかななどと思っていたらしい。Haskell」が4000円しないのに、それより同じか高くして売れるわけがない。清水の舞台から飛び降りた。鹿野さんと赤池さん、ステージで、「お互い大変でしたねぇ」と慰め合っていた。恐るべし、デフレ・スパイラル。\(^O^)/幸せなる哉。Rubyなどの手続き型(命令型)言語と違って、HaskellやLispのような関数型言語(Lispは不純だけど(笑))、あるいはPrologのような論理型言語は、手順はいちいち書かなくても、関数型言語なら、こういう入力があればこういう出力になるという仕様、論理型なら、こういう事実とこういう推論規則があれば結果が出るという仕様を書くのが人間の仕事で、あとはコンピュータがやってくれるように言語が作られている。少なくとも、それを目指している。蔽が大きな威力を発揮する。抽象的なところをきっちり書けば、手続き型言語で書かなければならなかった世俗の下々のことは考えなくていいよというのが、基本路線(実際はなかなかそうは行かないんだけど)。プログラマはどんどんバカになるというわけ。抽象的に考えて、仕様をきっちり記述するというのが苦手。数学や論理学がもろに出てきて、どうも苦手などという。そこが、関数型言語や論理型言語が難しいと一般のプログラマが感じるところだが、でもね、手続き型言語に慣れる前の状態。学校の数学しか知らなかったころに戻れば、案外理解しやすいと思うよ。仕事のコードをHaskellで書かなくても、一度、こういう言語をやっておくと、ちゃんと御利益があって、まず、仕様をきっちり考えるようになる。入力パラメータに許される事前条件は何か、不変条件は何か、出力には何が出るか、その値の範囲は何かといった事後条件とかね。やって、仕様をきっちり考えるようになれば、バグも大幅に減る。語を離れていえば、仕様記述の世界。