10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Digging Deeper Into The Myths of Ruby vs. Java
Posted by Scott Delap on Jun 08, 2007
Myth #1: Ruby is suitable for small projects, and Java is better for large, complex projects.
In summary Halloway contends that for small projects factors like the unknown can drastically alter schedule while finding an established library can leave a developer with little actually left to code. These factors are an advantage for Java which has an established community and pool of experienced developers. For large projects Holloway argues that factors like language productivity matter more than libraries swinging the advantage to Ruby. He notes that such logic is backwards to the established wisdom at the moment and explains this by saying:
Ruby is, at present, exceptionally good at one specific kind of small project: database-backed web applications. Ruby on Rails counteracts all of Ruby's small-project disadvantages
Myth #2: Ruby feature X makes code unmaintainable
For this myth the assertion is that Ruby's features make its code more maintainable when used correctly. Maintainable code is defined as:
- Understand the overall design of an application or module
- Find code you are looking for
- Read the code
- Make changes to the code
- Verify that the changes work
With the following advantages:
- Understand the overall design of an application or module : Neither
...In my experience, no language is very helpful here. Good abstractions help. Java and Ruby share many abstractions in common: implementation inheritance, classes, polymorphism, encapsulation, etc...
Find code you are looking for : Java
Java wins based on IDE support.
Read the code : Ruby
The assertion is that Ruby code is easier to keep DRY and therefore easier to read.
Make changes to the code : Ruby
The assertion is that change is easier in a dynamic language.
Verify that the changes work : Neither
Both Ruby and Java have good support for unit tests, acceptance tests, continuous integration, etc.
Myth #3: Ruby is too hard
People have argued that Ruby is too hard for the average developer. Halloway argues that programming is hard in general and can't be learned in 21 days despite what the book rack says. Java and Ruby as a result are both hard. He contends that:
...You cannot wish away difficulty by limiting language features...
Myth #4: It is easy to copy Rails' good ideas
it is noted that this myth is tricky since part of it is true. Many of Rails good ideas can be copied to any language. The counter to this however is:
...Other good ideas depend on specific Ruby features. Rails uses open classes to make better, more readable object models. For example, you can say x.blank? instead of StringUtilities.isBlank(x). Individually, such differences do not matter much, but hundreds of them add up to a significant improvement in readability...Myth #5: It's a zero-sum game
The summary item in the series takes the stance that Ruby wins as a language but Java wins as a platform:
So can't we all just get along? I want to live in a world where language preference does not define a programmer. We'll write code in Ruby, or Scheme, or Scala, or Erlang. And we can all live in harmony on a JVM anywhere.
Steps listed to promote such harmony going forward include contributing to JRuby and managing your next Java application in href="http://www.infoq.com/rake">Rake instead of Ant.
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
dynamic langs
by
serge boulay
Posted
Re: dynamic langs
by
Stuart Halloway
Posted
Re: dynamic langs
by
Marc Stock
Posted
those
by
Ahmet A. Akin
Posted
Re: those
by
Stefan Tilkov
Posted
Myth #6
by
deepak shetty
Posted
Re: Myth #6
by
Arnt E Berge
Posted
Re: Myth #6
by
Stuart Halloway
Posted
Re: Myth #6
by
Arnt E Berge
Posted
Re: Myth #6
by
deepak shetty
Posted
Re: Myth #6
by
Arnt E Berge
Posted
Re: Myth #6
by
Stuart Halloway
Posted
Why is the Java community so enchanted by Ruby?
by
Zeev B
Posted
Re: Why is the Java community so enchanted by Ruby?
by
Stuart Halloway
Posted
Re: Why is the Java community so enchanted by Ruby?
by
Zeev B
Posted
Re: Why is the Java community so enchanted by Ruby?
by
Stuart Halloway
Posted
The myth is...
by
Robert Hicks
Posted
unwriting wrong functionality
by
Shahzad Ismail
Posted
-
I really like the Ruby Language but a lot of the nice features you find in Ruby you can do in Groovy. Groovy is a pretty easy sell to java programmers wanting to dip their feet into the dynamic programming world without completely learning an entire new language. That being said, JRuby is another viable option to build apps on the VM and I am grateful for yet another great language at my disposal.
-
many times i found author's reasoning not correct because he avoids mentioning serious shorcomings of ruby platform.
-
Ahmet, can you elaborate? Which shortcomings do you refer to?
-
In non trivial projects, the programming language used is what increases your productivity/performance/scalability etc...
-
I've lately became interested in dynamic languages and looked at both Ruby and Python.
After looking at both languages I find Python is much more in tune with the Java culture:- Readability and explicitness - both Java and Python endorse clean readable code that explicitly states what is being done. Ruby for example, reminds me of Perl - a "write only" language. A language that might be very fun to write but might be very hard to maintain.
- Matureness - Python and Java are of almost the same age. They are mature languages that proved themselves again and again in production systems (e.g. YouTube).
- Vibrant community - both platforms have a devoted community and community process.
- Open source libraries - both platforms have a lot of librariesand frameworks available (a result of points 2 and 3).
It seems that there are a lot of Java developers looking at Ruby as an alternative or complementary environment and not at Python which offers a lot and is more "in the spirit" of Java. This also includes Sun that chose to hire the JRuby guys instead of resurrecting the Jython project (which has been brought back to life recently by some volunteers after a call from one of the JRuby guys).
As for RoR, there is a python-based web framework that seems to offer the same level of productivity (and some say that even more) which is called Django (used by Tabblo which was recently acquired by HP).
Looking for a dynamic language, take a look at Python; I know I did and I found it both useful and fun. -
"the programming language used is what increases your productivity/performance/scalability etc..."
This is simply not true.
Read F.P. Brooks. "No silver bullet" and you'l know what I'm talking about.
In my experience god OO solutions and god communication is what matters.
I'm sorry to say that technical solutions seldom help much. If they did it would bee an easy way out. But there are no short cuts!
So what if it takes 30% less time to implement the wrong functionality. You have still implemented it. If you find a technique that helps you hit your target then that will be what makes the difference. -
Hi Arnt, you quote out of context. The original quote was comparing the relative importance of languages and libraries. Nobody denies the importance of communication, or that no language will compensate for the wrong people and process.
The technique we use to hit the right target is a variant of Extreme Programming. We take less time to implement the right functionality.
The argument I am making about programming languages is not new, and you overstate Brooks. Of course there are shortcuts. Will these shortcuts turn a bad programmer or process into a good one? No. Will they make a good programmer or process better? Yes.
-
Hi Zeev, Python is a very nice language, and many people prefer it to Ruby. At Relevance, we have significant production experience in Java, Ruby, and Python. We current prefer Ruby for many tasks for the following reasons:
- Readability. Ruby's ability to created domain-specific languages without a parser allows us to quickly write code that is more readable than equivalent Java or Python code.
- Maturity. Ruby is older than Java.
All three languages in question have vibrant communities and plenty of open source libraries. -
Groovy is cool, there is a lot to like. But there are some worries too. We are guessing that JRuby is the better future direction, but are keeping our options open and doing work in both languages.
-
Regarding maturity - this is not an issue of which programming language is older but how much is it used in production environments. Ruby, until recently didn't have a very good VM and as far as I know there wasn't a proper language specification (heard that in an interview by the JRuby guys) - that doesn't sound mature to me.
Indeed this is changing now with the JRuby 1.0 announcement.
Hi Zeev, Python is a very nice language, and many people prefer it to Ruby. At Relevance, we have significant production experience in Java, Ruby, and Python. We current prefer Ruby for many tasks for the following reasons:
- Readability. Ruby's ability to created domain-specific languages without a parser allows us to quickly write code that is more readable than equivalent Java or Python code.
- Maturity. Ruby is older than Java.
All three languages in question have vibrant communities and plenty of open source libraries. -
There is no Java vs Ruby. There are tackling different domains entirely.
-
Well, if a language is productive for the programmer and the guy codes 30% of wrong functionality then its a problem of inefficiency of the system analyst.
Secondly, a productive language helps a programmer read the code, identify the code for wrong functionality, undo the code and write a new supposedly correct code in place of the previous one in a shorter amount of time with less worries and with slush and fruit cake :-) -
Zeev: The maturity point was humor. Of course the age of a language does not mean it is mature. Wonder where I got that idea? :-)
-
Hi Stuart, I don’t think my quote is out of context. Although I think you make some good points. You state that “Nobody denies the importance of communication, or that no language will compensate for the wrong people and process.” Well this is true, but the overly focus on programming languages tend to diminish the importance of these factors. It’s very easy to get techies in a heated discussion about programming languages, but does it really mater that much? How much productivity can you gain?
As the original post states “In non trivial projects, the programming language used is what increases your productivity/performance/scalability etc.”
Well if my post is out of context, this is out of context, because this doesn’t consider the relative importance of languages and libraries. It clearly states that language is the most important factor. This was my point. The overly focus on language often overshadows more important issues and make some people believe it’s the most important issue. -
Hi
your confusing my post with what stuart has written(his post doesnt have the quote).Though i dont think you noticed the title of my post as myth #6.
I find such language comparisons very naive.
regards
deepak -
Hi Arnt, I think we are both out of context. :-) You are quoting Deepak, not me. And Deepak's quote is intended as a myth.
-
Sorry my mistake I misunderstood. Thanks for the clarification.
-
Stuart, every language has something that will bother you. There is no perfect language. In any event, the worries you document aren't of any real consequence and the plusses of the language more than make up for it. Read Graeme's response. But hey, it's not Ruby so it will just never be as good, right? Also, you say that you thinnk JRuby is the better future direction but what makes true? I would say for the typical Java developer that Groovy is the obvious choice.
18 comments
Watch Thread Reply