プログラミング言語は自由度が低いほど強力か？

作者 Sadek Drobi , 翻訳者 編集部 投稿日 2008年3月28日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

Architecture ,

Java ,

言語 ,

プログラミング

タグ

Haskell ,

Functional Programming ,

言語 ,

言語特性

さらなるパワーを追求し、C#には最近新機能が加わり、Javaも間もなくC#と同じ道をたどる可能性がある。機能の選択肢が拡大すればプログラマーの自由度は高まるが、これにより必ずパワーが増すのだろうか。また、真に強力であるために、言語は高い自由度と柔軟性を提供する必要があるのだろうか。 

これは必ずしも真実ではないとReg Braithwaite氏は考えている。Azubuko Obele氏が「さらなるパワーを持った言語を支持する人々は、実はいっそう少ないルールに賛成しているのだ」と発言したことに応えて、Reg氏は、Rubyなど多数の言語では、たとえパワーと自由度に相互関係があったとしても、この2つの間には因果関係はない(source) と力説する。Reg氏によれば、PythonとJavaは両方とも「プログラマーからある特定の自由を取り去れば、より良いプログラムができるという哲学で構築されている」にもかかわらず、 Python は「Java よりかなり強力な言語」である。Pythonで機能が却下された理由は、単に誤用される潜在性があったからではなく、むしろ、望ましい結果を達成する「完全に有用な方法」がすでに存在したから、あるいは「インデンテーションのような重要でない」ものに関係していたから、その機能は不要と判断されたため、機能が却下されたのである。そして、このアプローチによると、もし新機能が「Pythonのスタイルと設計的美学にフィット」できたなら、そうした機能の追加が阻止されることはなかった。  

関数型言語にも厳密なルールを課すものがあるが、それはパワーが落ちることを意味するわけではない。

Haskell は一般に使用されている言語の中で、おそらく制限度が最も高い言語でしょう。一つの方法であらゆることを行うという、数学上純粋な関数プログラミングです。強力かつ表現的な静的型づけがあります。

[…] 

同様に、Factorプログラミング言語は、制約ルールを１セットだけプログラマーに課します。Factorに乗り換えるプログラマーは、Factorのより高位なプログラミング力を手に入れるために、ローカル変数を放棄しなくてはなりません。

そのため、 Reg氏は「言語は、より多くのルールを提供しながら、そして逆説的に、自由度は減少させながら、いっそうのパワーを提供することができる」と論ずる。Reg氏によれば、本当に重要なのは、舵取りとなる哲学に従い、言語に一貫性をもたらす入念な設計である。そうすれば言語は、より少ない労力でより多くをプログラマーに達成させることによって、さらなるパワーを提供でき、そして、「おびただしい数の機能の上にさらにたくさんの〔しばしば無関係な〕機能を投入する」ことなく、言語が成長できるのだ。

あらゆる分野で優れている設計は、より少しでさらに多くを達成する「反引力」という芸当をやってのけます。設計が貧弱であれば、新しいパワーの追加には、さらにたくさんのチェックボックスや機能、物事を実行する方法が必要になり、こうしたものはお互いに予期しない影響を受けるのです。

パワーと自由度に必ずしも相関性がないというReg氏の意見を共有しながらも、コメンテータの一人のDaniel氏は、言語のパワーは、その言語がプログラマーに課するルールには依存しないが、その言語が「提供するコンピュータ言語の『定理』」に依存すると論じている。

コンピュータ言語はルールと同種ではありませんが、数学とは同種です。［…］ですから、コンピュータ言語を代数と比較してください。定理が多ければ多いほど、強力さも増すのです。定理は自由でしょうか。もちろん違います。定理は、さらなる成果をより容易に達成するために結合することのできる、根本的な真理なのです。

Daniel氏によれば、言語に相違をもたらすものは何かと言えば、言語が提供する定理のどの程度が、人間が容易に対応できるコンストラクトであるかということである。

たとえば、私たちの大部分が「for」ループを理解するとしても、マシンコードに「for」ループはありません。CPUフラグに基づいた条件付き飛び越しがあるだけです。 

しかし、私たちはそこから、非常に便利なコンストラクト、「for」ループを開発したのです。さて、「for」ループは非常に強力なコンストラクトですが、しばしば誤用しがちです。実のところ頭の中で「for」ループを本当にシミュレートできる人は少ないため、このコンストラクトでのエラーは珍しくないのです。 

次に、「foreach」（リスト・イテレーターもしくはマッパー）コンストラクトは「for」コンストラクトほど柔軟ではないかもしれませんが、より容易に理解できます。

Daniel氏は、こうした簡単に理解できるコンストラクトの使用を唱道している。なぜなら、そうすれば誤用の危険を制限できるし、より「プログラムを修正しやすい」言語となるからである。こうしたコンストラクトが「強力でありながら、同時に使いやすい」としても、常にそうとは限らず、誤用されやすい「定理」の方が実はより強力なのある。そのため、自由度とパワーの間に直接の相互関係が存在しないだけでなく、コードの質という名において、ある程度のパワーを放棄する必要があるかもしれない。  

根本的な概念の相違にもかかわらず、これら2つのアプローチは相対するものではない。Reg氏とDaniel氏双方の議論を基にすると、言語が真に強力であるためには、異なる機能の一貫性を約束する慎重に考え抜いた設計を有すること、そして誤用による危険を制限し、コードの質を高めるために、人間から見て意味をなすコンストラクトを提供する必要があること、と主張することができる。

原文はこちらです：http://www.infoq.com/news/2008/03/powerful-programming-languages

• 次へ >