Bill Burke氏のブログ記事：動的言語 -正当化と神話-

作者 Ian Roughley, 翻訳者 金森 諭 投稿日 2008年2月22日 午前12時37分

コミュニティ

Java,

Ruby

トピック

動的言語,

プログラミング

タグ

Groovy,

Java EE,

Scala,

Python

自分はJavaマニアでしかないのだろうか？」そう自問するのはよいことだ。Bill Burke氏は自身のブログDynamic Languages: Rationalizations and Myths(source)（動的言語：正当化と神話）でこの問いに関してこう書いている。

多分ですが、そうは思わないです。Javaが終わったとは全く思わないし、まだこれからでしょう。確かに今はアノテーションを完全にするためのエレガントでタイプセーフなクロージャがないのでDSL（ドメイン特化言語）の実装もできません。コード生成ではない方法でアノテーションに振る舞いを記述できるようにすることも必要です。初期化をもっと簡単におこなう構造的な構文も必要でしょう。AOP（アスペクト指向プログラミング）をサポートするのもいい考えですし、少なくともAOP的な機能をより簡単に実装するためのサポートをJVMで行えるとJavaは良くなるはずです。JVMとAPI両方で仕様変更がない開発機能の改善、これをJava EEやSeam、Hibernate、Spring、JBoss Application Serverのように行えばきっと素晴らしくなるにちがいありません。

彼はこう続ける。

私ならこれらのすべてをサポートする言語があればJavaを捨ててそちらを選びます。ただしJavaにある以下のことは必ず満たしてないといけません。

• タイプセーフで、静的に型付けを行う
• 最近のJava IDEと同じ機能をサポートしたIDE
• 自分のアプリケーションを作るための豊富なAPIとライブラリ
• ビジネスでも利用可能な環境
• 活発なオープンソースコミュニティ

今ある動的言語はこのうちのいくつかの特性を持っていますが、すべてを満たすものはありません。そのような動的言語が現れるまではJavaだけが選択肢となり、私はJavaファンの一人であり続けるのです。

ブログ記事ではこの文章にいたるまでに正当化と神話についてのいくつかの事項が検証されている。正当化については、

• 動的言語○○はの△△のベンチーマーク結果でJavaに及ばない
• Ruby VMはカーネルスレッドをサポートしてない
• RubyやPythonなどのような動的言語はタイプセーフな型付けや静的な型付けができない
• タイプセーフな型付けができないと大規模システムには使えない
• 静的な型付けができないと、IDEは確実なリファクタリングを行えない

神話については、

• ソフトウェアエンジニアたるもの仕事に最適な言語を使わないといけない
• コード行が多いほどバグが多い、だから動的言語の方がよい
• 動的言語○○は構文はよりクリア、よりエレガント、よりパワフルだから○○なら生産性を上げられる

それぞれの詳細はブログ記事を読んでもらいたいが、大体はこれまでにも議論が続いてきたことだ。それより興味深いのは、この記事への反応だ。John Wilsonは動的言語について良い指摘をしている。

動的言語は万能ではありませんが、ある種の問題を解決するのには向いています。

Java は素人が使うのがどんどん難しくなっていってます（そう、ジェネリックのことです）。この点から言ってJavaに何かを加えるのは使いやすさにつながりません。IDEはプロにとっては便利ですが、IdeaやEclipse、Netbeansなどを生産性が上がるほど使いこなすには時間と努力を相当投資しないといけません。

 JVMのプログラミングに参加する障壁はますます高くなっています。これが続くならJVMは死んでしまうでしょう。JVM向けのコードがほしいなら高給なスーパースターかプリマドンナを雇うしかありませんが、活気は得られないでしょう。

もし誰かが素晴らしいアイディアを思いついて、それを2、3日の間にJythonやJRuby、Groovyなどで実装したとします。もしそれがうまくいかなくても失うものはあまりありません。しかしうまくいったとしたら、多くの問題が起きるでしょう。パフォーマンスが悪かったりスケーラビリティがなかったり保守が大変だったりするでしょう（アイディアの実装がうまくいった場合にこういうことが問題になります）。するとこの問題を解決するために人を集めることになるでしょう（Twitterを作っている人たちにはこのことがまだ分かってないようですが）。しかし最初の実装を磨き上げて実行可能にできても、今度は人が多くなったことで人間の頭から機械に落とし込むアイディアの量は激減してしまうのです。

