パスワードを忘れた? アカウント作成
13373 story

JRubyプロジェクトリーダーがSunに入社 27

ストーリー by yoosee
御社も誰か雇ってみませんか? 部門より

zonkerman曰く、"Sun Microsystems は、 JVM (Java Virtual Machine) 向けのRubyの インプリメンテーション開発を目指している JRuby Project の チーフメンテナーである チャールズ・ナッター氏と トーマス・エネボー氏を雇用したとのこと ( ITmediaの記事)。 両氏はフルタイムでJRubyの開発に取り組み、特に開発ツールに注力する予定。 またSunは、Javaプラットフォーム上で複数の言語をサポートする計画であり、 Javaプラットフォームとほかの言語との間の相互運用性に向けた取り組みも 進めるとしているらしい。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 今さら (スコア:2, 興味深い)

    by Anonymous Coward on 2006年09月12日 17時10分 (#1017105)
    JVMで複数の言語か。何年もすべきだったことだけど、今となっては.NETに対する敗北としか思えない。
    何から何まで後手後手に回ってるSunを象徴してるように思う。
    • Re:今さら (スコア:3, 興味深い)

      by SteppingWind (2654) on 2006年09月12日 19時19分 (#1017165)

      対応言語が多いって, 特にエンタープライズ用途ではあまり有効に働かないんじゃないかな? 特に一定の品質を求めるとか, 実運用に入った後のメンテナンスなんてことを考えると, 最大公約数的な言語ひとつ(多くても2つ)でやっちゃった方が良いわけで.

      かってCOBOLが主流だったころには, デシジョンサポートや医薬統計処理の数値計算までCOBOLで組んでいたなんて話もあるぐらいですから. まあ, 単なる趣味の領域では使える言語が多いほうが面白いんですけど.

      親コメント
      • Re:今さら (スコア:3, 興味深い)

        by Anonymous Coward on 2006年09月13日 1時32分 (#1017386)
        どちらかというと世代交代という言葉がチラつくような気がします。

        ●10年くらい前はC(C++)。
        ●今は(JVMはさておき言語としての)Java。

        それが「ちょうどその(この)時点で引導を渡されつつある言語」なのでしょう。

        Javaの生産性にはぼちぼち限界を感じつつあります。C/C++の延長な伝統的世界観の、型が下手に強い変数(そのくせHaskelよりチャチ)とか、狭い意味での関数/メソッドしか無い(そういやC#もJavaもClosure追加しようと悪あがきしてますねえ)とか、要するに古さが目立つんですよ。生産性の低さが目立つ。

        脱線になりますがJakartaのBeanUtilsが結構笑えます。ありゃJava上で断片的に動的言語ごっこをしようっていう腹だ。動的言語のうまみを少しだけ摘み食いする感じです。つまりそうしたほうが生産性が高いんですよね。

        そうそう生産性。そういう危機感ないしはマンネリ感(?)を感じてる人が多いんでしょうね、下々にもトップメーカーにも。だからMSもSunも自社のVM(&バイトコード)の動的言語むけ機能拡張をぼちぼち始めていたりする。

        今後。あっという間に入れ替わるってことは無いでしょう。ただ、次の十年の潮流はコレだ…という可能性が凄く高いとは思います。つまり「最大公約数的な言語ひとつ」と5ないし10年後に呼ばれるであろう選択肢は、RubyやPythonあたりなのではないかと。

        まずは来年あたり、VisualStudioでIronPythonが、NetBeansでJRubyが、動くようになるんじゃないですかね?あとEclipseのプラグインもJRubyで書けるようになるといいですね。JavaWorldのコードサンプル(もちろん殆どがJava言語)なんて眺めてると胸悪くなってきます。はやいとこLLに置き換わって欲しいものです。

        MSのPowerShellは正直おしゃれだと思うのでAC
        シェル言語とSQLと関数型言語のエッセンスをうまいこと混ぜやがった…
        親コメント
        • クロージャなんていうものがソフトウェアエンジニアリング上使い物になるのでしょうか。こういうときに便利だというのがあれば教えてもらいたいです。

          ところで私はJava派だったのですが、最近VB6.0とかASPとかで無節操にExcelとかのオブジェクトを使って作るプログラムに妙に感動しています。これが理想とは言いませんけどね…。
          親コメント
          • by Anonymous Coward on 2006年09月14日 1時08分 (#1018068)
            anArray.sort(new Comparator(){
                int compare(T o1, T o2){
                    return o2 - o1;
                }
            });



            anArray.sort{|o1, o2|
                o2 - o1
            }

            になるだけでも、十分強力な(開発プロセスの)燃料だか潤滑剤だかだと思います。

            あ。これだけ短いので行を分ける必要すら感じなくなりますね。

            anArray.sort{|o1, o2| o2 - o1 }

            こんな風に5行を1行に詰めるだけでも「ちりつも」なんですよ、開発って奴は。その差は(劣ってるほうにとっては)ボディブローのようにじわじわと効いてくるんです。

            そして、偉い人(例えばプログラマをあごで使うような立場の人)にはそれが判らんのです。プログラマの辛さを省みない。だから上記の差を埋めようという偉い人サイドで必要な努力(たとえば「より書きやすい言語で開発するように采配する」など)をしない。

            そういった辛さの積み重ねが、開発においての「ちょっと面倒だな(だからxxxをやらない)」を生み、xxxをやらないせいで更に大きなyyyをやるのが面倒になり…と、いつしか雪達磨式に「面倒」「実装の手抜き」が積み重なっていくんです。

            逆にシンプルに書ける書きやすい言語は、「より高度な洗練された書き方」を「さほど負担※と感じずに」使えます。ということはプログラマは自然とより高度な書き方に導かれるわけで、そうすればバグは減ります。

            ※この「負担」という感覚が、Matz氏あたりが言う「脳力」という奴に通じるのだと思います。

            また、上記でもちらっとやりましたが(1行にまとめちゃった辺りね)、一箇所がシンプルになるおかげで、更にまとめてシンプルに書けるという「シンプル化の連鎖」が起きたりします。

            >ソフトウェアエンジニアリング上

            上記の「差」を把握できないようなエンジニアリングは、使い物にならない似非エンジニアリングだと思われます。エンジニアリングは突き詰めれば現場がスムーズに動いてナンボでしょ?

            同じ処理をより楽に。同じ手間ならより高度に。そんなふうに書けるほうがいいに決まってます。

            なお「既存の言語への慣れ」の話を言い出したらキリがないのでパスします。

            >こういうときに便利

            もう1つ、リソース管理系ですね。

            「便利」という呼び方は少々正確ではありません。やるべき処理を「忘れにくくなる」「怠りにくくなる」ってのが真相です。つまり人間がやりたいことをやってくれるというよりは、人間がやりたくないことを(かわりに)やってくれるって感じです。

            x = new Resouce()
            try{
             x.use();
            }finally{
             x.close();
            }

            なんてなコードが、

            Resource.open{|x|
             x.use()
            }

            という風にCloseを意識しなくて済むようになるってのは、ボディブローが確実に減ります。FileのCloseやDBのCommit(あるいはエラー時にRollback)を殆ど絶対に忘れなくなるってのは、大きいですよー。

            CommitとRollbackの使い分けについては、Exceptionが挙がったときも(挙がらないときも)ブロックから出たら上記のopenメソッドの中を必ず再び通るというカラクリになってるので、そこで内部的にCatchやFinallyを使ってCommitかRollbackかを切り替える、というような実装になります。

            なんというか、括弧の内側と外側を別々に(内側はインライン、外側は関数として)実装できるという感じです。はっきり言って便利…というか「快適」です。

            エンジニアリングくさい話でいえば、たとえばベテランとビギナーがコードを分担して書くとき、ベテランにopenメソッドを実装させ、ビギナーにそれを「使え」と命じるという手がありますね。Java方式だとtry云々という長ったらしい慣用句と例外処理(を入れるタイミング)を習得してないビギナーはコードを全く記述できませんが、Ruby方式だとリソースの面倒見は全部Openメソッドのほうで見れるから、ビギナーはヤワなブロックを書くだけでOK。

            なお今月(?)号の日経ソフトウェアのRuby記事はなかなか的確にRuby(などのLL2.0?)のメリットを指摘していますので一読をお勧めします。

            余談になりますが、JavaでAOPしている人々は、ちょうど上記のような「分担」をAOPで実現しようとしてる節があると思います。が、そんな大げさなことをしたり設定ファイルを書いたりしなくても、クロージャさえ有れば簡単に実現できるのですよねえ。しかもリソース管理する側の処理も(AOPみたいに複雑なコーディングをしなくても)簡単に作れちゃう。

            class DB
             def open(&block)
              x = DB.new()
              begin # tryに相当
               block.call(x)
               x.commit()
              rescue # catch
               x.rollback()
              end
             end
            end
            ほらできた。簡単。

            DB.open{|x|
             x.update(hogehoge)
            }
            使うときはこんな感じ。

            >無節操にExcelとかのオブジェクトを使って

            JakartaPOIだのCOM-Javaブリッジだのを使うというのはどうでしょう?私はRubyのWin32OLEにするかな。
            親コメント
            • > anArray.sort(new Comparator(){
              > int compare(T o1, T o2){
              > return o2 - o1;
              > }
              >});

              >が

              >anArray.sort{|o1, o2|
              > o2 - o1
              >}

              それは「クロージャの」メリットじゃない。だって、enclosing scopeの変数を参照してないから(匿名関数=クロージャ、ではない)。単にRubyのブロックが、Javaの匿名クラスよりタイプ数が少ないと言えばいいだけのこと。
              • いい質問ですねえ(^^;
                ええ。ご指摘そのものは、その通りです。

                で、じゃあ本当にクロージャの話をしようと思ったら、
                このタイプ量の違いが更に激烈に開くことになるんですよね。

                Javaに限った話をすると、匿名クラスの外の変数を匿名クラスの中から参照したいとき、final宣言された変数であることが要求されています。つまり変数というよりは定数です。

                それって、変数名と値のペアは覚えているものの、その両者のつながりを司っている何者か(すなわち環境)を覚えることは拒絶してるということになるわけで、つまりクロージャ(でブロックの中から値を持ち出すこと)が出来ない。

                ということは
              • 相変わらず、細かいツッコミが中心になりますがご容赦

                > Javaに限った話をすると、匿名クラスの外の変数を匿名クラスの中から参照したいとき、final宣言された変数であることが要求されています。つまり変数というよりは定数です。

                これを定数というのは、一般的な言葉の使い方としては正しくないですよね。関数型言語では、変数自体は通常immutableなわけですが、それを持って関数型言語の変数は定数だと言ったりはしないわけで。まあ、単なる用語の使い方の問題ですが。

                > final HashMap env = new HashMap();
                > anObject.hoge(new Fuga(){
                >  int doFuga(){
                >  env.put("xx", "yy")
              • ん?生成時に一度だけ値を設定できて、あとは変更できないってのは、「定数」そのものでは?地方によってそう呼ばないかどうかは別問題でしょう。

                >Genericsの機能を活用して、もうちょっとマシにできる

                いやー。なんか凝ったコードどもっす。static importを使ってrefを予約語まがいの使い方をしてる感じですね。私としてはちょっと腰が引けます。

                私なら、そういう慣用句を30回くらい書いた(書かされた)頃には、「そう書かざるを得ない」言語仕様に対して殺意を抱くでしょう(^^;。JavaについてはそれこそJava7でクロージャがつくかもだそうなので、うまいこと私の殺意を回避
              • #1021135です。

                > 私なら、そういう慣用句を30回くらい書いた(書かされた)頃には、「そう書かざるを得ない」言語仕様に対して殺意を抱くでしょう(^^;。

                自分もこの仕様に関しては、むかつきますが、そこまで強烈ではないですねえ。まあ、言語仕様に対するスタンスの違いなんでしょうけど。

                > JavaについてはそれこそJava7でクロージャがつくかもだそうなので、うまいこと私の殺意を回避したなぁと思ってるところです(はぁと

                最初のドラフトは良かったのですが、最近になって改訂されたやつを見てみたところ、改悪されてたので、自分はむかつきました(笑)。
          • http://www.jbook.co.jp/p/p.aspx/3199684/s/ [jbook.co.jp]
            オープンソースマガジンの今月(?)号に
            「クロージャとオブジェクトの微妙な関係」
            というビンゴな記事がありますね。
            (書いたのはGaucheの川合史朗さんですね。)

            エンジニアリングですか?
            言語の古臭い機能だけを使わせることで
            雇用者が労働者を「管理」しやすくし、
            そのぶんの皺寄せをぜんぶ労働者に押し付けるのは
            そろそろ勘弁してください。
            そろそろストライキだの革命だのを起こしたくなります。

            時間ばかりかかるコーディングスタイルを強いる「から」、
            人月などという怪しげな単位が意味を持ってしまう。
            本末転倒です。
            品質を上げるために新機能を使う。
            そして人月も無意味化する。
            あるべき将来像はコレです。
    • Re:今さら (スコア:2, すばらしい洞察)

      by kicchy (4711) on 2006年09月12日 17時25分 (#1017113)
      >JVMで複数の言語か。何年もすべきだったことだけど、今となっては.NETに対する敗北としか思えない。
      >何から何まで後手後手に回ってるSunを象徴してるように思う。

      そうかなぁ・・・
      むしろ、単言語であったのでJVM側の改良に専念できていた
      という面もあるとは思うんだけど・・・・
      ただ、単に多言語対応というよりスクリプト言語対応
      という側面が強いとは思う。時代の流れかな?

      まぁ、SUNもようやくゆとりが出てきたってことで。
      (やはりコレが実情か?)

      私は、ほとんどJava側のニュースしか追ってないので
      .NETは、多言語対応ということでどの程度成功しているのか
      事情を知ってる人に聞いてみたい。

      # 取りあえずVBとC#に関しては認識してます
      親コメント
      • LL対応 (スコア:0, フレームのもと)

        ただ、単に多言語対応というよりスクリプト言語対応
        という側面が強いとは思う。時代の流れかな?
        Java と同世代の、あまり生産性が期待できない言語に複数対応してもらっても嬉しくない。
        JVM としてなりふり構わず生き残りを図る方向でしょ。
    • by Anonymous Coward
      Delphiも買い取ってJVM版を開発してほしいなり
      • by zilog80 (31064) on 2006年09月12日 22時30分 (#1017282)
        Visual Basicを。.netじゃないやつ。
        親コメント
      • by Anonymous Coward
        いや、ここで、C# on JVM。

        というのはさておき、
        元々、多言語を想定して作られた、CLR/.NET Frameworkに比べ、
        Javaしか想定していなかった(ですよね?)JVM上での多言語展開は
        制限が多いんじゃないかなーと素人考えに思います。
        特に、リフレクション周りとか、値型の扱いとか。
        • Re:今さら (スコア:1, 興味深い)

          by Anonymous Coward on 2006年09月12日 19時05分 (#1017157)
          > 元々、多言語を想定して作られた、CLR/.NET Frameworkに比べ、

          確かに多言語を想定してるんでしょうが、既存言語に対応することを想定して作られたようには思えません。

          #偏見かもしれないのでAC
          親コメント
        • Re:今さら (スコア:1, 興味深い)

          by Anonymous Coward on 2006年09月12日 22時16分 (#1017273)
          > Javaしか想定していなかった(ですよね?)JVM

          そんなことは無いと思いますけどね。Java VM仕様
          第2版でも、Java以外の言語でもクラスファイルにコンパイルできる云々の記述がありましたし、そのことを全く念頭に置いていなかったとは思えません。もちろん、CLR/.NET Frameworkに比べると、Java中心の仕様になっているのは否めないとは思いますけど。ちなみに、リフレクション周りの仕様が原因でJVMでは、他言語展開が面倒ということはまず無いと思います。
          親コメント
          • Re:今さら (スコア:4, 参考になる)

            by Anonymous Coward on 2006年09月12日 22時41分 (#1017289)
            JVM そのものは、多言語を想定してた風はありますが実際のところ VM/クラスライブラリ/Javaの言語仕様の境があいまいなまま設計されてしまってるので、他の言語を素直にのせるというのは本当に難しいですよ。

            .NET の場合、クラスライブラリ、VM(CLR)、言語が完全に独立するというのが大前提で設計されてるので多言語の共存が容易です。
            それこそCOBOL で実装したクラス(!)を C# で継承して使うなんてのも何のトラブルもなく実現できるわけです。さらにそれを sather で継承して、結局 COBOL で使うなんてのも、何の問題もないわけですよ。
            .NET の場合 int のようなプリミティブな型が存在せず、全てクラスライブラリに置かれますが、クラスライブラリそのものが多層に分かれていて、言語仕様が知っていなければならない型(Int32など)が定義されている層と、言語仕様が知っていてはならない型も明確に切り分けられてます。なのでC++などプリミティブな型の存在を前提にしたような言語でも .NET 上に実装できるわけです。
            現実的(ただし人によっては好みが分かれる)な切り分けには、完璧なまでの一貫性があり理論矛盾や一貫性を損なうような拡張がないのが.NET の最大の特徴だと思います。
            個人ベースの物からメーカーが作るような大規模なものまで多言語環境が矛盾なく共有できる環境が作られてるのは、そういった最初の想定ゆえでしょう。
            JVM での言語ポーティングを諦めたり中止して、.NETに移行しちゃうプロジェクトが目立つのも、このせいではないですかね?

            まぁ Java と比べて 後発の.NET が(ソフト資産を除けば)あらゆる面でよく出来てるのは当たり前なわけです。
            先に出てて成功したものを真似して、失敗してあぁしとけば良かったって物を全部直してから出せるんですからね。
            典型的な後出しジャンケンなわけです。
            親コメント
            • by Anonymous Coward
              例外は退化しているのであらゆる面で上とはいいきれんなぁ。enumの実装もイマイチでしょ?

              .NETは現実的な路線を目指し、VBとC++,C#といった3本の柱をOSはWindowsで動くものと(ほぼ)過程して作ってると思うが。

              おかげで一番割り食ってるのはVB.NET。言語仕様だけそれらしいのを作ったけど、VBってのはそんな部分がうけたんじゃねーって。
  • ライセンス (スコア:1, 興味深い)

    by Anonymous Coward on 2006年09月13日 1時15分 (#1017381)
    IronPythonは作者移籍のさいにライセンスがShared Sourceに変更された。

    JRubyもSun独自の変なライセンスに変更されたりしないだろうな?
    そこがちょっと心配だ。
  • 便乗してPython (スコア:0, オフトピック)

    by Anonymous Coward on 2006年09月12日 15時47分 (#1017058)
    作者がMSに雇用されてしまったJythonはもうダメなんだろうか。IronPythonもかなりいいけど、見捨てないで欲しいな。
  • by Anonymous Coward on 2006年09月12日 16時37分 (#1017088)
    Matz氏曰くとうとう来たよ。そういう時代が。 [rubyist.net]

    #それだけなのでAC
    • というか、リンク先も「それだけ」なのね。
      何か他に書いてあるのかと思ったんだけど。

      # それだけなのでAC
  • by Anonymous Coward on 2006年09月13日 0時29分 (#1017358)
    いやー、すてきだなぁ。AS400は間違ってなかった。

    JVM vs CLR vs Parrot

    ってところかな?他に何があるかなー?
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...