なぜいまだにシステムプログラミングはCなのか

Programming Language Challenges in Systems Codes

システムコードにおけるプログラミング言語の挑戦、あるいは、なぜいまだにシステムプログラミングはCなのか。

著者がJonathan Shapiroであることが興味深い。Jonathan ShapiroはD&Eに頻出する名前である。Bjarne Stroustrupの記述からして、初期のC++の設計に多大な影響を与えた人物である。それに、最初にC++を使って本格的で大規模なプロジェクトを始めたのも、Jonathan Shapiroだ。しかし、今日、Jonathan Shapiroの名前はC++界では、あまり有名ではない。私はMLとかHaskellなどの言語には疎いので、この方面の話は知らなかった。

なぜシステム・プログラミングは、いまだに1970年代に開発された大昔の高級アセンブリ言語で書かれているのか。自動的に検証可能でガベコレもあってsound typeな、つまりプログラマーが直接にコードを書かずとも、条件を指定するだけで、自動的にチェックを生成してくれるような、そういう言語にとってかわらないのかという問題を考えている。

クライアントサイドでは、新しいプログラミング言語が頻繁に生まれ、一定の成功をおさめている。しかし、ことシステムプログラミングに関しては、プログラマーが直接管理できる言語が、依然として必要なのだそうだ。pre conditionやpost conditionの条件を記述すれば、自動的に検証してくれるような言語を作ろうとしたところで、そもそもシステムプログラミングでは、そのような方法で条件を記述することすら難しいのだそうである。加えてハードウェアの特性が、GCなどの高級な機能ではパフォーマンスが得られない。

インタラクティブなトラフィックにおいては、FoxNetは、当時のUNIX実装に比べて、0.00007倍のパフォーマンスを達成した。これはtypoではない。最も容易に実装できる例ですら、FoxNetはCによるネットワーク実装に比べて、11倍ものCPUロードを必要としたのである。

その後の改良で結果が向上したものの、今のUNIXの実装も当時よりさらに高速になっている。

何故こういう結果になるかというと、ハードウェアの都合上、データは正しくアライメントされていなければならなかったり、またCでは詳細なデータ構造とそのメモリ管理を手動で行うことができるからである。

2006年の結論として、結局CやC++には勝てないということである。2012年の現代でも結論は同じだろう。