Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Scott Delap on Jun 08, 2007
Stuart Halloway of Relevance recently wrote a series of blog posts on "Ruby vs. Java Myths". The series was prompted after he switched gears from working on a green field Ruby project back to a well established Java project. During the course of several days Halloway looked at several "myths":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:
With the following advantages:
...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.
The 5 Mandates of Software Development Teams - Presto Manifesto
Learning to be a Good Product Owner: Foundation Skills
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
Right Collaboration Architecture Drives Business Transformation
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:
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:
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:
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.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
18 comments
Watch Thread Reply