ふーん、飲み込まれちゃうんだってさ。
しかし、バックにサンというブランドを得て、性能や普遍性で勝るJRubyが、Rubyワールドのヘゲモニーをいつの間にか奪ってしまう可能性も否定できない。現在、JRubyはRuby1.8と互換性を持っているが、Ruby1.8から大きな変更が加わるRuby1.9が登場するころに、もし万が一、 JRubyユーザーの多くが、そうした変更を嫌ったら、どうなるだろうか? Rubyが、いくつかの“Rubies”にフォークしてしまわないだろうか。ちょうど、BSDがFreeBSD、NetBSD、OpenBSDと分かれたように。
まつもと氏を中心としたRubyコミュニティは、今後どういう体制を整えていくのか。あるいは緩やかで暗黙的な連帯だけで開発を続けていくのか。それは、今後Rubyの受容がどこまで進むのかにも関わってくる問題で、今は誰にも予想ができないことなのだろう。
っていうか、「Javaのやり方」から見てるからそう感じるのかもしれないけど、 フリーソフトウェアの歴史を見てると、「Javaのやり方」の方が特殊だし。
Java界におけるRubyの存在意義のひとつは「Alternativeの提示」だと思う。 Javaの世界の当たり前が、外の世界では必ずしも当たり前でないことを示してきた。 Rubyだけがそうしてきたわけじゃないけど。
つまり、
で、フォークだけど、「したければしたらいい」というのが私のスタンス。 少なくとも現時点では「フォークしたくない(ので調整したい)」と思ってるのはJRuby側だから。 言っとくけど。
これこれ。ながらく「育てて」きた.bashrcがあると、 zshに移行するのも面倒だと思ってきたが、ヒストリの共有だけはうらやましいと思っていたので これはありがたい。
後、ワイルドカード展開もうらやましいかなあ。
「なら、さっさとzshに移行すればいいのに」と言われそう。
「静的型情報がないとヒントが少なくてコードを読み解くのが難しいんじゃない」という疑問に対する反応。結論は、「人間にとっては(多くの場合)そんなことはないんじゃない?」というもの。
Structs+Springの以下のコードと
public ActionForward edit(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { PersonForm personForm = (PersonForm) form; if (personForm.getId() != null) { PersonManager mgr = (PersonManager) getBean("personManager"); Person person = mgr.getPerson(personForm.getId()); personForm = (PersonForm) convert(person); updateFormBean(mapping, request, personForm); } return mapping.findForward("edit"); }
Rails (ActiveRecord)の以下のコードを比べてみる。
def edit @person = Person.find(params[:id]) end
で、読みやすさは言語(の文法)によるものではなく、 プログラマによるものである、という結論。
もちろん、Java文法でも上の例題よりも読みやすいコードが書けるAPIは可能だろう。 要はモチベーションの問題か。
来週のRailsConfで正式発表だとか。
日本での発表は6月5日のCodeGearイベントにて。 私もゲスト出演することになった。事前打ち合わせ、何にもしてないんだけど。