imk-1.16 リリース

昨日 imk-1.15 をリリースしたばかりですが、致命的なデグレが見つかったので imk-1.16 を緊急リリースしました。β 版を常用している方は、アップデートのほどよろしくお願いします。ご迷惑をおかけしてすみません。

http://sourceforge.jp/projects/aquaskk/releases/?package_id=4098

imk-1.15 で文字の出力方式を見直した影響で、促音を連続して入力できなかったり、文字種変更やトグル変換でおかしな状態になっていました。さっさとテストを書けばいいのですが、なかなか気が乗らない。困ったものです。

Programming 読書日記 & C++0x

不定期にブランクを挟みつつ、Chapter 25 Embedded Systems Programming まで読み進めました。Predictability が重要とか、メモリ分断化の基本的な回避策とかそういった内容。

C++0x については先頃、Concepts が削られるという大きなニュースがありましたが、Concepts 以外にも素晴しい改善が盛り沢山なので、個人的にはちょっと残念という程度。ただ、これまで気の遠くなるような議論を積み重ねてきた標準化委員会の面々にとっては、燃え尽き症候群やモチベーションの維持が心配です。DDJ には Bjarne Stroustrup 自ら経緯を説明した記事が載りました。

http://www.ddj.com/cpp/218600111

会議当日、Bjarne Stroustrup は当初 Concepts を修正する案を推していたものの、最終的には Concepts の削除に同意したとあります。

I and others preferred the first alternative ("fix and ship") and considered it feasible. However, a large majority of the committee disagreed and chose the second alternative ("yank and ship," renaming it "decoupling"). In my opinion, both are better than the third alternative ("status quo"). My interpretation of that vote is that given the disagreement among proponents of "concepts," the whole idea seemed controversial to some, some were already worried about the ambitious schedule for C++0x (and, unfairly IMO, blamed "concepts"), and some were never enthusiastic about "concepts." Given that, "fixing concepts" ceased to be a realistic option. Essentially, all expressed support for "concepts," just "later" and "eventually." I warned that a long delay was inevitable if we removed "concepts" now because in the absence of schedule pressures, essentially all design decisions will be re-evaluated.

Surprisingly (maybe), there were no technical presentations and discussions about "concepts" in Frankfurt. The discussion focused on timing and my impression is that the vote was decided primarily on timing concerns.

Please don't condemn the committee for being cautious. This was not a "Bjarne vs. the committee fight," but a discussion trying to balance a multitude of serious concerns. I and others are disappointed that we didn't take the opportunity of "fix and ship," but C++ is not an experimental academic language. Unless members are convinced that the risks for doing harm to production code are very low, they must oppose. Collectively, the committee is responsible for billions of lines of code. For example, lack of adoption of C++0x or long-term continued use of unconstrained templates in the presence of "concepts" would lead to a split of the C++ community into separate sub-communities. Thus, a poor "concept" design could be worse than no "concepts." Given the choice between the two, I too voted for removal. I prefer a setback to a likely disaster.

意訳：

私と何人かは最初の案(Concepts を直してリリース)を推し、実現可能だと見ていた。しかし、大多数の委員は反対し、二番目の案(Concepts を削除してリリース)を選んだ。個人的には、どちらの案も三番目の案(現状維持)よりマシに思えた。Concepts を提案した複数の委員の間でも意見が割れるという状況のもと、全体的に認められないという人、早くもスケジュールの遅延を心配をする人(それを不当に Concepts のせいにして)、Concepts について冷淡な人、といったスタンスの違いを感じる中での投票だった。結果、「Concepts を直す」案が負けた。基本的に全ての委員が、Concepts のリリースをただ単に遅らせるということを、最終的に選んだ。Concepts を削除したら、締切のない状態で言語設計を見直すことになるため、大幅な遅延に繋がると私は警告した。

意外なことに(おそらく)、フランクフルト会議では Concepts に関する技術的なプレゼンや議論は全くなかった。議論はリリース時期を主題にして行なわれ、私の印象では、リリース時期を決める投票という側面が大きかったように思う。

委員会が慎重だからと言って、責めないで欲しい。これは "Bjarne 対 標準化委員会の争い" ではなく、様々な検討要素の間でバランスを取る議論なのだ。私と何人かの委員は「直してリリース」する案を採択できずに落胆したが、C++ は実験的な学術言語ではない。現場のコードを傷つけるリスクが非常に低いと確信できなければ、委員は反対しなければならない。まとめれば数億行にも上るコードについて、標準化委員会は責任を負っている。仮に、C++0x が普及しなかったり、Concepts を目の前にして非制約的なテンプレートの利用が長期間続くとしたら、C++ コミュニティの分断を招いてしまうだろう。つまり、不完全な Concepts の設計は Concepts がないことよりも悪い。この状況で、私もまた Concepts の削除に賛成した。破滅よりも後退のほうが好ましい。

いやはやなんともまあタフな会議の様子が目に浮びます。体に気をつけてなんとか頑張って欲しいです。