Technology Review: なぜ多くのソフトウェアはそんなに粗悪なのでしょうか?

Bjarne Stroustrup: 良いものもあります。Mars Rovers、 Google、 Human、 Genome Projectは高品質なソフトウェアです。15年前、こういうものを作るのは不可能だと思われていました。技術文明はソフトウェアに依存しているので、ソフトウェアがそんなにダメだったら我々はとうに滅びていたでしょう。

他方で、"平均的な"コードを見ると私はぞっとします。構造はひどいし、明らかにプログラマーは正しさやアルゴリズムやデータ構造、保全性について深く考えていません。多くの人は実際のところコードを読むことはなく、Internet ExplorerやWindowsが「フリーズ」するたびに電話で助けを求めたり、新聞でコンピュータウィルスについての記事を読んで戦慄してみたりするだけです。

真の問題は、我々ソフトウェア開発者がいつも緊急事態にあり、仕事を成し遂げるために藁にもすがろうとしていることです。我々は試行錯誤や力業の過度の使用や数多くのテストによって多くの場合そこそこの成功を得ることができますが、しばしばそれは十分ではありません。

ソフトウェア開発者は信頼性の低い部品からそこそこ信頼性のあるシステムを組み上げるという難しい芸当に熟達してしまいました。問題は、我々がしばしば自分でどうやったのかを正確に理解していないことです。(試行錯誤の結果)システムがなんとなく最低限受容可能なものになった、といった感じに。個人的には私はシステムがいつ動き、なぜ動くのかを理解していたほうが良いと思っています。

TR: どうやったら我々が置かれているこのひどい状態を修復できるでしょうか?

BS: 理論的には、答えは単純です。開発者を教育してより適切なデザイン方法を用い、柔軟で長期間の使用に耐えるようなデザインをするのです。正しく堅固で安全なシステムに正当に報い、いい加減な仕事を罰することです。

現実ではそれは不可能です。粗悪でバグのあるソフトを供給する開発者が報酬を受けます。なぜなら人々が新しいいかしたガジェットを求めるからです。彼らは不便を嫌い、コンピュータの使い方を学ぼうとはせず、配達が遅れることを嫌い、品質のために余分な金をかけようとはかけたがりません(品質の違いが明瞭に分かる時以外は、あるいはそういう場合でさえ)。従ってユーザが変わらない限り、ソフトウェア業者が変わることはなさそうです。

コーヒーマシンから会計システムまで全てをプログラミングしなおす間世界を停止させておくというわけにはいきません。だからといって、ただいきあたりばったりでやっていくのも高くつき、危険で、気が滅入るものです。本質的な改革が必要なのです。そして、それは徐々に進めるしかありません。改革は広範なものでなくてはならず、単一の変化だけでは無意味です。

1つの問題は、理論の弊害です。万能薬と思われていることが多過ぎます。より良いデザイン手法、より良い仕様策定技術、よりよいテスト技術、より良いOS、より良いミドルウェアインフラストラクチャー、より良いアプリケーションドメイン、データ構造やアルゴリズムに対するより深い理解といったものが役に立つと思われています。例えば、タイプ理論、モデルベース開発、形式的方法がいくつかの分野で重要であると考えられてます。しかし、大きなプロジェクトにおいて、他のアプローチの代替物として使われるだけでは失敗に終わるだけです。人々は自分たちが知っているものやうまくいくと知っているものを使おうとします。「他にどんな方法があるんだ?」と言って。しかし、要求とリソースをバランスさせるために必要な技術的な成熟度を持ち合わせている人はほとんどいません。

TR: C++には、効率的なコードと引き換えにプログラマーに負担を要求するというコンセプトがあったと思います。ベル研究所は、限られたごく有能な人が、あまり速くなかったElectronic Switching Systems (ESS)のようなコンピュータ上で走らせるコードを書くための言語を求めました。今日では、たくさんのソフトウェア開発者がおり、コンピュータはとても高速です。このことによってC++を使う価値は下がったでしょうか?

BS: C++は特に大型スイッチングマシン用というわけではなく極めて広い種類に渡るアプリケーションを開発するためにデザインされました。ベル研究所では、あらゆる種類のコンピュータやOSを使うあらゆる規模の、多岐に渡る興味深いプロジェクトが生まれました。しかし、確かにベル研究所の平均的プログラマーは多くの人が考える「平均的プログラマー」よりははるかに有能であり、信頼性や高速性は(この順序で)他の場所で考えられるよりははるかに重要視されていました。

高速性は、私が興味あるアプリケーションの多くでは依然として重要課題でした。インターフェイスの応答性、アプリケーションの起動と終了にかかる時間といったものです。ソフトウェア開発者は現代のコンピュータハードウェアの驚くべき性能を、何層もの手の込み過ぎた[ソフトウェア上の]抽象化によって相殺してしまいました。ハードウェアの線形な高速化は限界に達したようですが、多くの場合、奪われたかなりの「計算時間」をソフトウェアから取り戻す余地が残されています。

正規教育によって平均的プログラマーにC++が習得されることが実質的に少なくなった折りには(?)、C++はあまりにも「エキスパート向け」になってしまった、と言われました。しかし、解決法はプログラミング言語を大衆化することではなく、より多様なプログラミング言語を用い、より多くのエキスパートを育てることなのです。そういったエキスパートが使うための言語が存在する必要があり、C++はその一つなのです。

