記事書いたっすよ!
今日発売の「Software Design」誌に11ページもD言語の記事を書いた。はっきり言って書きすぎである。
ここ半年間はD言語の先見性に惹かれ、毎日いろいろといじってみる日々であった。
しかし、結局のところは、またC++(あるいはJavaやC#)での開発に戻らねばならないと痛感している。これは、D言語の未成熟さもあるが、それ以前の問題として、携帯を始めとしてC++やJavaを使わなければならない状況というのは依然として存在するからである。
どの言語が優れているかとかそういう問題ではなく、その携帯端末ではJavaしか動かなかったり、韓国人に作ったパチモンのCしか動かなかったりと、まあそういった状況だからである。
それにしても、C++の言語デザインは忌むべきものだと思う。「Effective C++」や「More Effective C++」、あるいは「Modern C++ Design」、あと「Effective STL」有名なのが、この4冊。あとARM(The Annotated C++ Reference Manual:注解C++リファレンスマニュアル)、それからFDIS(C++ Final Draft International Standard) ついでに「Exceptional C++」とか「More Exceptional C++」とかもか。
プロのまともなC++プログラマならば、これらをすべて読んでいて然りだし、少なくともFDIS以外は精読していて然りである。
そうは思うものの、いま「Effective C++」やら何やらを読み返してみると、ホント頭悪いなぁと思う。もちろん「Modern C++ Design」もだ。書いている人が頭が悪いと言っているのではない。こんな解説書が必要になり、また必須であると思われている状況が、もうどうしようもなくやるせなくなるのだ。こんな解説書が必要になるというのはC++の言語デザインの悪さゆえなのに。
「Modern C++ Design」を知らずしてテンプレートを語るなと言われる。確かにそうかも知れない。この本以前のテンプレート批判は本当に的はずれだった。かと言って、「Modern C++ Design」が珠玉のテクニック集か何かと思われている雰囲気、これがもうたまらない。
はっきり言って、こんなテクニックを理解する時間があれば、まともなコンパイラが実装できるのに。そっちのほうが、何倍も有益で、普遍的なものなのに。
などといつも思うのだが、自作のpreprocessorというのは(作るのは簡単だが)それはそれでまたいろいろ問題がある。C++やJavaでは外部ツールでの言語拡張を想定していないということだ。たとえばAspectJと、この自作のpreprocessorを組み合わせるとどうなるか?そもそも組み合わさるのか?EPP*1などはこの問題をうまく回避している。
このへんについて詳しいことは、C++/C#/Javaで共通して使えるシュゴー(゜Д゜)なpreprocessorを作ってからまた書くことにする。