D at 20 Hits and Missesを議論する

本記事では、Walter Bright氏が D言語の良かった点・悪かった点を振り返った D at 20 Hits and Misses を参照しながら、プログラム言語のあるべき姿について、プログラマー視点で語ります。
D at 20 Hits and Misses は Walter Bright氏自身のプレゼンも Youtube で公開されています。
D言語開発の経緯とその発展については、こちらのブログ記事（日本語）が詳しいです。

20 Hits and Misses とあるけど、数えてみると20より全然多いんだよね（笑）。 我々は普段は C++ 使いで、D言語に関しては完全に門外漢なので、話せそうな内容をピックアップしてきましょう。

よろしく。

早速、最初の項目は「No Preprocessor」。

これは、プリプロセッサが無いことが良いということですか？

そう言ってるね。 実際、プリプロセッサって無い言語の方が多いんだよね。Java でも、新しい Go や Rust や Swift でも。

言われてみるとそうですね。普段 C++ を使っているので、意識しませんでした。

C++ もマクロを減らそうとする意図があるよね。inline関数とかテンプレートとか。ただし、#include や #ifdef とかは代替え手段がないから、使うしかないよね。 かなり後ろの方に「Modules」という項目があるんだけど、これはD言語が行った、#includeからの脱却だよね。

続く２つの項目は「Unicode all the way」と「Miss: Agnostically Supporting UTF-16 and UCS-2」。 現在なら UTF-8 一択だね。

D言語が登場したのは2001年なんですね。この頃にはまだ UTF-8 一択とはしにくかったかも。でも、振り返ると後悔してしまいそうですね。

続いて「2's Complement Arithmetic」。 これは C言語の回でも触れたけど、C言語が2の補数を前提としていないのは、現実的にはマイナスの作用しかないんだよね。

1の補数って教科書でしか見たことないです。符号付き整数の加算回路をどうするんだ、という話ですよね。

私も2の補数しか見たことない。 が、驚くべきことに、Youtubeのプレゼンを見ると、1の補数を見たことある人が会場に何人かいるんだよね。

一体どんな環境だったんでしょうね。

想像つかないね。

自作したPCとかかもしれないですね。

続いて「Miss: bit Data Type」。 これは C++ の std::vector<bool> でも同じことが起こってしまったよね。１つのサイズに複数の値を入れれるようにすると、ポインタを取れなくなるんで、面倒なことばっかり起こるんだよね。

std::vector<bool> の場合、std::vector<bool> だけ他の std::vector<T> と動作が変わってしまうという点もマイナスで、完全な失敗作ですね。

だいぶ飛ばして、次は「Strings are Arrays」。

これは、文字列型が無いのが良い、ということですか？

そう言っているね。

私は文字列型がある方が便利でいいと思います。strcat() ではなく +演算子で連結したいです。

まあ、次の項目に「Miss: Then We Botched It」とあるし、文字列というのは一筋縄では行かないよね。

次は続けて２項目「Built In Unittests」と「Built In Documentation Generation」。

ビルトインで提供されていると、プログラマー間のブレが少なくなるし、いいですよね。やっぱり標準が一番ですから。

Documentation Generation は誰が作っても機能として大差なさそうだけど、Unittest はセンスが出るよね。つまり、xUnit系のような仰々しいユニットテストだと、使わない人が出てくると思う。 D言語の Unittest のスペックを見る限り、極めてシンプル・軽量そうで、これならD言語を書く人はもれなく使うような、センスのある Unittest じゃないかな。

続いて「Pure Functions」。

これはいいですね！

C++のメンバ関数のconstのようなものだね。

副作用なしというのは、宣言する価値が大いにありです。 もう一押し言うと、デフォルトが pure で修飾子なしで、pure でない時に修飾子が必要な方がいいですね。副作用無しを推奨する意味で、記述量も少なくて済むようにすべきです。

おぉ、Rust方式。

Rust は非constの時は mut が必要ですが、あれは変数が対象ですからね。pure関数という言語仕様は非常に優れていると思います。

これで最後にしましょう。「Miss: Contracts」。 Contractって何だ？

