プログラミングの常識を疑え！
プログラミングとは何か
プログラミングと聞いて、みなさんはまず何を連想するでしょうか？
狭義の意味では、人間の意図をプログラミング言語によって記述すること（コーディング）ですが、より広い範囲、ソフトウエア開発全体を連想する人も多いかと思います。
狭義の意味だけに絞ったとしても、プログラミング言語にはさまざまなものがありますし、記述する内容や書き方のスタイル（プログラミングパラダイム）にもいろいろなものがあります。
例えばCやC++のようなコンパイラ言語は、OSを初めとした、さまざまなシステムやアプリケーションを作るのに向いた言語と言われています。これらの言語で書かれたプログラムは、コンパイラに対して細かな指示を与え、効率的な実行可能ファイルを生成するための記述です。
それに対してShellやPerlのようなスクリプト言語は、その名の通り、システムの動作内容などを台本のように記述します。そして、システムが持つインタプリタが直接読み込んで実行し、複雑な作業の自動化などに用いられるケースが多いです。
とはいえ、コンピュータが十分に高速化した現在では、スクリプト言語によってシステムやアプリケーション自身が記述／拡張されるケースが増えてきており、それぞれの役割分担は以前ほど明確なものではなくなりつつあります。
従来はOSの上で実行されるだけのプログラムがほとんどでした。やがてJavaプログラムのようにVM（Virtual Machine）上で実行されたり、JavaScriptのようにWebブラウザ上で動くプログラムも多くなり、より自由度が高まってきています。
最近では、ただ実行するだけではなく、LLVM（Low Level Virtual Machien）（http://llvm.org/）のように、実行可能ファイルを「ゆりかごから墓場まで」最適化し続けるための実行環境も実用段階に入ってきています。これは、コンパイラ、インタプリタ、プロファイラ、VMなどを統合するものであり、より柔軟かつ高度な自動最適化が可能になると考えられています。
開発環境の多様化
さらに、電子回路をプログラミング言語で記述し、ソフトウエアからハードウエアを生成するHDL（Hardware Discription Language）や、プログラムをロードすることでハードウエア自体を変更可能なFPGA（Field Programmable Gate Array）のような技術も普及しつつあります。
もはやハードウエアとソフトウェアの境界さえ絶対的なものではなくなりつつあり、システム構成の自由度は格段に向上してきています。そして、ソフトウェア開発の際に使用するライブラリや開発環境、ミドルウエアも非常に多様化してきています。時代が進み、技術が高度になるにつれて、ますますプログラミングという概念は複雑でとらえどころの無いものになりつつあるような気がします（図1）。
そこであえてもう一度、プログラミングという概念を整理してみて、その本質とこれからの向かうべき方向について考えてみるというのが、この連載の目的です。
次ページでは、プログラミングを取り巻く固定観念について考えてみましょう。
用語から連想される固定観念の危険性
技術が進歩し、できることがどんどん増えてきているにも関わらず、従来の常識にとらわれたままでは十分に技術を生かすことができません。また、新たな技術の開発や発展を阻害してしまう恐れもあります。
例えば、先に述べた「コンパイラ言語」と「スクリプト言語」は本当に異なるものなのでしょうか？それとも本質的には大差ないものなのでしょうか？
現在はインタプリタといえども、ソースコードを一度内部形式にコンパイルしてから実行するのが普通ですし、実行中も動的に（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の環境に最適化されたプログラムを、マルチプロセッサ環境に手作業で移植するのは容易ではありません。
このように、現実に普及した技術だけを見ていると、それが果たして本当に望ましい技術なのか、それとも単なる一時的なブームなのかということが見えにくくなります。
そして次から次へと現れる「新しい技術」に踊らされるだけで、何も本質的な視点も技術も身につかない、ということに成りがちなのではないかという危機感を、筆者は常々感じています。
もちろん、理論的に良いものが普及するわけではない、ということは歴史が証明するところではありますが、いろいろな可能性を考えてみて自分なりの意見を持つことは（たとえ直接的に業務の役には立たなくとも）無駄にはならないと思います。また、一から新技術やアーキテクチャを設計する機会を得た場合などに、何らかのヒントとなるかもしれません。
あらためて「プログラミング」について考えてみる
さまざまなイメージをもとにその位置付けを考えてみると、「プログラミング」とは、なんらかの記法（人工言語）で「プログラム」を書いて、何らかの「問題」を、何らかの方法で「コンピュータによって解決」する行為、と一般化できるのではないでしょうか。
もちろんこの定義は厳密な定義ではなく、いたる所に議論の余地があるあいまいなものです。「どんな記法で、何を、どこまで書けば良いのか？」「どこまでが自動化可能なのか？」「どのようなシステム構成で、どのようにしてハードウエアを動かすのか？」など、どれもそれだけで1つの連載になるぐらい難しい疑問ばかりです。
例えば、従来はターゲットプロセッサの機械語が最下層であり、アセンブリープログラムを生成するまでがコンパイラの役割でした。しかし、現在の技術水準ならば、LLVMのような抽象実行系をいったん経由し、さらに高度な最適化を狙うという選択肢もあります。そして将来的には、直接サブルーチンをハードウエア化する技術なども実用化され、より選択肢は豊富になるかもしれません。おのずと望ましいプログラムの性質や記述方法なども変わってくることとなるでしょう。
また、「コンピュータによる問題解決」こそが本質であって、プログラミングはそのための一手段にすぎない、とバッサリ切り捨ててしまうこともできるでしょう。
先に行われたLL Future 2008（http://ll.jus.or.jp/2008/）という800人以上が集まった一大イベントのパネルセッション「LLで未来を発明する」においても、100年後のプログラミング言語について豪華なパネラー陣が予想するという企画がありました。
そこでは、プログラミング言語Rubyの設計者/実装者であるまつもとゆきひろさんなどが「100年後の未来では、そもそも誰もプログラミングなどしてないのではないか？自然言語で命令すると、コンピュータが動くような世界になっているかもしれない」というような話をされていました。確かに本物の人工知能が実現し、コンピュータと人間がシームレスに協調できる世界こそが理想なのかもしれません。
しかし現状では、プログラミング以外で人間の意図を正確に伝え、コンピュータを動かす方法論は確立されていません。話の発散を防ぐためにも、本連載ではそこまで未来ではない、数十年後程度について考えて行きます。先ほどプログラムを「人工言語による記述」とあえて位置付けたのは、そのような意味を込めてのことです（また、筆者は、自然言語は本質的にあやふやで、問題の厳密な記述には向いてないと考えており、そのような可能性について多くの疑問点を持っています）。
未来を知るために、まずは歴史を知る
そのために、まずはコンピュータプログラミングの過去数十年の歴史について考えてみましょう。
この連載では「命令型プログラミング」と「宣言型プログラミング」という大きな切り口で歴史を見ていきます。そして、それぞれのプログラミングパラダイムにおいて何が不十分だったのかということを考察した後、それらの問題点を解決できると期待されている「等価変換型プログラミング」という新しいプログラミングパラダイムを紹介するという流れで進めて行きます（図3）。
次回は、コンピュータのハードウエアに根ざして発展してきた命令型プログラミングの歴史について振り返っていきます。
