Previous Myths:
Welcome to Myth #3: "Ruby is too hard." Honest, I am not making this up. People do seriously argue that Ruby is too hard for the average developer. This is problematic in many ways.
1. Programming itself is hard. It is not for dummies, and you cannot learn to do it in 21 days. Programming languages may have a gentle learning curve, but hard problems will require hard thinking in any language.
2. In what serious discipline is "It's too hard" a legitimate excuse? I have never seen a bank that eschews multiplication: "We use repeated addition here--multiplication was too hard for our junior staffers." And I would be uncomfortable if my surgeon said "I refuse to perform procedures developed in the last 10 years--it is just too hard for me to learn new techniques."
3. Java and Ruby are both hard. I have heard the same argument made about which features to use within Java: "We don't use reflection, it is too hard to understand."
4. "We use idiot-proof tools and save money by hiring the cheapest idiots" is simply not true because there are no idiot-proof tools. Even as wishful thinking this idea sucks. It won't impress customers, and the effect on morale is easy to imagine.
5. You cannot wish away difficulty by limiting language features. If a language omits a feature that developers need, they will find a way to simulate it. This can happen on a small scale: Start without blocks, and you end up with anonymous inner classes. Or on a medium scale: Start without implementation mixins, and you end up with design patterns as code smells. Or even on a grand scale: Start with no trivial way to compose dynamic systems, and you will end up with an enormous framework that requires a second language for tedious, error-prone configuration.
This last point leads to the circular framework argument:
- We cannot use language Hund. We need simple language Blub that everyone can understand.
- Ruh-roh. Blub is not powerful enough. We must build an elaborate framework for enterprise work.
- Blub doesn't have an elaborate framework! How can we possibly use it for enterprise development?!
More than half of the code in every Java enterprise framework exists purely to work around well-known, deliberately chosen limitations at the language level. Smart Java developers have paid a staggering price to prop up the illusion that the Java language is easy.
Perhaps this is all water under the bridge. The price has been paid, and Java works. Expert Java developers can do incredible things. Those of us in the Java community should be proud of the great code we have written, in spite of the incredible difficulty of Java development.
But we shouldn't, in the next breath, say "Ruby is too hard." I for one would have trouble holding a straight face.
Comments
Actually, I completely agree with the ruby is hard statement.
As I said in another post. Look at a good java programmer and check how used his language texts are. Then look at a good Ruby programmer.
The java programmer hasn’t cracked a textbook in years, the ruby programmer uses his once a week.
Consistency is what makes a language easy. Minimal syntax that cannot be changed.
For instance. Why on earth would anyone consider throwing regular expressions into the language without quotes. Now you have to start figuring out all sorts of quoting rules for the language simply because some programmer couldn’t be bothered to type:
re(”...”)
That’s the kind of inconsistency that is just silly-pointless.
Of course, on top of that you have to be able to have DRY code. I’ve never had a problem writing DRY code in Java, but I do think that it’s probably easier for many beginning programmers to write DRY code in Ruby.
Hey, also. Could you give me references for this:
“More than half of the code in every Java enterprise framework exists purely to work around well-known, deliberately chosen limitations at the language level. Smart Java developers have paid a staggering price to prop up the illusion that the Java language is easy.”
It may change my mind.
I’ve looked through the SDK code quite a bit and have seen virtually none of the code you are talking about. I’ve also worked on enterprise client/server systems and don’t know. I haven’t worked on Java web solutions, might that be what you are referring to?
What I have noticed in Ruby is a tenancy to make really horrible code because you can use some neat language trick.
I actually saw someone comparing ruby to java who created a structure such as [array1] * [array2] but the first line was a test that excluded all cases except a1.something == a2.something.
In other words, he made an inner loop he didn’t need simply to use that stupid * operator. The funniest part is he did it as an example saying how adding a language feature cannot make the language worse, then gave a perfect example of how it did.
I would have guessed that he was simply a bit green, but he claimed to have years of java experience, so all I can guess is that his desire to use this “Neat” * operator made him stop thinking about how to actually code.
(I’m not a fan of premature optimization, but coding an unnecessary inner loop or doing an insertion sort into an array list instead of a linked list is simply bad programming, has nothing to do with optimizing!)
Hi Bill, I picked the 50% figure because I assumed that would be transparently obvious to anyone with passing familiarity with both languages. I expect the real number is much higher in most frameworks. If you pick a framework whose source code is readable I can give you some examples. Most of the low-hanging fruit is metaprogramming for accessors, validation, delegation, etc.
Joel calls this The Perils of JavaSchools
Ruby is the new perl.
$crazy^ness @abounds!
Perl is dead! Long live Ruby!