プログラミングの常識を疑え！

用語から連想される固定観念の危険性

　技術が進歩し、できることがどんどん増えてきているにも関わらず、従来の常識にとらわれたままでは十分に技術を生かすことができません。また、新たな技術の開発や発展を阻害してしまう恐れもあります。

　例えば、先に述べた「コンパイラ言語」と「スクリプト言語」は本当に異なるものなのでしょうか？それとも本質的には大差ないものなのでしょうか？

　現在はインタプリタといえども、ソースコードを一度内部形式にコンパイルしてから実行するのが普通ですし、実行中も動的に（JustInTime：JIT）最適化される場合も珍しくありません。インタプリタとコンパイラの区別は絶対的なものではなく、過去の技術的な制約のために分類されていた（にすぎない）と言えます。

　このように昔から使われている用語の中には、現在の多様化したプログラミング環境においては、むしろ誤解や固定観念の原因に成り得る有害なものも少なくないのではないかと感じます。

　「Cはハードウエアに近い記述ができ、高速な機械語を生成できる」というような言及をよく見る気がしますが、果たしてそれは本当なのでしょうか？確かにCはハードウエアを意識した高速なコードが書け（る可能性があり）ますので、それは一面の真実です。しかし一方で、むしろハードウエアがCを意識し、Cで記述しやすいようなアーキテクチャに進化してきた結果なのではないかと考えることもできます。

　効率的なコードを生成するCコンパイラの有無はCPUの売り上げと直結します。いくら高性能のCPUでも、コンパイラがその性能を生かしきれなければ無意味です。また、Cが高速なコードを生成しにくいようなアーキテクチャのCPUは、ベンダも設計をためらうのではないでしょうか。仮に作るとしても、マーケットシェアを考えた場合、Cを全く意識しないというわけにはいかないでしょう。

　Cは歴史が古く、最も普及した言語の1つであるため、ライブラリや最適化技術などに膨大なマンパワーが投入されており、歴史的資産が蓄積しています。もはや現在では、Cが言語として優れているのか、あるいはほかの要因との相互作用によって使わざるを得ないだけなのかは、鶏が先か卵が先かという問題に似た複雑な関係にあると言えます（図2）。

従来の常識を疑おう

　現在のCPUと、Cが設計された70年代の単純なプログラミングモデルとの乖離は進む一方です。いくらCコンパイラが優秀であっても、キャッシュやパイプラインなどの知識が無ければ、真の性能を引き出すことは難しいでしょう。

　マルチプロセッサ環境やメモリ空間がフラットではない環境も増えてきています。Cは、単一CPUで、フラットなメモリ空間を前提とした言語なので、本来はこれらのモデルに対して必ずしも最適な言語ではないはずです（とはいえ、それでも前述した理由により、現時点ではCで書いたプログラムが最速な場合が多いのですが）。

　また、Cの強みは、そのまま弱みにもつながります。ハードウエアを意識したコードを書いてしまうと、自動的な最適化がほぼ不可能になってしまうのです。例えば単一CPUの環境に最適化されたプログラムを、マルチプロセッサ環境に手作業で移植するのは容易ではありません。

　このように、現実に普及した技術だけを見ていると、それが果たして本当に望ましい技術なのか、それとも単なる一時的なブームなのかということが見えにくくなります。

　そして次から次へと現れる「新しい技術」に踊らされるだけで、何も本質的な視点も技術も身につかない、ということに成りがちなのではないかという危機感を、筆者は常々感じています。

　もちろん、理論的に良いものが普及するわけではない、ということは歴史が証明するところではありますが、いろいろな可能性を考えてみて自分なりの意見を持つことは（たとえ直接的に業務の役には立たなくとも）無駄にはならないと思います。また、一から新技術やアーキテクチャを設計する機会を得た場合などに、何らかのヒントとなるかもしれません。