この一週間、ずっとC++のname lookupのことを考えていた。その前の一週間も、やはり、name lookupについて、思いを巡らせていた。一体、name lookupを、どうやって説明すればいいのだろう。
C++本の執筆が、全く進まない。困った。
name lookupについては、理解している。理解はしているものの、これを説明することは難しい。
今までも、このブログで、C++について、色々と書いてきた。ブログに書くのは、簡単だ。というのも、書いた内容に責任を負わなくていいからだ。それに、間違っていれば、あとからいくらでも書き直せる。しかし本に書くのは、難しい。
単に、ブログは無料で、本は金を取るからなどという理由ではない。私の書いた本は、一般の流通に乗り、全国の書店の店頭に並ぶ。私の知る限り、今現在、C++0xの参考書を書いている他の人は、いないはずだ。入門書なら、いくらでも出版されるだろうが、今私が書いているような、言語の詳細を説明する本を書いている人は、いないはずだ。
ひとたび印刷された本は、書き換えることができない。責任は重大である。下手なことを書く事はできない。
しかし、こんな完璧主義を続けていたのでは、いつまでたっても本は完成しない。結局、どこかで妥協しなければならないわけだ。
規格を読めないのは、英語がわからないからであり、むしろ、規格の日本語訳をするべきであるという意見もある。しかし、それは間違っている。規格がどの言語で書かれているかなどということは、些細な問題だ。日本語だろうが、英語だろうが、スワヒリ語だろうが、たとえ規格が日本語で書かれていても、問題は変わらない。
思うに、世の中には、完全なものは存在しない。完全を求めるのは不可能だ。かのBjarne Stroustrupでさえ、C++のすべてを理解してはいないのだ。Stroustrupが、C++についてわからないことがあればどうするか。彼は、規格や、自分の著作を参照する。彼の言によれば、「C++の詳細な定義を、完全に丸暗記するのは無駄である。それよりも、もっと現実的なことに、労力を割くべきである」ということだそうだ。
もはや、この問題に直面して、二週間になる。いや、去年から、このおそれはあった。これ以上、執筆を続けるためには、ここで妥協というものをしなければならない。
C++の標準規格でさえ、妥協をしている。C++の標準規格が制定されるときというのは、皆が、「この規格は、もはや、ある程度使えるようになった」と妥協した時である。この妥協は、1998年に起こり、最初の標準規格が制定された。その後、その妥協した産物である規格には、多くのツッコミが入った。
もし、完全なものがあるとすれば、それは、それ以上変更する必要がないはずだ。C++自体でさえ、完全ではないのに、どうして完全な参考書が書けようか。
中国の伝説では、昔、ある皇帝が、完全な本というものを書かしめて、誰でも読めるように、公共の場所に置き、「この本に、一字をも、付け加え、または取り除くことのできるものがあれば、誰でも自由に申し出よ」と宣言したという。詳しいことは忘れたが、確か、こういう話があったはずだ。いま、出典が思い出せない。誰かご存じの方は知らせてください。
4 comments:
最後の逸話は呂氏春秋ですね。
http://ja.wikipedia.org/wiki/%E5%91%82%E4%B8%8D%E9%9F%8B#.E4.B8.80.E5.AD.97.E5.8D.83.E9.87.91
何かプログラミング作業に通ずるものがある話ですね。
どうしても取れないバグが一つあって、それをやっとの思いで潰すと今度は
二つ新しいバグが出てくる。
プログラミングの現場ではオブジェクト指向を使ってバグの発生確率を大幅に
下げたりバグの原因を突き止めやすくしていますが、思考の面でそれをやろうと
すればKJ法が有利です。
http://ja.wikipedia.org/wiki/KJ%E6%B3%95
これは歴史のある叙述方法で、膨大なデータを綺麗にまとめ上げる時に圧倒的な
効率を発揮します。
http://www.vector.co.jp/soft/win95/writing/se093192.html
http://www.vector.co.jp/soft/win95/writing/se136782.html
http://www.vector.co.jp/soft/win95/writing/se081696.html
こんなKJエディタがフリーソフトで出ています。
他にもいろいろ出ているようです。
ああ、呂氏春秋でしたか。
Post a Comment