Skip to main content

What Ruby could learn from Java (and a bit of the vice-versa), is it time for a Ruby Community Process?

Posted by boneill42 on April 7, 2008 at 7:34 PM PDT

The other day one of my team members was complaining about the lack of
documentation in Ruby on Rails. I had to think for a minute because I
never had problems finding information I needed. It finally occurred
to me that the ruby development and documentation cycle is very
different than Java's.

First of all, ruby code *is* documentation. The constructs,
conventions and style used in ruby (e.g. the unless construct, and
underscores in verbose method names) make the code more descriptive.
The code is readable. Evidence of that is found in rdoc, which
is ruby's JavaDoc equivalent. The actual code is embedded directly into the rdoc pages, as if it were part of the description.... because it is!

Ruby also attracts a different crowd (at least for now). Ruby
developers enjoy riding at the forefront of the technology wave. This
makes them more likely to have blogs. And they use those blogs to
document code recipes, successes, etc. Those blogs get absorbed into
the ethos, indexed by the engines, and reiterated by the rest of the
blogosphere like a big echo chamber. Consequently, the blogosphere is
the biggest ruby manual and how-to in existence.

Now, that suits some, but not everyone. Despite the readability of
the code, and the mass of the "documentation" on the web, I completely understood what my friend was getting at. There are very few ruby "specifications" that you can download, read, and process in their entirety.

One could argue that the success of Java is in (a large?) part due to
the success of the Java Community Process (JCP). You may dispute the
quality of the APIs themselves, but the JSRs fill a real need. The
specifications coming out of the JCP give individuals and enterprises
a firm fixed interface on which to hang their hats.

To my knowledge, Ruby has no such organization. Without it, when
developing a ruby application, you are left praying you stumbled upon
the right blog post, at the right time, with the right solution.

The importance of community accepted interfaces becomes even more
important when considering pluggability, and solution portability.
Recently, I ran into the need for HTTP Digest authentication in Rails
App. I found lots of proposed solutions, and a ton of authentication
plugins, gems and modules, but none of them were swappable, and not
one of them offered me a "standard" means of achieving digest
authentication. In Java, I could have gone to the JCP, found a
suitable interface, examined the vendors that passed the TCK tests,
and gone about my business knowing (at least in part) that the
interface I was about to use had some consensus and support behind it.

Alas, I love Ruby. I love Rails. They are a joy to program in. And
for that reason, I'm entirely okay with the "faith factor" required in
pulling down random solutions from blogs. Hell, if the solution
doesn't work, it will be fun to fix it. And that is fine for the href="">beer review site I put together, but that is (arguably =) not a mission critical application. I'm not sure businesses can assume the same risk.

I'm not foolish enough to believe the JCP is flawless (e.g. Entity
Beans anyone?), but businesses can't always afford to bet the farm (or
their investor's farms) on solutions not backed by real consensus
organizations. I understand slow consensus processes run counter to
everything Ruby on Rails stands for, but perhaps the Ruby Community
Process can offer a more agile environment basing specifications on code and capability, not politics and vendor positioning. (which IMHO is the thorn in the side of the JCP)

just some more food for thought,


Related Topics >>


The comments for the older blog entry "JBI: Catch the second wave" are closed, and I see no other way to get in contact with you, so I'll reply here... I know the other blog entry is over a year ago, but it's sad to see the jBIzint site has closed, now that JBI2.0 is around the corner (I surely hope it is:). Has it been incorporated into the OpenESB-wiki? And what about the promising concepts you outlined here (install-packages sound like an excellent idea), are/were they discussed for JBI2.0? Unfort. there's no public information available about JBI 2.0 besides some blog posts and a presentation here and there - what about an update to the JSR-spec page with a public review...? If you have any information, please get in touch with me (gregor dot rosenauer -squirrel- gmail anotherdot com), I'm finishing my thesis involving JBI and any additional info for the outlook would be welcome.

good food

thiagosc: Ignorance is bliss, I suppose. And, I'm sure you're the super coder that documents everything you do. But, hey - who really cares? I think the post that Bone's referencing here - regarding "expectations" confirms that you're absolutely wrong. There's no unrealistic expectations with Ruby - unless you are just plain ole ignorant. I could keep going - but, again who really cares? At about the same time you were posting this Bone, I responded to a user-group mailing list: "Yeh, I saw that yesterday. Made me think a bit. The best counter to that post is that the statement needs to get finished. Not ready for what? I mean I could come out and say that Ruby is not ready for realtime autopilot control. But, I could say that for every language except C...which would be stupid. The other problem with essays like this, that are well thought out and documented often miss the real benefits of the "part" they are discussing. Unfortunately, it kind of happens here. There's no doubt that all of the issues with Ruby do exist, and I believe - even though he states they are fixable - the community is so weak that it isn't likely. I really do like Ruby however. And having spent some time writing Python on a previous project I'll take Ruby anyday. I hated about debugging nightmares. Who in their right mind would build a language based on whitespace? Anyway... Not that Python has one either, but Ruby is suffering from a lack of organizational leadership. Matz, the original developer, is no Linus Torvalds. Indeed it is quite the contrary as his stand is that it is still his personal language and that he is just happy other people are using it. If Ruby had the structure that the Linux kernel does we'd not be having this discussion right now. The work in the VM space is where all the real technical stuff is happening for Ruby. I do believe with Sun's help via JRuby that the language side will evolve eventually, with many of the points made in the Glyphobet post covered. The reality right now is that people are still just "hacking" with Ruby."

Ruby and forefront in the same sentence? That can't be correct because there's absolutely nothing that makes it to be in the forefront of anything, perhaps just the hype category, the one that produces unrealistic expectations. Linux and Java backlashes are evidence of what happens when people realize that the "solve all your problems" product they were sold is not a panacea.

Documention as code is the standard lazy developer excuse for not documenting their projects and it is quite funny to hear it from a language that looks like a Perl bastard child.

Ruby? *burp*..whats that?
Sorry, I just saw "" and hastened there to add Bavarian hefeweisen to the list. If you haven't had wheat beer brewed and served fresh in Bavaria, you are missing one of life's truest pleasures..