TR: 振り返ってみて、C++のデザインにおいて、開発効率、セキュリティ、そしてソフトウェアの信頼性を実行時の高速性と引き換えにするという選択は根本的な間違いではありませんでしたか?

BS: 私がそういうトレードオフを行ったとは考えていません。私はエレガントで効率的なコードを求めました。これらの対立(効率性対プログラミング時間、効率性対(プログラミングの)ハイレベルさ、など)はまやかしです。

私のしたことは、C++をまず第一にシステムプログラミング用言語としてデザインすることです。私はデバイスドライバや、組込みシステムや、ハードウェアを直接制御するコードを書けるようになりたかったのです。次に、私はC++をツールをデザインするのに適した言語にしたいと思いました。それには柔軟性と高速性だけでなくエレガントなインターフェイスを表現するための能力が必要でした。私の考えは、ハイレベルなことをするためには、つまり完成されたアプリケーションを構築するためには、まず適当な抽象化を実現してくれるライブラリを買うか開発するか借りるかする必要があるということです。人々がC++ではまるとき、真の問題はしばしば彼らが適切なライブラリを持たないか見つけられないということにあります。

他の言語はより直接的にハイレベルアプリケーションをサポートしようとしました。それはうまくいきますが、しばしばその目的のために特化してしまうことになります。個人的には、私は自分がやりたいことだけができるようなツールをデザインすることはしません。私は汎用性を目指しています。

TR: C++が多くのプログラマーによって批判や憤慨の対象となっていると同時に極めて広く使われているという事実をどう受け止めますか?

BS: 表向きの答えとしては、世の中にはただ二種類だけの言語があり、一つは誰もが不平を言う言語で、もうひとつは誰も使わない言語だということです。

ひどいと言われている言語で開発されたシステムのほうが、美しいと讃えられている言語で開発されたシステムよりもはるかに便利であったりします。プログラミング言語の目的は良いシステムを開発する手助けをすることであり、「良い」にも色々あります。私の簡潔な定義では、正しく、保守可能で、十分高速であることです。美学も大事ですが、1にも2にも大事なのは言語が便利であることです。現実世界のプログラマーが現実世界のアイディアを簡潔にかつ手頃な労力で表現できなければいけません。

C++の成功の主要な要因は、単にC++がその限られたデザイン上の目標を満たすものであったことです。その目標とは、極めて広範なアイディアを直接かつ効率的に表現できるということです。C++はただ一つのことを非常にうまくやるためにデザインされた言語ではなく、「良くない」と考えられていることを人々にさせないようにデザインされた言語でもありません。その代わりに、私は汎用性と高速性に努力を集中しました。

私は、C++が嫌いであると自称しているプログラマーの中でも一人ぐらいは好きになる人がいると確信しています(?)。

しかし、私の友達が行ったカンファレンスで、基調講演者が、一つめにどれぐらい多くの人がC++が嫌いか、二つめにどれぐらい多くの人がC++プログラムを書いたか、という質問に対して聴衆に挙手を求めました。一つめの質問に手を挙げたグループは二つめのグループの二倍の人数でした。自分がよく知らない物に対して嫌悪を表明するのはたいていの場合偏見であることが知られています。また、不平を言う人たちはいつも声が大きく、擁護者--分別のある人は欠陥を認める--より確信に満ちています。私は他の誰よりもC++の持つ問題を承知していると思いますが、また一方でそれらを避けてC++の力を使う術も知っていると思います。

そして、もちろんC++との競争に敗れた言語の支持者がそれに対し礼儀正しくあることを期待してはいけません。ソフトウェア開発の世界にはそんなプロフェッショナリズムはありません。私はそれができることを望んでいますが。この点で科学は違います。新しい道具や技術や理論が勝利を収めたとき、人々はそれを進歩と見ます。ソフトウェアの世界では、競争相手や先駆者の寄与が広く認められたり評価されたりすることはなく、理解されることすらありません。

TR: あなたは"The Design and Evolution of C++"の中で、キルケゴールがあなたのプログラミング言語のコンセプトに影響を与えたと述べています。これはジョークですか?

BS: ちょっとうぬぼれてみましたが、ジョークではありません。ソフトウェア開発に関する多くの思想はグループ、チーム、会社に焦点を当てています。これはしばしば個人の独創的な能力や技能を表出させることなく企業「文化」に埋没させるほどです。企業の風習は、技術関係で突出した能力やイニシアティブを持つ個人に冷淡であることがあります。私は技術者に対するそのような扱いは非道で能力の浪費であると考えます。キルケゴールは「大衆」に対する「個人」を強く擁護しており、美学的・道徳的振る舞いの重要性について真摯な議論を行いました。C++の仕様のうち特定の何かを挙げて「これは19世紀の哲学者の影響です」と言うことはできませんが、彼は私が「誤用」を防ぐために「エキスパートレベル」の仕様の排除したり、自分が便利だと考える用途だけをサポートするように仕様を限定したりすることに抵抗することのルーツの一つです。私はキルケゴールの宗教哲学を特に好むわけではありませんが。

TR: 最も後悔することは何ですか?

BS: 後悔はありません! もちろんもっと違った形でうまくやれたかもしれないと思うことはありますが、真面目に言って、私が1984年のBjarneにけちをつけられるでしょうか? 彼は今の私より経験は少ないですが、より無能であったというわけではなく、おそらく今よりも賢く、1984年について私よりもよく理解していたでしょう。C++は我々の生活を向上させる多くのシステムを構築するために使われており、後発の言語やシステムに重要な良い影響を与えました。これは誇るべきことです。