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

Ruby on Railsはゲットーだ」記事へのコメント

  • RubyとRailsを切り離せ (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2008年01月02日 19時32分 (#1274648)
    まずRailsは決して「敷居を下げる」ようなものでは無かったはずだ。
    以前誰かが書いてたが、
    あのGoogleがNice Hackだからといって授賞したのがRailsだ。
    つまり下々の企業じゃなくHackerがうじゃうじゃ居るような企業にとってNiceだということだ。
    ヘタな奴がヘタに使うと危険。逆効果に成りかねない。
    (これはRailsではなく誤解する人々が悪いだけだが。)

    次。Rails(で作ったアプリ)って
    書籍のサンプルレベルですら「コードが綺麗じゃない」のだよね。
    綺麗といっても別にJavaのごとく書いてくれという意味ではなく、
    なんというかRailsアプリのそれは、
    字面がごちゃごちゃしてるんだ。
    念のため言うけどそれはRubyの性質ではなく、Rails固有の性質のようだ。
    つまりRailsで作ったコードは「Rubyらしくない」。
    個々の道具である例えばActiveXxxxを使ったコードが汚いわけではないのだが、
    なぜかRails全体で見るとゴチャゴチャになる。これは不味い。

    あと良し悪しはともかく気になる点が、
    Railsはアーキテクチャには何ら新しい工夫が無いって点だ。
    コードが短くなるのは良いことだが、それでも所詮はMVC2だ。
    その(利点もだが)欠点もそのまま無批判に輸入してしまってる。
    ここは一応警戒しておいたほうが良い点であろう。
    #WicketのようにアンチMVC2、あるいは新SeasarのようにMVCっぽさをボカす、という手も有るのよ>Webアーキテクチャ

    さて。
    Railsに決定的に不味い点あるいは不幸な点があるとすれば、
    それは「一人勝ち」状態だという点だ。
    ライバル不在なのだ。
    もっとマシ(例えば下々がハマリにくいとか綺麗に書けるとか)
    になるための競争が起きていない。
    少なくとも登場してブレイクして以来ここ数年はそうだ。
    そのためRailsが「進化の袋小路」に陥ってしまってる恐れが有るし、
    もし陥ってしまっていても、
    その欠点を速やかにアゲつらうための「比較対象」が居ない。

    同じくライバル不在としてはMS謹製の各種フレームワークが有るが、MSは伝染力が元々最強なので、ヘマをやってもMSが失うものが少ない。RailsがコケたらRubyコミュ全体が不安だという構図とは一緒にならん。そういう意味では「フルスタック」も良し悪しだ。

    これはRubyコミュニティ全般にとって不幸なことだ。

    Matz氏も「流行るかどうかは気にしない」と言っているが、
    それは流行曲線が平坦または上り坂だった時の話かも知れない。
    もし下り坂になってもRubyを維持する気力が彼から沸いてくるか、
    あるいは彼を支援する企業つまり氏の収入が維持されるか、は、
    十分心配すべき事柄だ。

    個人的にはRubyのファンなので、
    彼(Mongrelの作者かよ!!)に「Rubyが」見捨てられるのは忍びない。
    (Railsは比較的どうでもいいけどな。というかRailsバブルが弾けるときにRubyを道連れにしないでくれ。)

    だから、
    Railsに対抗するようなWebアプリフレームワークがRuby上に沸いて出てくれることを
    強く祈っている。
    しかも可及的速やかにね。たぶん勝負は年内だろう…

    あるいはだ。
    俺様の気が変わって或る日フレームワークを作ったならば、
    藻前ら総出でそれを崇め奉れ!
    それでこの問題は解決するぞ!:-)
    #作るまでは名乗る気がないのでAC
    • by Anonymous Coward on 2008年01月02日 23時41分 (#1274709)
      そかなー… 自分が使ってみた限りでは、"それっぽいものを適当に作る"
      という前提ならかなり敷居が低い部類かと。

      が、細かいことを考え出すとハマる。
      例えば、Ajaxのリクエストでチャッタリング起こしてて、溜まっている
      キュー捨てらんないのか? ちゃんと設定すれば対応できるのかもしれない
      けど、その調べものに余計な時間かけてなお解決せず挫折。
      なにが高速開発だ、ウキー…ってな具合。
      結局RoRとグッバイして自前で作り直しましたとも、えぇ。
      親コメント
      • by Anonymous Coward
        つーかさ、何でLLで大げさなフレームワーク使わにゃならんの?
        LLを使う動機が丸つぶれな気がしてならないんだけど・・・。

        # 楽しくねーじゃん
        • by Anonymous Coward
          >何でLLで大げさなフレームワーク使わにゃならんの?
          何でAjax使った位で、サービス名に「Beta」ってつけなければいけないの?と同じ事(ウソ)
          ていうかLLだから、フレームワークとは無縁と考えられるのは経験不足としか思えない。

          マジレスすれば、大げさなシステムを仕事で作っていれば定型的手順を繰り返し作る事になる。
          そこを、蓄積されていく社内ノウハウを詰め込んだ社内フレームワークで賄うのもいいけど、
          それだと人集めや教育、メンテで余計なコストが発生するのでフレームワークに飛びつきたい
          というのが全てのフレームワークに共通している潜在的な需要で、LLだから要らないと
          • by Anonymous Coward
            >個人が思いつく範囲の動機なんて
            >世間の会社の企みとは乖離していて、たかが知れているという事ですよね。

            それは逆だろう。
            むしろ企業のほうが高が知れてるんだ、「LLの使い方」においては。

            全部ではないが典型的企業(の中の人)においては、
            LLのよさを活かす使い方なんて、思いもつかないものだ。
            硬い開発体制を取れば安泰、そうでなければ死、と信じて疑ってない。

            味噌はそこではない。
            1つの案件が有るとして、その案件が軽いか重いか、の判断が、
            (優秀な)個人と企業とでズレてるのだろう。

            優秀な個人ならばだが、彼らは同じ仕事でも「軽い」と判断する(という率が高い)はずだ。
            LLなりなんなりといった美味しい道具を美味しく駆使して、
            案件を「軽くして」しまうことが出来る。

            で、その優秀な人についていけないのが、(普通の)企業のレベル。
            同じ案件でも重く評価してしまい、重い開発体制にしなければならないと判断してしまう。
          • by Anonymous Coward

            そこを、蓄積されていく社内ノウハウを詰め込んだ社内フレームワークで賄うのもいいけど、 それだと人集めや教育、メンテで余計なコストが発生するのでフレームワークに飛びつきたい というのが全てのフレームワークに共通している潜在的な需要で、LLだから要らないとはならない。

            ひがさんも同じようなことを言われていたと思うのですが、実際に社内フレームワークをどこの会社も使わなくなってきているのでしょうか?
            某社の場合、今だに社内フレームワークに固執しており、またオープンソースを使うことは堅く拒否し

            • by nim (10479) on 2008年01月06日 22時07分 (#1276091)
              >上から下まで全て自社製品でなければ

              まあ、突き詰めていえばそんなことが可能な企業なんて、今や全然思いつきませんけどね。
              そもそも、CPUベンダとOSベンダを兼営しているところが数えるほどしかない。
              一部大手メーカーの携帯電話はそんな感じかもしれませんが。
              親コメント
          • by Anonymous Coward
            そもそも、業務システムの重要な部分にLLを使わないから。
            フレームワークなんざ出番が無い。出番があるとしたらJavaのやつ。
            1000万オーバーのプロジェクトだとLLの出番なんて補助的なツールとか
            だけだもんなぁ・・・。

            そういう意味では、必要と思ってる人は「実務経験」が不足してるんで無い?
            • by Anonymous Coward
              厨房な釣りに乗るのもなんだが、1000万って単位は円?桁が違うだろ…。
              億くらいまではLLの案件なんていくらでもあるって。
              ここ五年はもっぱらLLを使っているが、Rubyで1000万、Perlで5000万、PHPで7000万くらいまではある。
        • by Anonymous Coward
          大きな「仕事」も、
          LLで(やれるものなら)やりたいという願望は、
          十分理解できると思う。
          大規模な仕事だったらJavaでやります、とか言っちゃったらちっとも楽しくないわけ。

          そして、いわゆる「こまかいところまで弄くれる性質」は、
          非LLからLLに換えたところで、
          別に言うほど損なわれるわけじゃない、
          というのは我々プログラマは(直感的にだが)知っている。

          …まあこの直感的ってのが急所でもあるんだけどね。
          つまり、実績というか「実際にやってみて確認した事例」がまだ少ない。
          実は出来ないのかも知れない。
          出来るかも知れないけどやりかたを少々変えないとならないのかも知れない。
          だけどまだ
          • by Anonymous Coward
            LLでの開発がJavaでの開発より楽しいという前提がすでに間違っているような。

            Java言語そのものより、大規模なウォーターフォールで資料の作成等や面倒な手続き等が問題になってるだけだと思いますけど。
            Javaでも軽い開発はいくらでも出来る。
            言語を差し替えても何の効果もありゃしませんよ。
            • by vn (10720) on 2008年01月04日 0時55分 (#1275032) 日記

              Java言語そのものより、大規模なウォーターフォールで資料の作成等や面倒な手続き等が問題になってるだけだと思いますけど。
              Javaでも軽い開発はいくらでも出来る。
              言語を差し替えても何の効果もありゃしませんよ。
              "Java がボトルネックではない状況ならば、Java を排除してもスループットは上がらない"
              ということを主張しているように読める。それってトートロジーじゃないの?
              親コメント
              • by Anonymous Coward
                え?
                俺、関係ない人だけど、

                > "Java がボトルネックではない状況ならば、Java を排除してもスループットは上がらない"
                > ということを主張しているように読める。それってトートロジーじゃないの?

                「A が原因でない状況ならば、A を排除しても意味がない。」の場合に、
                どこがどこでトートロジーになってるの?

                # いや、あたりまえにきこえたんでさ
              • by vn (10720) on 2008年01月04日 21時11分 (#1275392) 日記
                TOC [wikipedia.org]

                「ボトルネック」と「スループット」はコテコテのこの辺の用語だから、
                説明するまでもないかな、と思ったんだけど、確かに知らない人には
                通じない書き方だった。
                親コメント
              • by Anonymous Coward
                すいません、折角、教えていただいたんですが、
                リンク先を読んでもわかりませんでした。

                リンク先の、この辺に注目したのですが、
                > ボトルネックプロセスにおけるスループット(生産率)の増大によってのみ、全体的なスループットの増大が可能になる。
                ボトルネックではないプロセスを改善しても、スループットは向上しない様に読めます。

                多分、注目する箇所がなにか違っているのだと思いますが、
                どの部分がどの様に繋がってトートロジーになるんでしょうか?
            • Javaの方が、Rubyより、定型的なコードが多く必要だってことは間違いないところじゃないかな。JavaのIDEには、コード補完の機能がこれでもかと入っているわけですが、定型的なコードを大量に書かなければならないから、そこを改善すると利用者の「効率あがった感」が高いので注力されているのだと思うのですが、違うかな。

              言語を差し替えても何の効果もありゃしないのであれば、Java言語仕様のバージョンアップも何の効果もないはずでは?

              # 個人的にはクロージャや高階関数のない言語では仕事したくないね。してるけど。

              親コメント
              • by Anonymous Coward on 2008年01月05日 1時30分 (#1275473)
                がちがちのウォーターフォールで、打ち合わせとそのための資料作りが作業の大半を占めるような開発では、どんな言語を使ってもあまり変わらないでしょう。もともとプログラミングの占める割合が小さいのですから、いくらプログラミングを手っ取り早く済ませても、全体に与える影響が少ないのです。
                逆に、開発作業におけるプログラミングの割合を大きくすれば、言語やライブラリの違いが大きく効いてくることになりますし、適切な言語・ライブラリを選択することで楽な開発にすることが可能になるのです。
                親コメント
              • 「何の効果もない」というのが「全体に与える影響が少ない」に後退したと読みましたが、それでいいですか?

                ついでにいうと「プログラミングを手っ取り早く済ませられる」かどうかがRubyの評価につながっているわけではないと思います。「楽しく」プログラミングできることが重視されていることが、Rubyが評価されている理由だと思います。そしてモチベーションがプロジェクトの成功率を左右すると考えている人々が、Rubyを支持しているということだと僕は理解しています。

                # もっとも、それでもJavaが負ってきた責任のすべてをRubyに任せられるとは思っていませんが。

                親コメント
              • by Anonymous Coward
                Ruby使ったつまんない仕事も、Java使った面白い仕事もあるんだし、言語そのものでモチベーションが左右されるということは無いでしょう。もちろん、言語ごとに仕事の傾向はあると思うし(.NETなら事務処理が多いとか、アセンブラなら組み込み系が多いとか)、現状でRuby使える仕事なら楽しいプログラミングの期待値が上がるというのもわかりますけどね。
                #最近自分がやってて楽しいと思った仕事はP2Pネットワーク内にオブジェクト流して
                #分散処理ってやつだけど、Java使った。

アレゲは一日にしてならず -- アレゲ見習い

処理中...