今日はあちこちで仕事納めであったり、大掃除であったりするようです。
いよいよ今年も終わりが近いと言うことですね。
というわけで、年忘れスペシャルとして普段は書かないであろうJava賛美論を書いてみます。
ここでは、「機種に依存しない」という表現を使っていますが、より正確には特定の実行環境には依存しない、と書くべきものです。不正確な表現ですが、「機種に依存しない」という言葉がけっこう好きなので、こう書いてしまいます。
とても変な人? プログラム言語ミーハーという人種 §
プログラム言語ミーハーというのは私がそう名乗っているだけで、同じような人が他にもいるのかどうか分かりませんが。一言で言えば、プログラム言語が好きな人のことを言います。いろいろなプログラム言語がこの世にあることを喜び、楽しむ人種と言えますね。ただ、プログラム開発に関わる全ての技術が対象という訳ではありません。あくまでプログラム言語だけが対象となります。たとえば、モデリングを行うUMLは、プログラム言語ではないので、対象外になります。もっとも、一部で行われているようなUMLそのものを実行可能に記述する手法を用いれば、これはプログラム言語ミーハーの対象内に入ってきます。また、XMLのようなメタ言語も、プログラム言語ではないので、対象外になります。しかし、XMLによって作られたプログラム言語があれば、それは対象内になります。
別の言い方をすれば、プログラム言語ミーハーが大好きなものは、言語仕様書とソースコードです。モデルを示すUML図や、フローチャートはそれほど好きではない場合があります。UML図よりも、ソースコードの力を信じる、という態度もあります。
そのようなことかわ分かるとおり、プログラム言語ミーハーはいろいろなプログラム言語の言語仕様を見ています。当然、それを通して設計思想も見えてきます。それゆえに、あるプログラム言語が、他の多くのプログラム言語と比較して、どのような特徴を持っているかも見えやすいと言えます。
そういう観点から見ると、「このプログラム言語はXX機能があるから凄いのだ」と宣伝されていたとしても、他の多くのプログラム言語にも同じ機能があれば、それは特徴と見なさい、という判断も可能となります。
そういう視点でJavaを見て行きます。
1990年代で最も極限に高められた芸術的な美しさを持つ言語! §
まず、Javaこそは、1990年代で最も極限に高められた芸術的な美しさを持つ言語だ、と高らかに宣言してみましょう。本当にそうかどうかは分かりませんが、ミーハーなので、嘘を言っても実害はないでしょう。余談を言えば、プログラム言語というのは、極めて多くの種類のものが生み出されていて、それを全て見ることは不可能であるし、見たものに限っても、それを正しく理解したという保証はありません。そういう点で、「最も極限に高められた」というのは、本当に意味のない言葉です。
しかし、「芸術的な美しさ」という言葉は、そこそこには意味があると思います。
Java言語仕様は極限まで切りつめられた美しさがあると思います。
それこそが、Javaを類似の他言語と区別する最大の特徴だと思います。
よく、機種に依存しない、インターネット対応、マイクロソフトに対抗する切り札、といったことがJavaに関して言われますが、それはJava言語仕様の持つ本当の価値とはかけ離れたものに過ぎないと感じます。
機種に依存しない特徴がJava普及を妨げる? §
たとえば、機種に依存しない、というような特徴を持たされたプログラム言語は珍しいことではありません。まあ、おおむね大多数のプログラム言語は、言語仕様レベルにおいて、機種に依存するような構造になっていないと思います。処理系の都合や、いろいろな事情によって、機種に依存してしまうことになりますが。それでも、8bitパソコンの時代のUCSD Pascal(開発システム一式と作成されたプログラム本体が仮想マシンで実行され、特定の機種への依存性がなかった)を思い返せば、機種に依存しないというような特徴が大騒ぎするような凄いことには思えません。
そして、そういう機種に依存しない戦略は、ことごとく失敗しているように思えます。実際、初期の8bitパソコンでは、UCSD Pascalよりも、ネイティブコードを生成するPascal MT+の方が成功したような印象があります。
このような観点からJavaを見ると、むしろ「機種に依存しない」ことがJavaの普及を妨げているようにも見えます。
Javaはサーバサイド処理にこそ普及しているものの、デスクトップアプリケーションを書くプログラム言語としては、失敗していると言っても良いと思います。
そのような結果になるのは、「機種に依存しない」という戦略を取る限り必然と言えるでしょう。
たとえば、初期のGUIライブラリであるAWTは、環境ごとに動作が非互換であり、そのあと鳴り物入りで登場したSwingは、重く大きく、しかもOSのネイティブのGUIと動作が微妙に異なっていて、使いにくいことこの上ない代物だったのです。
この点で、より現実的であるらしいStandard Widget Toolkit (SWT)の登場は必然的なものだったのかもしれません。SWT無くして、Eclipseの成功も無かったのかも知れませんが、とりあえず、まだSWTはちゃんと調べたことがないので、ここは調べてもいないことを書いてごめんなさい、と書いておきましょう。
話を戻すと、プログラム言語ミーハー的な見解はこうなります。
もし、機種に依存しない、などという思想が大々的に主張されなければ、ネイティブアプリケーションを書くためにJavaを使う機会はより多く訪れたと思います。そして、それは、Java言語仕様の芸術的な美しさを堪能する機会を増やす結果になったでしょう。(よりマシな、ネイティブアプリケーションを書くためのプログラム言語のニーズが無かったわけではないのです)
つまり、「機種に依存しない」という宣伝と強要は、Javaの美を世間に普及させるためには、マイナス要因であったと思います。
切りつめられた美しさ §
切りつめられた美しさを持つプログラム言語は、何もJavaが初めてというわけではありません。むしろ、歴史的に他にも同じような美しさを持つプログラム言語があるからこそ、Javaの言語仕様も美しいと認識できると言えます。
たとえば、どんなプログラム言語が切りつめられた美しさを持つと言えるのか。
全てをリストとアトムに還元して処理するLispなども良いと思いますが、個人的にはFORTHが最高に好きです。全ての操作をスタック経由で行い、「スタックに値を積む」ことと、「手続きを呼び出す」という2つの機能以外、全てはライブラリで実現する単純さ。いや、「スタックに値を積む」機能もライブラリ呼び出しで実現できたかな? それはともかく、FORTHのインタプリタはアセンブラで10行ぐらいで記述でき、なかなかのシンプルぶりを見せてくれます。そして、アセンブラで書くよりもプログラムサイズがコンパクトになると言う、驚くべき特徴すら発揮します。コンパイラの最適化機能が貧弱だった昔、高級言語で書くよりもアセンブラで書いた方がプログラムが小さくなるのが常識でした。しかし、FORTHはその常識を超越したのです。
Javaの場合は、C++と言語仕様を比較すると、どう切りつめられているかが分かるでしょう。ある程度の実装上の効率的な問題を意識しつつ、徹底的に機能が切り捨てられています。同じような構文を使って記述するにも関わらず、言語仕様の大きさは、歴然と違っています。それでいて、記述可能なアルゴリズムの範囲が狭まっているようなことはありません。ある種のコーディングは不可能になっていますが、それは他の方法で十分すぎるほど代用できるものです。
これによって、得られたものは極めて大きいと言えます。
言語習得の容易さ、分かりやすさ、そして、ぎりぎりまで研ぎ澄まされた緊張感。
素晴らしき言語仕様を持つJavaよ!
1990年代で最も極限に高められた芸術的な美しさを持つ言語であると私は賛美してあげたいと思います。
切りつめられた極限美の裏側にあるもの §
この文章を誠実なものにするためには、もう1つだけトピックを付け加える必要があります。
それは、切りつめられた極限美のマイナス面です。
切りつめられた極限美は、それ以上変化し、適用する能力を失う、という話です。
これはプログラム言語に限定されず、どんな世界にもある話です。
たとえば、MS-DOSの時代に一世を風靡した大傑作エディタのVzというものがあります。これは、ぎりぎりまで切りつめられ凝縮されたソースコードから叩き出される、軽快でパワフルな動作が魅力的なものでした。しかし、機能強化するバージョンアップ版は提供されませんでした。Vzの最後はマイナーバージョンアップのバージョン1.6であり、メジャーバージョンアップとなる2.0はリリースされませんでした。
切りつめられた極限美を無理に変化させようとすると、失敗に終わるという事例もあります。たとえば、C言語も、1つの切りつめられた極限美を持つ言語だと思います。C言語を当たり前だと思っていると、なぜ「極限美」などと言うのか疑問に思う人もいると思いますが、同時代のプログラム言語と比較すればいろいろなことが分かると思います。たとえば、当時の言語は、入出力機能などが言語仕様の一部であったりすることが珍しくありませんが、C言語はそういうものをスパッと全て切り捨ててしまいました。それらはライブラリに置くとしてしまったのです。それゆえに、C言語は入出力のスタイルが言語仕様と切り離され、独自の入出力デバイスを持つ組込用にもすんなり適合して利用可能になったと言えます。
話を戻しましょう。切りつめられた極限美を持つC言語を上位互換性を持たせつつ拡張しようとした試みがC++であったと言えます。しかし、言語仕様的な面でC++を良いプログラム言語であると言う人を、私はほとんど知りません。Cと同じような構文を採用しながら、全く互換性を持たせていないJavaが成功しているのは、まさに互換性を持たせなかったからと言えるでしょう。
そのような観点から言えば、Javaの言語仕様は、おそらく、これ以上変われないと思った方が良いと思います。おそらく安易なJavaの機能拡張は失敗するでしょう。
では、永遠にJavaは今のままで良いのか、というと、それは違います。
世の中というものは常に変化し続けるものです。それゆえに、プログラム言語は、そのニーズに対応するために、変化する必要性を迫られます。
しかし、Javaは変われないと書いたばかりではないか、と言われそうですが、その通りです。
世の中は変わっていくのにJavaは変われません。
それが、実用言語としてのJavaの限界です。
状況の変化に適応できずないJavaを堪能することは、いずれ「滅びの美」を味わうことを宿命づけられたのと同じことだと思います。
むしろ、「滅びの美」を味わうことすらも、プログラム言語ミーハーの愉悦の1つであると言えます。
ここでもう一度Javaを賛美しましょう。
滅びに味わうべき美もないプログラム言語も珍しくありません。
しかし、Javaの滅びはきっと味わうに値する甘美なものになるでしょう。
それは、Javaが良い言語であったということの裏返しです。
そして、実用言語としてJavaの価値が失われたとしても、Javaの美が失われるわけではありません。実用言語ではなくなった後でも、美を堪能するためにJavaを使うことは、プログラム言語ミーハー的には楽しいことでしょう。
