Ruby と Rails の導入・研修・各種コンサルをやっている Relevance, LLCという所のブログで、Ruby vs. Javaというシリーズ記事が公開されています。
- Ruby vs. Java Myth #1: Project Size
- Ruby vs. Java Myth #2: Ruby feature X makes code unmaintainable
- Ruby vs. Java Myth #3: Ruby is too hard
- Ruby vs. Java Myth #4: It is easy to copy Rails' good ideas
- Ruby vs. Java Myth #5: It's a zero-sum game
お得意のﾃｹﾄ-和訳でご紹介。今日は#1だけ。これだけでも議論になるネタが豊富にありすぎる。
Ruby vs. Java Myth #1: Project Size
Myth #1: Ruby is suitable for small projects, and Java is better for large, complex projects.
This is exactly backwards. In fact, Java is more suitable for small, well-defined projects, while Ruby is better for large, complex, open-ended projects.
Rubyは小規模案件、Javaは大規模で複雑な案件に向いているという都市伝説は正反対だぞ、と言っています。で、その論拠が以下の通り。
Javaが小規模案件に合う理由
原文の紹介は省略します。興味のある方は、原文をご覧ください。どこの部分かすぐにおわかりになるかとおもいます。
Rubyが大規模で複雑な案件に合う理由
これも原文の紹介は省略。
個人的なまとめ
これ、ネタ記事じゃないのか？大丈夫か？
小規模案件はライブラリをがっちゃんこすればすぐできちゃうって、それネタもいい所だろ。Railsのようなフルスタックでかつ「この流れで開発するとノリノリでいけちゃうよ」ならば分かるけど、Javaの場合はライブラリを統合して使うコストってのがそれこそバカにならん。StrutsとSpringとHibernateってまったく別じゃんか。所謂このSSHで1人で全部開発できますっていうJavaエンジニアがどれだけいるのかと。
仕様変更に対する柔軟性が求められるのは小規模だろうが大規模だろうが一緒。言語特性の柔軟性という意味ではRubyに一日の長があるけど、グタグタで硬直したコードを書いてしまうのは言語の問題ではなく設計の問題。ツールのせいじゃない。使い手のせい。
教育については、RubyはXXXな理由によりJavaよりも学習効率が高いのであるという話ならわかるんだけど、なんかそういう話でもないみたいだし。スキル獲得の金がないから新しい言語やフレームワークをやらないってのはありえなくて、小規模だから新たな技術を実践の場、つまりお金をもらって作るシステムの屋台骨として採用できるという事実もある。仮にトラブっても金銭的損失は少ないし、工期も自分が頑張ればどうとでも挽回できる。大規模案件は自分が頑張ってもどうにもならない。全体をコントロールできるようで全くコントロールできない。
なんというか、JavaとRubyを引き合いにして「どういうサイズの案件に適しているか」という議論は不毛だと思う。
多くの会社のエンジニアと同調したりオフショアをしたりする場合は、必然的にエンジニア人口が多いJavaが選ばれるだろう。それにRubyのIDEってコンパイラと実行環境にちょっと色つけました、ぐらいのものでしかないはず。赤の他人と開発する場合はEclipseやVisual Studioのような統合的開発環境が求められる。CheckStyleやFindBugsのようなコード品質を高めるプラグインも豊富にあるJavaの開発環境は、かなり強力な選択肢であると思う。ヒトモノカネの集合によって決められるべき。
コメント欄のご紹介
本文よりもコメントのほうが面白い件。お時間が許す方は以下コメントをお楽しみください。
But I wonder how dynamic languages work on teams with many developers? (let’s say more than 15, in 3 remote offices)
With this in mind, I wonder about some of the flexibility of the “new wave” of dynamic languages. As team size grows, does the “wild frontier” of dynamic coolness pose a threat to good development principles (in a social context) ?
動的言語による"wild frontier"が人間系の側面から優良な開発規範・指針を脅かしてしまうんじゃないのか、ということを言っています。これは「プログラマには余計なことをさせたくないのである。均質、つまりみんなが同じやり方に従う方がよいのである」という主張です。でもこの主張って「やってはいけないこと」を防ぐために言われることなんだよね。DBのコネクション管理を個々のクラスでやっちゃうとか、StrutsのActionクラスに業務ロジック書くなとか、Handlerに例外を返す設計なのに勝手にcatchすんなとか。そういう負の要素を避けるための「自由の強制」なのであって、そこから先は自由であるべきだと思う。
Large project have to be scalable. Advantage: Java. Large project could be easily outsorced. Advantage: Java. Large projects must handle a lot of workload. Advantage: Java. Large projects should just work. Advantage: Java.
Javaのほうが大規模案件に向いているよというもの。スケールさせないといけないからJava優位。アウトソースしたいからJava優位。多くの仕事量を捌かないとといけないからJava優位。動かすことが重要*1だからJava優位。
特にスケールとアウトソースのダブルパンチが印象的。確かにこの２点においてはJava優位であると思う。
Large projects mean more less-than-average-quality developers (Ruby is much more difficult to learn for the average guy), need to have strong tool based refactoring support (not possible in Ruby), more compile time typechecking support (Ruby offers no compile time type checking), ability to construct rich domain models (Rails couples your persistence logic with domain model) and a rich set of libraries and frameworks (much more in Java than Ruby).
大規模案件とは「平均以下の開発者」を意味しているので、下駄を履かせることができるかどうかも考える必要がある、と。下駄としては、ツールベースの強力なリファクタリングのサポート、コンパイル時の型チェック、リッチなどメインモデル豊富なライブラリとフレームワークなんかがあるよ、と。リファクタリングについてはRubyでもサポートしてるよという指摘と、DSL書くのはそんなに難しくないよなんていう指摘もありました。
なんかこの流れに沿っていくと、Java is next COBOLなら、Ruby is next Javaって言われるのもそう遠くないのかな。
*1:should just workの訳し方が今ひとつ・・・
