Tuesday, March 21, 2006

Thoughts on James McGovern

Everyone else has posted their opinions on James McGovern's Thoughts on Ruby and the Enterprise. I figured, "what the hell? Why not post mine too". James McGovern lists some problems for the Ruby community to address, but stumbles from the mistakes. So, I'll start out with a nice quote:
Many folks haven't figured out that I too am a fan of Ruby.

OK, I can buy this, but when it comes to the list, he makes these mistakes:
Does anyone agree that the notion of packages / namespaces should be a part of every modern language?

Ruby has these things called Modules that fullfill that role.
I also couldn't find the equivalent of instance variables. Wouldn't that make reuse at an enterprise-level somewhat problematic?

Uh, Read the chapter "Classes, Objects, and Variables" in the pickaxe book. If you were a fan, you'd know this. Right?
Shouldn't the notion of methods being public, private and protected also be a part of every modern language?

Same chapter as the first one.
Does anyone in the community acknowledge that software vendors and even many large enterprises don't build on top of scripting languages because they don't want their intellectual property so discoverable?

Um, if you write your code on the server, why does that matter? Ruby shines on the server-side. Do we need to protect ourselves from ourselves? Wasn't that a problem with the Y2K problem? Didn't they have issues finding the original code and developers had to search through assembly language. Sounds fun to me...
But, my favorite is...
Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions.

It's built in. But, you know Java didn't have Regular Expressions until 1.4 if memory serves me correctly. I remember Java was useful without it, but boy it does make somethings easier. But, if you heavily depend on regular expressions in your code, I hope never have to maintain it.
And this one took me over the deep edge:
Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development.

This one got my blood boiling. I love design; I think about design; and I live for design. I get angry when people do not think before they code. I know some in the agile community think you should sit at the terminal all of the time. But, I think it's important to know how the components of your application are going to fit together before you start. You might not have all of the details, but you should know what the interfaces and what their purpose are.

Thought does not mean "Big Upfront Design". Coding right away is gross negligence. CRC cards are still an excellent tool. Hell, simple message send and class diagrams still help my thought process.

To lump all of us together and call us hacks is disturbing. Ruby takes a lot from Smalltalk . Just remember all of the GoF Patterns come from examples in every Smalltalk-80 image. Don't damn all of us for the few who don't think. Besides, I've seen my fair share of poor designs in all languages including Java. Good design goes beyond language. Period. End of story. Languages are simply amplifiers that aid in the implementation of design.

Most of the critism has been overly harsh and I think his intention was to advise. But, when you get so much wrong, it's hard to take it seriously. Ruby has a lot of senergy behind it and the thing that has shocked me is the fanaticism. We need to take some advice from "The Pragmatic Programmer's" book and show everyone how cool are toolset is and not attack them. But, by the same token, we should correct those that are mistaken. It's a thin line.

No comments:

Amazon