The depth analysis of Ruby VS Java misunderstanding

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:

The following is a reference fragment:
a small project that is currently suitable for Ruby is: a Web application supported by the database because rubyonrails 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