InfoQ

News

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

作者 Sadek Drobi , 翻訳者 編集部 投稿日 2008年3月28日 午後6時36分

コミュニティ
Java,
Architecture
トピック
言語,
プログラミング
タグ
言語,
言語特性,
Functional Programming,
Haskell

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

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

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

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

[…] 

同様に、Factorプログラミング言語は、制約ルールを1セットだけプログラマーに課します。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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
slashdot+
Hatena

特集コンテンツ一覧

Flex 4の新機能トップ10

今週(2009年6月1日)AdobeはFlex 4の正式な初ベータ版をリリースしました。Flex 4はGumbo(オクラ)というコードネームで開発されています。今回のリリースには大きな変更が多数含まれています。このRIAフレームワークの最新バージョンにおいて変更された事柄についての概要を以下のリストで見ていきましょう。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

ビジネス領域の深い理解を反映したドメインモデルを設計するための、ヴィジョンとアプローチです。この本は、Eric Evans氏の「Domain Driven Design」の主要点を短く読みやすく要約しました。

JavaプログラマがFlexとBlazeDSを学んだ方がいい13の理由

この記事ではJavaプログラマがなぜFlexとBlazeDSを学ぶべきなのかについて13の理由を述べています。なぜ高度にインタラクティブなWeb サイトからJavaで開発されたバックエンドをもつエンタープライズ・アプリケーションまでを含む、リッチ・インターネット・アプリケーション(RIA)の開発にFlexとBlazeDSの組み合わせが最適な選択肢となるのかについて述べています。

仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?

Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。

Perf4Jを使ったパフォーマンス解析とモニタリング

この記事ではAlex Devine氏が、Java開発者がPerf4Jをどのように利用できるかと、タイミングステートメントにコードを追加し、ロギング、結果の解析とモニタリングを行うオープンソースツールセットの説明をします。

複雑な外部DSLを開発する

本稿では、Vaughn Vernon氏が内部DSLと外部DSLの違いを説明し、複雑な外部DSLを開発する際のステップを示します。

J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

この記事では低レベルのサービス・レイヤやリポジトリ・レイヤを肥大化させることなく、フェッチング・ストラテジによってモジュール化された方法でバックエンドにあるシステムからデータを取得する処理を最適化する方法について説明します。

実証済みのアイデアの融合: S#arp Architectureの裏側

この記事では、Web開発における多数の成熟傾向と、クライアントに価値を提供することに対するそれらのメリット、およびS#arp Architecture(最善の手法と技術を活用しようとするASP.NET MVCをベースとしたフレームワーク)内でのそれらの使用について取り上げます。