Unofficial Planet WordPress Japan

Ruby と Java についてあとで書く。

追記:

結論

どっちもやってみたらいいと思うよ！

いやほんと、これにつきる。
とりあえずそれぞれの言語にどっぷりつかってみるべき。

優劣

どちらの言語が優れているとか、そういうレイヤーの話って不毛なんですよ。
Ruby という言語のことを知らずして Ruby のことをとやかく言うことはできないよね。
逆に Ruby やってる人間はだいたい Java のことはよくわかってる。
むしろ、Java やってる人以上によくわかってるかもしれない。
（想像だけど）

適材適所

ていうか、適所適材ですよ。
Java を使うべき所で Java を使い、Ruby を使うべき所で Ruby を使う。
PHP を使うべき所では PHP を使う。
えーっと、だから逆に言うと、いくら Ruby がいいからといって、Ruby を使うべきではない所では Ruby を使うべきではないということ。
エンジニアたるもの、そのくらいの見極めができないとダメだと思う。

Ruby vs Java

実際の所、Ruby を仕事でバリバリ使ってる人ってまだ結構少ないと思う。
Ruby が好きとは言っても、ほとんどの人が仕事では Ruby 以外の言語（Java, PHP, Perl とか？）をメインに使っているんじゃないかな。
だから例えば、Ruby を知らない Java 屋さんが、Ruby プログラマと何らかの形で張り合おうとした場合、Java 屋さんは圧倒的に不利。
Rubyist は相手のことをちゃーんと把握してるから。
それに比べて Java 屋さんは Ruby のことを何にもわかっちゃいない。
この状況でどちらが勝つか。
考えるまでもないですね？

冗談はさておき。
どのプログラミング言語を使えるのか、という程度のことで他人との間に軋轢が生まれてしまうような状況ってのが実にくだらないと思うのです。
自分の考えが正しくあるためには、相手の考えが間違っていなくてはならない、みたいなね。

…

ああ、
もうちょっとまともな文章かけるようにならないと。

スクリプトを手軽に実行するためのツールを作ってみました。
ファイルに保存するまでもないような、ちょっとしたスクリプトを書くときなんかに便利です。

ダウンロード

ScriptConsole.jar

仕組み

内部的には、一時ファイルにスクリプトの内容を保存してスクリプト実行用のコマンドを直接叩いてるだけです。
Ruby とか PHP とか、その他にも、システムにインストールされていればだいたい動くと思います（なんせコマンド叩いてるだけなんで）。

動作イメージ:

スクリーンショット

実行の仕方

実行方法は以下のようにコマンドプロンプト等から実行するか、

java -jar ScriptConsole.jar

もしくは jar ファイルをダブルクリックして直接実行できるような環境になっていればダブルクリックして実行してください。

あ、java 1.5 じゃないとたぶん動かないと思います。

ソースコード

http://svn.jugyoo.org/public/ScriptConsole

これ読みました。

JavaからRubyへ ―マネージャのための実践移行ガイド Bruce A. Tate 角谷 信太郎 オライリー・ジャパン 2007-04-21 売り上げランキング : 6640 Amazonで詳しく見る by G-Tools

誤字が多いのが気になりますが、大変面白かったです。

いやー、ほんと、システム開発っていろいろあって面白い。
一体何が真実なんだか。
ま、なんにせよ、選択肢は複数あった方が良い。
テクノロジーでは解決できない問題もたくさんあるだろうけど。

Martin Fowler氏へのインタビューより引用。

Q : Javaはどこで道を誤ったのでしょうか？
Java界は、スキルの未熟な開発者にもシステムを台無しにされないようにすることに力点を置きすぎています。結果から言えば、この考えは破綻しています。銃で自分の足を打ち抜かないようにするという考え方は魅力的ですが、現実に私たちが目にしているものは理想からは程遠いものです。あまりにも複雑でひどいJavaアプリがそこら中に転がっています。

全体的に、Javaは複雑すぎるのです。「銀の弾丸はない」 [略] というのは、本質的複雑性と偶発的複雑性とを区別するということです。たとえば、給与支払システムの開発では、給与支払の業務ルールは本誌的な複雑性です。しかし、Javaの労力のほとんどを占めているのは偶発的複雑性です。EJBの大失敗はこの最たる例です。EJBは、それ自体がとんでもなく複雑なフレームワークであるばかりでなく、私たちが経験してきたアプリケーションのほとんどにとって複雑すぎます。SpringとHibernateはEJBに比べれば格段に進歩していますが、それでもまだ、偶発的複雑性に満ち満ちている印象を拭えません。
– p.28

「本質的複雑性」と「偶発的複雑性」っていうのは良い表現だなぁ。

プログラマって、複雑なものに惹かれる本能を持ってる気がする。
「こんな複雑なことをやってのけちゃう俺すげー！」みたいな。
それがバッドノウハウにつながったりもする。
あとは、焦り。
「この新技術をマスターしないと時代に乗り遅れる！」みたいな。
そういうのが問題を生んだりする。

以下、その他諸々コピペ。

EJBはだんだん良くはなっていますが、それでもまだ難しすぎます。 [略] EJBは象を撃つ大砲のなかでも最高級品なのです。しかし、筆者の知るEJB開発者のほとんどは、EJBをWebインターフェイスを備えたリレーショナルデータベースアプリケーションの開発に使っています。どんなに贔屓目に見ても、EJBに適しているのは、分散トランザクションのような高度な機能が要求されるニッチな分野です。
– p.30

[略] Javaで言語を拡張するために（Dependency Injection やアスペクト思考プログラミングといったバズワードや、XMLベースの設定を利用するような）厄介で複雑な方式が必要不可欠なのは、動的言語のような方式ではJavaの拡張が難しいからです。
– p.52

要は、DIって「苦肉の策」的なものなんじゃないかなぁ。

Javaの良くないところは、もっと素朴なテクノロジを使うべきユーザに対しても、エンタープライズフレームワークを使うように働きかけていることです。
– p.60

Javaは言語の選択肢としては安全かもしれません。しかし、正しいフレームワークの選定は、たとえ専門家であっても難しいのです。
– p.68

確かに、Javaにおいてはフレームワークの選択は非常に難しい。

ていうか、RubyがJavaに取って代わるかはどうでもよく、現時点でのJavaの問題点をきちんと把握しておくことが重要だな、と思った次第。