This post originated from an RSS feed registered with Java Buzz
by Weiqi Gao.
Original Post: The Re-education Of A Ruby Brush-er-Off-er
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
I made it no secret that I did not buy all the Ruby hype, not when Curt Hibbs worked at OCI, not after attending Dave Thomas's and Bruce Tate's Ruby talks at NSJF, not when most of the Java developers around me started to go the the St. Louis Ruby User's Group meetings, and certainly not in front of my OCI colleagues, including our CEO.
CEO: How do you think of Ruby?
Me: I don't like it. Their (10x) productivity claim is ridiculous. They are trying to eat Java's lunch.
CEO: Mark will be doing an internal Ruby training event. Maybe you should attend and see it up close from your perspective.
So I signed up for the 18 hour (six evenings) training course on Ruby Programming. To be honest, my original intention was to go to the training event, raise a lot of noisy questions, and in general rip Ruby apart the best I can. Now that we are two thirds into the event, I can't say that's what I did. Maybe I'm too nice. Maybe I'm too chicken. Maybe the Ruby people does have a point.
What did I learn from taking the Ruby course? A few things. Let me enumerate.
The syntax
I still am not comfortable with the Ruby syntax. I understand them in class, but soon forget them afterwards. The language seems to be constructed to suit one persons taste. To me, C, C++, Java, bash, awk, Lisp, Basic, etc., have remember-able syntaxes, but Perl, Ruby, XQuery, XML Schemas, etc., have forgettable syntaxes.
Blocks
Everyone raves about blocks in Ruby. Some even put it up as the one differentiating feature of the language. After learning the syntax and coded a few examples, I can definitively say that blocks is no such thing. Yes you can capture the environment of the block. But you'd be crazy to design your library to mess around with the environment of a passed in block. So for normal use, blocks act much more like function objects in C++:
# Ruby
[1, 2, 3].each { |i| puts i }
// C++
std::for_each(vector.begin(), vector.end(), print_elem);
Meta-object model
We did not go into details on this one. However we touched upon the attr_accessor method on the Module class. With its help, the one line of Ruby code:
attr_accessor :foo, :bar
in a class's definition generates two instance variables @foo and @bar, plus getter and setter methods foo, foo=, bar, bar=.
(Notice how cute Ruby's setter syntax is. This line of code:
myObject.foo = 10
is actually a method call to the setter foo=. Another thing you have to think about when coding.)
This can be simulated in C++ with macros, but Java is powerless in this regard. If I have to pick one Ruby feature to explain all the hype, the meta-object model and the meta-programming that is enabled by it would be my choice.
With great power comes great confusion. Meta-programming is not an easy thing to learn and use. If indeed meta-programming is what makes Ruby so attractive, then there will be two kinds of Ruby programmers—the kind who does meta-programming, and the kind who doesn't. For the ones who doesn't meta-program, Ruby will be just like any other scripting language.
Dynamic typing, duck typing, open classes
Ruby's dynamic typing system is just like that of other scripting languages. There is nothing special here.
Ruby's duck typing feature is very similar to C++ templates. It can invoke a method on an object as long as a method with the same name and number of parameters is available.
Classes are open for modification. If I want to change the string class, I can. And my changes will be felt by all other classes in the same process. This is another dangerous sounding feature. However it has not caused any big problems in practice. It's just another thing that the programmer has to be careful about.
Rdoc, Gems, ruby-mode.el
Rdoc is like Javadoc.
Ruby Gems is a program that can automatically download Ruby packages from Internet code repositories and make it available on the local system. Just like Perl's CPAN. This is one feature that I like a lot about Ruby. Of course I've been advocating for years a system like this for Java, but nobody listened. JPackage.org and Maven comes close to the ideal, but one is tied to Unix, the other a build system.
Ruby doesn't have good IDEs that support refactoring. But at least there is ruby-mode.el so that I can indent my Ruby code properly. It can also auto insert the end markers that's so prevalent in Ruby (which is annoying.)
So how does Ruby stack up?
From a technical point of view, I saw very little that sets Ruby apart from the other scripting languages. It is practically another Perl. I also think Python could match Ruby feature for feature, including lambda support (blocks in Ruby) and meta-object model.
I will refrain from comparing Ruby with Java because they are in two different leagues. Java is a statically types language while Ruby is dynamically types. They serve different users, communities and purposes.
I have yet to hear a Ruby success story from a non-Ruby-enthusiast. I don't believe Ruby will succeed as a popular programming language. I do believe, however, that Ruby will be a potent tool for the meta-programming elite few. It will be the basis of their spectacular successes that nobody can duplicate. Kind of like that one guy who built a e-store system in Common Lisp and sold the company to Yahoo.
Google will buy a Ruby based product company this year for $40,000,000.
And it's not going to be me.
What about all the hype?
By hype we usually mean the loud reporting of something new in the technical press and blogs. For technical press, I have a very good explanation—that's their job. They are supposed to hype. They usually focus their hype for no more than three years, time enough for a nine month small project followed by a two year major project to succeed. Usually by the third year, a good technology will be standing on its own, and a bad technology will die off. Think applets which died, and servlets which lived.
However to take advantage of the media's hype, a technologies internal structure must be such that it can work with the media's hype cycle. It must continuously feed the media good material, either analysis or case studies. Think Free Software, which the media can't hype if they wanted too, and Open Source, which modified Free Software's stance so that the media can hype them.
Ruby was "discovered" by the pragmatic programmers when they went searching for a language to use in their pragmatic projects. And what did they do? They wrote a book. A bad one first, followed by a better one. What else did they do? They went on the conference circus telling the Ruby story to endless developers again and again. And that inspired people who experimented with it and liked it. What did they do? They made a fifteen-minute video of their web MVC framework product. The rest, as they say, is history.
Could someone else, just like the pragmatic programmers, have discovered something else like Python and did all the conference promotions? Of course it's possible. But nobody did. Could someone else promoted a Python based web MVC framework the way Ruby on Rails people did? Of course. The TurboGears people did just that. But clearly the socond comer does not have the same impact as the first comer.
What about Java?
As for Java, all I can say is that there is nothing in Ruby that directly competes with Java. The fact that Ruby people like to knock on Java is simply because Java is a fairly popular language. As DHH said once in an interview, he likes to poke at Java because he likes to see the reaction from the Java camp. He also said that he does not wish Ruby on Rails to go "enterprise."
However, Java can indeed learn something from Ruby. Here's my list of things that would make Java better:
Make Java open source, and quickly. Java 5 needs to be open sourced by the end of 2006. I have been saying this for years now. (And I promised to not talk about it anymore.)
All open source Java libraries needs to be made available, with dependency management, yum or apt-get style, from one single place (plus their mirrors.) No messy download and installation instructions.
Get things done more quickly. The slow pace of the JSR process is not fast enough for the technical press's hype cycle. It was not fast enough for the normal Java developers. Think the Groovy JSR.
The variously names jar file formats (war, ear, sar, bar, car, dar, far, gar, etc.) as well as the classfile format need to evolve into a single format. They are too confusing.
Improve the experiences of first time Java users. Let's not force them to define the JAVA_HOME environment variable. Let's not force them to learn about CLASSPATH and ClassLoaders.
Previous Topic
