BT

「原罪」(Javaは、プリミティブがないほうがよかったか?)

| 作者: Dave West フォローする 1 人のフォロワー , 翻訳者 編集部N フォローする 0 人のフォロワー 投稿日 2009年6月7日. 推定読書時間: 5 分 |

原文(投稿日:2009/6/1)へのリンク

Gilad Bracha氏は、言語の設計について、特に言語は、純粋なOO(オブジェクト指向)になりえるか、そして、プリミティブ型のシステムを強要することができるのか、について古い議論を再開した。彼は、自分のブログRoom 101で、こう主張している。"私は、Javaの原罪は、純粋OO言語、すなわちすべてがオブジェクトである、言語ではないことだ、としばしば言ってきました。"この掲載記事の論点は、純粋なOO言語の価値についてではなく、プリミチィブ型なしでも、Javaは、今と同じぐらいのパフォーマンスを出せるか?という質問について答えることです。その答えは、イエスです。"

氏は、型づけがいかに問題を生むか、という簡単な例で、彼の議論を始めている。Javaのchar型は、当初(当時のユニコード標準に従って)16ビットで、表現された。しかし、標準が変更されると、ユニコードを扱う人は、コードポイントを自分で、エンコードしなくてはなりません。パフォーマンスについては、効率を犠牲にせずに、いかにオブジェクトを生成するかの、いくつかの例を示している。一例は、

そこで、著しいパフォーマンスの低下なしに、どうやってプリミティブ型を取り除けるかです。

Javaには、強制的な静的な型システムがあり、コードは、静的な型付きのアセンブリ言語(Javaバイトコード、いわゆるJVML)に、コンパイルされます。Javaは、finalクラスをサポートしています。私は、このフィーチャが好きでは、ありませんが、前提として受け入れましょう。私の提案は、プリミティブ型を完全に、取り除くことだけです。

32ビット整数を表す、ファイナルなIntクラスが、あると思ってください。コンパイラは、この型の実体を、整数に翻訳できます。ですから、今日のJavaが、全くパフォーマンス低下なしに行うように、スカラに対して、同じコードを生成できます。

もっと面白い例が続き、名前がオペレータであるメソッド、Intオブジェクトを値のように振る舞わせこと、==オペレータ, インスタンスのロッキング、配列の共変性などがあります。

 

結論。

結局のところ、Javaは、著しいパフォーマンスの低下なしに、純粋OOであり得たが、過去、現在において、そうではないし、未来においてもおそらくそうならないでしょう。 栄華は、かくも消えゆく、です。

この発言に対するレスは、ほとんどGirad氏の主張に賛成しています。

 

いくつかのレスを抜粋すると、

  • Daniel Speiwak氏 - 実際のところ、Scalaに似たような感じですね。興味あるのは、Odersky氏とその仲間が、最近、配列の共変性+アンボックスされたプリミティブの問題への、面白い解を示しました。ジェネリックな型の特化です。
  • " abies氏 - 事は、そんなに単純じゃない、と思います。オブジェクトと同様に、プリミティブ型を非常に効率的に、エンコードするのは、可能だ、ということには、同意しますが、それでもコストが、かかります。Smalltalkが、いい例です。- 大抵の実装では、小さな整数と大きな整数とでは、別な実装になっています。小さな整数は、周回しないポインタ内で、変装されています。あるところを境に、パフォーマンスが、非常に違ってくるわけです。 そこを境に、すべての整数のパフォーマンスが少し低下します。- 私個人としては、Javaは、数学演算するコードについては、C++やFortran並みに、速くなる可能性があることを、喜んでいます。
  • " Osvaldo Doederlein氏 - OO対プリミティブ型についての議論は、プリミティブなスカラ/配列を持った言語に対して、著しいパフォーマンスの低下がない、純粋OOプログラミング言語を少なくとも一つは、あげる、という課題から始めるべきです。高レベルなアプリケーションのベンチマークで、騙さないでくださいよ。数学/配列のミクロなベンチマークか、データ圧縮、ビデオエンコーディング、ネットワークスタックのような、実用的で、低レベルなアルゴリズムで、最高のパフォーマンスが欲しいですね。

議論の中には、両陣営の隔たりを説明するためだけに、役立つような、技術的な例もいくつかある。

 

おそらく、"偉大なOO論争"の、この特別な事例の最もおもしろい側面は、取り上げられなかった問題にある、ということだ。例えば、

  • " 効率対OOの純粋性の議論は、Javaが出現するずっと前の80年代と90年代始めにおける、Smalltalk とC++間の、言語戦争の中心部分だった。OO言語が、作られた理由を無視したので、その議論は、まったく見当違いのものだった。当時、最も純粋なOO言語は、Smalltalk と Selfで、両方とも、Simula (Simula Iではない)を模倣することを明確な目標として、ドメインの専門家が、自分の問題と解を簡単に、直接的に、表現できるようにと、作られた言語である。そのため、コンピュータ(資源)の効率性やパフォーマンスの低下は、二の次だった。
  • " この著者は、組み込みで、ミリセカンドを争い、アプリケーションを切り替えながら、リアルタイムのグラフィックシステム(ジェット戦闘機用)において、SmalltalkがC++のパフォーマンスを上回るのを見てきた。パフォーマンス向上のために、例えば、プレコンパイルやSmalltalkのオブジェクトが、OSを介さずに、ハードウェアを直接操作する、などの、プログラミングトリックを使った。
  • " この著者は、組み込みで、ミリセカンドを争い、アプリケーションを切り替えながら、リアルタイムのグラフィックシステム(ジェット戦闘機用)において、SmalltalkがC++のパフォーマンスを上回るのを見てきた。パフォーマンス向上のために、例えば、プレコンパイルやSmalltalkのオブジェクトが、OSを介さずに、ハードウェアを直接操作する、などの、プログラミングトリックを使った。
  • コードと言語の"フィーチャ"は、OOの純粋性の価値を議論する場所では、絶対にない。オブジェクトとは、開発者が、ドメインの問題を最もよく理解し、根本的に異なり、より単純で、もっと効率的な、設計とアーキテクチャを思いつくのを助ける、比喩的な道具である。純粋のOO、すなわち "すべてがオブジェクトである"、言語を持つ意味は、単に、設計がどのように実装されているのかとか、コンピュータレベルどのように、実行されるのか、について気にすることなく、設計を直接的に表現できる、ということである。

言語は、なぜそのように、存在するのか、に基づいて、純粋のOOと効率との論争を考えたり、そして、絶対的なマシン実行効率が、それほど問題にならないところで、オブジェクトは、本当に、設計する手段を、提供するのかどうかを考えるのは、非常に面白いだろう。

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT