Halloway: A deep analysis of Ruby VS Java Myths

Relevance Consulting's Stuart Halloway recently wrote a series of blog posts about the "Ruby vs. Java Geek talk". The inspiration for this series comes from his recent experience with a zero-start, previously constrained Ruby project that has been reversed to a full-fledged Java project. In the course of the project which lasted many days, Halloway explored the following "Mistaken ideas":

　　One of the myths: Ruby works for small projects, and Java is more suitable for large, complex projects.

To sum up, Halloway argues that for small projects, problems such as unknowns can make the schedule drastically change, and that if a well-developed code base is found, developers have little code to write. In the Java context, these factors are a big advantage, as it is backed by a mature and powerful community and a group of highly experienced developers. For large projects, Halloway says factors such as the productivity of the language are more critical than the code base, which puts the weight of the balance on the side of Ruby. He noted that the current facts had been reversed and explained that:

A small project that currently works well for Ruby is: Web applications supported by the database, because Ruby on rails offsets all Ruby's disadvantage in small projects.

　　Myth two: Ruby's So-and-so features make code difficult to maintain

In response to this misunderstanding, Halloway's conclusion is that if used properly, Ruby's language features will be easier to maintain with the code it writes. For the concept of "easy to maintain code", he gives the following definition:

1. Understand the overall design of the application or module

2. Find the code you need

3. Read the Code

4. Make changes to the code

5. Check that the changes are working properly

The following are the comparative advantages of the two languages:

　　Understand the overall design idea of an application or module: None wins

[...] My experience shows that there is no language in this area that can help a lot, but good abstract concepts can help. Java and Ruby contain many of the same abstract concepts: implementing inheritance, classes, polymorphism, encapsulation, and so on.

　　See the code you need: Java wins

Because of the effective support of the IDE, Java wins in this respect.

　　reading code: Ruby wins

Conclusion: Ruby code is easier to read because it maintains the dry principle more easily.

　　Making changes to your code: Ruby wins

Conclusion: It is easier to make code changes in a dynamic language.

　　Check to see if the changes are working: not comparable

Both Ruby and Java provide good support for unit testing, acceptance testing, and continuous integration.

　　Myth three: Ruby's too hard.

Some, such as Cedric Beust, argue that Ruby is too difficult for ordinary developers. Halloway retorted that, in general, programming was not an easy task. Although some books are a gimmick in the guise of "21-day Learning to program", this is not possible. Therefore, programming with Java and Ruby is not an easy task. He advocated that:

[...] You can't reduce the difficulty by restricting the characteristics of the language [...]

　　Myth Four: It's easy to copy rails ' ideas

Halloway that this myth needs to be taken seriously, because it is true that part of it is real. Many of rails ' ideas can be copied to any other language. But there is a rebuttal to this view:

[...] Some of the other ideas are based on specific Ruby language features. Rails uses Open class, which allows us to write better, more readable object models. For example, you can write X.blank, such as code, instead of: Stringutilities.isblank (x). Alone, such distinctions don't make much sense, but as they add up, the readability of the code can be significantly improved. [...]

　　Myth of the Five: this is a game without winners

Finally, a summary of the series: Ruby wins as a language, but as a platform, Java wins-

So, can't all of us get along? I wish that in the world I live in, the preference for language does not label a programmer. We can write code in Ruby, Scheme, Scala, or Erlang, and the JVM anywhere is a harmonious society where we can live.

To allow such a harmonious atmosphere to continue, halloway the following recommendations for action to be taken: Contribute code for the JRuby project and use rake instead of ant in future Java applications.