Intel の Web log である Research@Intel に Timothy Mattson が言論の核弾頭を放り込んで議論になっている。彼の議論は WIRED VISION が「選択肢が多すぎると意欲がそがれる」マルチコアの問題点として紹介している。WIRED VISION は見事にこの主張を論証しているとしているが本当にそうか? と疑問に思う。パパのインターネット巡回生活の"商品の選択は少ない方が買い易い?" あたりでもリファーされているのでその辺も含めて。
まず、Mattson はこの件を論証するに当たり、ジャムの陳列を持ち出している。抽象化は物事の本質を描き出すことがある。しかし、重要なことは描き出すことがあるということだと考える。抽象化はその過程で多くのものを捨てていくため、間違った抽象化は自ずと焦点を本来あるべき点から遠ざけていく。特に本来別のフィールドで構築されたものを転用するに当たってはその転用が妥当かどうかに多くを割いて検証する必要があると考える。なぜなら、プログラマはジャムを購入しようとは思っていないからだ。
また、Mattson が持ち出す選択肢はお互いに関連や競合があるものも少なくない。たとえば、
- Windows Threads
- Pthreads
これは同じレイヤーの技術である。Windows Threads は Windows OS のスレッド API 群であろうし、Pthreads は POSIX スレッドで、多くの場合には *NIX のスレッドである。どちらも、スレッドをコントロールするローレベルの API でこれは、OS を選定する時点で自動的に定まると考えてもよい。また、同じくリストに登場する OpenMP は Windows Threads や Pthreads などの低レベルなレイヤーを前提として動作するそれらよりも高レベルのレイヤーである。したがって、OpenMP を使いながら Windows Threads や Pthreads で細部を調整するということはあるだろうが原則的には高レベルのレイヤーを使っているときに低レベルのレイヤーは考慮しないだろう。
まず、前提として現在、進展するマルチコア化にプログラミング手段がギャップを持っているというのは恐らく確かだろう。OOP、AOP と問題が生じるためにいろいろな解決法が模索された。OOP では C++、Objective C、Java、C# など多くの言語が開発されたし、現在も開発されている可能性がある。そして、たくさんの言語があることで意欲がそがれたという話は聞いたことがない。つまり、プログラマがツールを探すときとジャムの購入ではどこかそして大きな差があると考える。
たとえば、私が現在何かプログラムを作るときには概ね、次の言語を考慮する。
- IronPython
- C#
- F#
- C/C++
- HLSL
たとえば、作ろうとするものがセクシーな 3D のシェーダであるならば、HLSL である他の選択肢は多くはない、GLSL ぐらいであろう。もちろん、NVIDIA の Cg も使えるとは思うが。しかし、C/C++ や IronPython は出てこない出てくるはずもない。ちょっとした使い捨てのツールを作るなら IronPython である他の LL でもいいが。しかし、C/C++ で作るのは大変だ。CPU をぶん回すのが主目的で大量の計算をするなら最初から C/C++ で作る、そういうときに LL を考慮することはあまりないだろう。もちろん、プロトタイプを LL で作るのはありであろう。グルーとして使うのもありかも知れない。でも、ヘビーなループがあるところに LL を持ってきたりはしないだろう。
多くの手段というのは多くの視点から問題解決が行われていることを示している。Igor Levicki が以下のような発言をコメントでしているので触れておく。
"different programming languages allow us to think about the problem space in a different light." No they don't
ちょっと、違う。確かに、アルゴリズムは一個だけのはずである。しかし、言語によって書きやすさには違いがある。たとえば、関数型言語であればループの代わりに再帰を使うだろう。特に論理型の言語たとえば、Proglog のようなものであればバックトラックのような機構を使うであろう。そういう意味では C と BASIC を引き合いに出して radix sort を出してくるのはちょいと例としては適切さを欠くと思う。
まつもとゆきひろはハッカーズライフ 第7回 "言語の重要性その2" の中で以下のように述べている。
また、良い言語をデザインしようという行為は、人間の気持ちをより深く考えることでもあります。つまり、インタフェースのあるべき姿について、より深い考察を行うことでもあるわけです。自分言語を作る2つ目のメリットとしては、言語レベルでの使い勝手を考えることで、プログラムの使い勝手に関するより深い経験と知識を身に着けられることがありそうです。
この辺に関しては私も基本的に同意見である。その意味において、別の言語を引っ張り出すことで別の角度から問題を考察できる可能性がある。少なくとも、C のかわりに BASIC を出しても意味は薄い。どちらも、手続き型言語という特性には忠実に従っているので別のパラダイムを生むことは難しいと思う。
