We have covered a lot of ground in this chapter. I hope you can see the comparison to Mary Poppins. After speaking at dozens of Ruby conferences, I have heard scores of people profess their love for Ruby because it is fun. To an industry that grew up embracing the C family of languages including C++, C#, Java, and others, Ruby is a breath of fresh air.
Ruby’s pure object orientation allows you to treat objects in a uniform and consistent way. The duck typing allows truer polymorphic designs based on what an object can support rather than that object’s inheritance hierarchy. And Ruby’s modules and open classes let a programmer attach behavior to syntax that goes beyond the typical method or instance variable definitions in a class.
Ruby is ideal as a scripting language, or as a web development language if the scaling requirements are reasonable. The language is intensely productive. Some of the features that enable that productivity make Ruby hard to compile and make the performance suffer.
Ruby is a fantastic scripting language. Writing glue code to munge two applications together, writing a spider to scrape web pages for a stock quote or book price, or running local build environments or automated tests are excellent uses for Ruby.
As a language with a presence on most major operating systems, Ruby is a good choice for scripting environments. The language has a wide variety of libraries included with the base, as well as thousands of gems, or prepackaged plug-ins, that can be used for loading CSV files, processing XML, or working with low-level Internet APIs.
Rails is already one of the most successful web development frameworks of all time. The design is based on well-understood model-view-controller paradigms. The many naming conventions for database and application elements allow a typical application to be built with few lines of configuration at all. And the framework has plug-ins that handle some difficult production issues:
The structure of Rails applications is always consistent and well understood.
Migrations handle changes in the database schema.
Several well-documented conventions reduce the total amount of configuration code.
Many different plug-ins are available.
I would consider the productivity of Ruby and Rails to be an important component in its success. In the mid-2000s, you could not throw a rock in San Francisco without hitting someone who worked at a start-up powered by Rails. Even today, Ruby is prolific in these kinds of companies, including mine. The combination of the beautiful syntax and the community of programmers, tools, and plug-ins is extremely powerful. You can find Ruby gems to find the ZIP code of a surfer and another to calculate all address codes in a fifty-mile radius. You can process images and credit cards, work with web services, and communicate across many programming languages.
Many large, commercial websites use Ruby and Ruby on Rails. The original Twitter implementation was in Ruby, and the extraordinary productivity of the language allowed the website to grow to huge proportions. Eventually, the core of Twitter was rewritten in Scala. There are two lessons here. First, Ruby is a great language for getting a viable product to market quickly. Second, the scalability of Ruby is limited in some ways.
In formal big enterprises with distributed transactions, fail-safe messaging, and internationalization, the role of Ruby is often seen as a little more limited, but Ruby can do all of these things. Sometimes, concerns about the right application frameworks and scalability are well-founded, but too many people focus on enough scalability to build the next eBay when they can’t deliver any software on time. Often, Ruby would be more than adequate considering the time-to-market pressures many enterprises face.
No language is perfect for all applications. Ruby has its share of limitations too. Let’s walk through some of the major ones.
Ruby’s primary weakness is performance. Sure, Ruby is getting faster. Version 1.9 is up to ten times faster for some use cases. A new Ruby virtual machine written by Evan Phoenix called Rubinius has the potential to compile Ruby using a just-in-time compiler. This approach looks at an interpreter’s usage patterns for a block of code to anticipate which code is likely to be needed again. This approach works well for Ruby, a language where syntax clues are usually not enough to allow compilation. Remember, the definition of a class can change at any time.
Still, Matz is very clear. He works to optimize the programmer’s experience, not the performance of the language. Many of the language’s features such as open classes, duck typing, and method_missing defeat the very tools that enable compilation and the associated performance gains.
Object-oriented programming has a critical limitation. The whole premise of the model depends on wrapping behavior around state, and usually the state can be changed. This programming strategy leads to serious problems with concurrency. At best, significant resource contentions are built into the language. At worst, object-oriented systems are next to impossible to debug and cannot be reliably tested for concurrent environments. As of this writing, the Rails team is only now starting to address the problem of managing concurrency effectively.
I’m a firm believer in duck typing. With this typing strategy, you can generally have cleaner abstractions with concise, readable code. But duck typing comes at a price, too. Static typing allows a whole range of tools that make it easier to do syntax trees and thus provide integrated development environments. IDEs for Ruby are more difficult to build, and so far, most Ruby developers do not use them. Many times, I’ve lamented the loss of an IDE-style debugger. I know I’m not alone.
So, Ruby’s core strengths are its syntax and flexibility. The core weaknesses are around performance, though the performance is reasonable for many purposes. All in all, Ruby is an excellent language for object-oriented development. For the right applications, Ruby can excel. As with any tool, use it to solve the right set of problems, and you’re not likely to be disappointed. And keep your eyes open for a little magic along the way.
| [1] |
Mary Poppins. DVD. Directed by Robert Stevenson. 1964; Los Angeles, CA: Walt Disney Video, 2004. |
| [2] |
Syntactic sugar describes a language feature that makes code easier to read and write, though there are alternative ways to express the same code. |
| [3] |
I’m lying to you a little, but only a little. Two examples from here, you’ll see me change an existing class at run time. Theoretically, a user can change a class beyond all recognition and defeat type safety, so in the strictest sense, Ruby is not strongly typed. But for the most part, Ruby behaves like a strongly typed language most of the time. |
| [4] |
DSLs let you tailor a language for a specific domain. For perhaps the best-known example in Ruby, the ActiveRecord persistence framework uses domain-specific languages to map a class to a database table. |