Hypothetical Labsはこれに関してJavaは将来問題となるレガシーだと見ている(source)。

問題はJavaコミュニティが言語の変化にどれだけ対応できるかです。すべては後方互換性がないといけません。世界のどこかのアプリケーションで破壊が起きないようにどんな言語仕様も変えてはならないので、理論上は1990年に書いたコードは最新のJVM上でも動くはずです。なんと狂ったことでしょう。 [狂ってる？これがJavaだ！ -スパルタ王レオニダス1世] ひとつの決定によってもたらされる言語への変更は累積し、完全な意思の力によって切断されるべき機能にまでなります。ジェネリックがどうなったか、もしくは今のクロージャー仕様に対する攻撃のすごさを見れば、このひとつの決定によって現実社会がどれだけ巻き添えをくらうかが分かるでしょう。こうして最後に行き着いたのが言語というものであり、コアコミュニティは変更を恐れるのです。

Enrique Utrilla氏の反応は、Neal Ford(source)が書いた多言語プログラマという考えに共鳴したもので、Ola Bini氏(source)やStuart Halloway氏(source)によって提案された言語層という方法にも通じている。

私に言わせれば、結局は３つのキーコンセプトに行き着くのです。生産性、保守の容易さ、実行性能です。

これはもしかすると間違ってるかもしれませんが、動的言語はJavaを生産性の点から打ちのめしたのです。かつてJavaがCを、Cがアセンブラをそうした時のように。いろんなこと、例えばプロトタイプやコンセプトを実証するものの作成を早く行うことができます、だからそれらが凄いのです。

保守の容易さの点では、JavaやJava的言語（.NetやScala、その他動的でなく高級でない言語であれば何でもいいです）が動的言語をやっつけてきました。リファクタリングは最新のIDEで間違いなくできます。またこれらの言語ではコンパイル時に多くのバグを検出できますが、動的言語では実行時にしか検出できません。一番困るのは、時々しか再現しないことです。

私にとって一番よさそうなのは、２つのタイプの間に落とし所を作ること、言語同士で良い統合を行うことです。クリティカルなアルゴリズムのコードはJavaで書き、そういったコードを結びつけるのは好みの言語で行うのはどうでしょうか。これなら動的な実装だけよりもパフォーマンスは良くなるでしょう。この方法には、Javaと完全に統合でき構文も似ているGroovyが特に向いているでしょう（本当のところ、Groovyを使った仕事はあまりしたことがありませんが、Groovyは既に私の二番目に好きな言語になっています）。繰り返しになりますが、結局はバランスの問題なのです。

私が思うに、「コミュニティ」ということを開発者として私たち皆が考えないといけないのではないだろうか。開発者が異なる言語間やプラットフォーム間を動くことで、大量の厨房(source)コードや、”スーパースターあるいはプリマドンナ"の技巧的なコード（その後で保守をする人たちの説明書きが必要になる）が出てくるのだろうか？言語は IDEなしでプログラミングできたり、プロでないプログラマでも何か始められるほどプログラムするのが簡単でないといけないだろうか？しかもプロである私たちが新しい機能やスケーラビリティのような非機能的な特性を取り入れたり拡張したりできるだろうか？過去の仕様の保守性まで改善しないといけないのだろうか？それとも動的言語の柔軟さがあれば設計者がどんな言語やライブラリを用いたとしても後方互換性が確保されるだろうか？Javaのコミュニティは、将来新しい動的言語やJVMプラットフォーム言語コミュニティに分散して活気を失うのだろうか？

しかしBill氏のブログに戻ってみると、

このブログ記事のポイントはRubyその他を非難することでなく、その開発者たちの説得力のない口実を非難することです。

.…できればJavaについてもしてほしいものだ。

原文はこちらです：http://www.infoq.com/news/2008/02/bill-burke-dynamic-langs

• 次へ >