パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

JRubyプロジェクトリーダーがSunに入社」記事へのコメント

  • 今さら (スコア:2, 興味深い)

    by Anonymous Coward
    JVMで複数の言語か。何年もすべきだったことだけど、今となっては.NETに対する敗北としか思えない。
    何から何まで後手後手に回ってるSunを象徴してるように思う。
    • 対応言語が多いって, 特にエンタープライズ用途ではあまり有効に働かないんじゃないかな? 特に一定の品質を求めるとか, 実運用に入った後のメンテナンスなんてことを考えると, 最大公約数的な言語ひとつ(多くても2つ)でやっちゃった方が良いわけで.

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

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

        by Anonymous Coward
        どちらかというと世代交代という言葉がチラつくような気がします。

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

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

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

        脱線になりますがJakartaのBeanUtilsが結構笑えます。あ
        • クロージャなんていうものがソフトウェアエンジニアリング上使い物になるのでしょうか。こういうときに便利だというのがあれば教えてもらいたいです。

          ところで私は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でクロージャがつくかもだそうなので、うまいこと私の殺意を回避したなぁと思ってるところです(はぁと

                最初のドラフトは良かったのですが、最近になって改訂されたやつを見てみたところ、改悪されてたので、自分はむかつきました(笑)。

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

処理中...