Thoughts after attending The Day Of Ruby

On May 16, 2009, I attended the Tampa Day of Ruby. I’m always interested in learning something new and with so many people talking about elegance of the language I was extremely excited to spend a full eight hours focused on getting a crash course in Ruby. I was not disappointed. After attending the overview, here’s my summary:

Invest some time to practice, learn Ruby and Rails (and/or other elegant technologies) to become a better programmer. Use more traditional, main stream technologies to ship high quality production code using what you learned from your studies of the elegant boutique languages.

Let me explain; but first a little background. My “Ruby-esque” language experience was a language called FORTH. It has many of the same characteristics of Ruby, with main feature that it shared being the ability to extend the language using the language. We had a shop of about 10 people. The distribution of talent was probably fairly typical: 3 – Shouldn’t be programmers, 5 – Average Developers and 2 rock-stars. Ruby like FORTH is what I would consider an “Amplifier”, where most C or traditional languages would probably be more of an “Equalizer”. With FORTH, and I suspect Ruby, it would allow the talented people to do an extremely good job building systems. In the hands of people that shouldn’t be programming, well, let’s just say, they can make a real mess that could never be salvaged. With average developers, they don’t really use any of the real power of the language and don’t see any of it’s benefits. That is to say that poor developers develop systems that are 100x worse than the average and great developers can develop systems that are 100x better than the average developer. If we contrast that with “equalizer” languages like the C-family, the poor developers may be do 5-10x worse job and the great developers can do 5-10x better.

Leveraging the power of languages like Ruby and FORTH, require some level of natural talent plus the desire to invest time and practice.

So that brings me to my point, invest time to learn Ruby (or something similar); and I’m very serious about that; however in your day-job for creating production code use more traditional technologies. Most production LOB (Line of Business) type applications can benefit less by using an elegant technology like Ruby as they can by putting in a predictable and repeatable process to deploy that technology. To leverage a technology like Ruby, you need top-tier developers to take advantage of it’s benefits. If you don’t have top-tier developers, you’ll probably end up developing using Java or C/C++/C# techniques in Ruby. This results in adding just one more layer of complexity into the already incredibly difficult process of developing software.

I know a lot of companies use boutique languages for internal or support systems. I personally have mixed feelings on this, I think it’s probably a good way to practice if it’s done in the right environment however there are two risks I see in doing this. First being that most of these are research efforts, and generally the output of research isn’t as good as if you engineer your tool. This results in support systems which are critical for your developers to do there jobs that may be somewhat fragile. If there is one thing I hate as a developer more than anything else is to work a long day, get my problem solved, really want to be done for the day and end up fighting with the support infrastructure for another two hours to get my solution deployed. In addition to that, if you develop your support mechanism in FooBat ZX V2.3, what happens when you leave the company (or want to take a vacation) and that support tools needs maintenance. You may have some one that knows FooBat ZX V2.3, but if this was done as your first application using the technology, I suspect it may not be all that clean. As I mentioned earlier, I think in the right shop, using a boutique language for internal and supporting systems could make sense, but deciding to do so should not be made on a whim or a cool write up you read in a blog post.

So in summary, I learned a lot yesterday at the Day of Ruby, it brought back great memories of some of the software engineering discussions we had while implementing systems in FORTH. However as I still think FORTH is probably the most elegant language, other than screwing around on my own, I just don’t ever see recommending using this for any production work I do for my clients. I think the same will be true for Ruby.

Finally I have to commend Cory Foy and his initiative to put this together. It was obvious he is a very talented presenter and spent considerable time putting together the materials and thinking through the topics.

-ec