「契約プログラミング」のようです。Wikipediaには、D言語をはじめ3言語が紹介されていますね。 でも、Miss ということは失敗だと振り返っているわけですよね。何が失敗だったのでしょう。

正直良くわからないけど、D言語の契約の仕組みと、手書きでassertを書いたものと、それほど差がないというのが失敗と判断した理由じゃないかな。言語仕様としてそこまでサポートしなくてもよかった、という。

プログラム界の法則を語る

プログラム界の知られている法則について、３人で語り合いました。

今日は、プログラム界の法則について話し合おうかと。

よろしくお願いします。

まず最初は「ブルックスの法則：遅れているプロジェクトに人員を投入しても、さらに遅らせるだけである」。

これは有名ですね。大学生の頃から知ってました。

それは早いね。私は会社入ってから知りました。

この法則は1970年代に提唱されているんだけど、未だに現場で見かけるよね。遅れているプロジェクトに中国人プログラマーを増員した、とか。

それ、典型的にダメなやつじゃないですか。

そもそも会社で「人月」という単語が普通に使われていたのが意外でしたね。「人月の神話」読んでないのか、となるわけで。

人月とウォーターフォールは、管理する側からは楽なんだよね。

ちょうど今、テスト駆動開発について勉強しているのですが、このやり方はソフトウェアの品質向上には効果がありますが、完成時期とかを見積もるのは確かに難しいですね。

ある程度の見積もりがないと、組織として動けないからね。

ウォーターフォールの原著について知ったのですが、原著の段階では工程が後ろに戻ることも考えられていたんですよね。

へぇ、そうなんですね。

ところが名前が悪かったのか、後ろに戻らないモデルとして知られてしまっているんですよね。

次も有名な「ムーアの法則：半導体の集積率は約２年で倍になる」。

この法則は終わりが見えてきてますけどね。

物理的な限界が来ているみたいだね。 それとは別に、モバイル機器の普及で、省電力化にもマンパワーを割いているという側面もあるみたいだけど。

物理的に限界だから省電力化に力を入れてる、という話なのかと。他に、ターボブーストなどの技術向上があったのも、同じような事情だと思いますね。

そんな感じですね。

一方、GPUのグラフィカル能力というのは、ハード的にもソフト的にも、近年まだまだすごい向上があったんですよ。この分野はまだムーアの法則の限界は来てないですね。

続いて、「ヴィルトの法則：ソフトウェアは、ハードウェアが高速化するより急速に低速化する」。

これは初耳です。ソフトウェアがどんどん大きくなっていく、ということですか？

そうそう。OSの起動時間とかプロセスの起動時間とかが、ハードウェアの進化ほども速くなってないのは、ソフトが肥大化してるから、ということ。

ソフトウェアの抽象化とかが入ると、アセンブリレベルとは規模が違ってきますからねぇ。

続いて「ダイクストラの箴言：プログラムテストは、バグが存在することを証明するには有用だが、バグが存在しないことを示すには絶望的に不適切である」。

悪魔の証明ですもんね。

さっき言ったテスト駆動開発の本では、テスト駆動開発はあくまで設計のための手法である、と強調されてました。万全のテストを書くというのは事実上不可能なのでしょうね。 個人的には、ソフトウェアでできてしまうことを減らすことが、バグを減らすの良い方策と考えています。

確かに。マーフィーの法則じゃないけど、最悪のことって起こってしまうんですよね。なので、動作から抑え込んでしまうのは有効だと思います。

ところで、グラフィック系のテストってどうやるんですか？

便利なデバッグツールとかはありますけど、リグレッションテストとなると難しいですね。やはり最後は目視が必要となるので。

さらにソフトウェアの法則じゃないけど「ハインリッヒの法則：1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する」。 1つバグが見つかったら他に29個はあると思った方が良い、ということだね。

車の運転をしてて思うのは、小さなことが複数重なって重大事故になるんじゃないかな、と。なので、実質無害そうなバグでも、修正していくことに意味はあると思いますね。

グーグルのテスターだった人が書いた本を読んだのですが、テスターの人は設計段階から関わるらしく、テストで潰せる所は潰してしまう、という思想が感じられました。