Will the Enterprise change Ruby, or will Ruby change the Enterprise?

This article is an expanded version of a post that originally appeared on the Ruby-talk forum.

Ruby has been very successful in some important niches, but to date enterprise IT has not been among them. Ruby is often criticized for lacking the features required for developing large applications, and maintaining them over long periods of time with large teams. But are we missing something more fundamental?

I came to Ruby three years ago from many years of C++, C and assembler, including large commercial-systems development. As far as Java is concerned, it's obviously been validated by the marketplace and experience proves its value for critical systems. But I've never been entirely convinced by Java.

Java incrementally improves on C/C++ in many ways. But fundamentally, it has a tendency to encourage sloppy thinking among less-experienced programmers, because the language takes care of so many things for you. Now of course that can be taken two different ways. You have to be a lot more careful with a straight razor than with an electric shaver, but having deep experience with dangerous and powerful shaving systems isn't necessarily all that valuable from a business point of view. In other words, the electric shaver represents progress precisely because it lets you be somewhat sloppy, without getting a bloody mess.

Now with Ruby the perception is that we're going back to the straight razor. Many have argued that additional tools and mechanisms must be added to Ruby in order to control certain language features, like dynamic typing, open classes, and the way Ruby handles namespaces. I spent much of the last three years writing Ruby programs that looked a lot like incrementally-improved C++ programs.It took me a long time to grok duck-typing, but when the penny finally dropped it really changed everything. People coming to Ruby without the baggage of many years of commercial C/C++/Java experience don't seem to have this problem, nor do they have the mental blocks against meta-programming that people like me have. (I learned to avoid self-modifying code way back in the assembler days.)

My point is that if we try to make Ruby fit into established large-team methodologies, we may be throwing away what makes Ruby special in the first place. And we'll end up with nothing more than an incrementally-better Java. And in a corporate environment, there are always more reasons to avoid change rather than to embrace it. Which means that if we accept this model, Ruby will simply not succeed in the enterprise.

What I believe is happening, but has yet to fully emerge into visibility, is that Ruby is successfully extending the same kind of partitioned development model that has worked so well in the open-source world generally. If you accept that Ruby may be revolutionary rather than evolutionary, then ask yourself why that may be so. To me the value of metaprogramming, duck-typing and open classes is that they permit a tremendously powerful way to re-imagine the mapping of elements from real-world problem domains to elements of computer programs. They help us model the world better. And yes, that can mean changing the behavior of already-established and stable objects. But to many, that is exactly the problem!

What are "large systems," really, and why is Java perhaps the better tool for them? Well, one answer is to think of a large system as a sizable collection of fine-grained, domain-specific elements. Problems arise both because of the size of the set (and the number of interactions) and the fact that they are domain-specific, which means they only matter to a small number of organizations, perhaps no more than one. So in turn, they don't benefit from the evaluation and improvements of a broad community. Well, if you think of a large system that way, you are really facing an essentially insurmountable design challenge. There are too many moving parts. So people respond with ideas like Design by Contract, which seek to automate and "freeze" the interactions among various system components. Well, the rigor which with this is done may actually be part of the reason that large systems get large in the first place! You end up adding more components because you have no ability to modify the existing ones in a context that won't arbitrarily break their existing contracts. There may in fact be a tipping point at which system size starts to conflict directly with constructability. But we know from real-world experience that this is not true in other engineering disciplines, so the question becomes: is there a different way to do this? And Ruby may be part of the answer.

If I sound like an advocate for enterprise SOAs, well I am. But I have a long background in large distributed systems, and what I see with SOA today is first-generation thinking, focused primarily on transport protocols and language support (which today practically means support for Java). What we should be doing is discovering more organic ways for large ordered systems to spontaneously emerge from existing and newly-designed parts. And the way we think about traditional large-systems development may indeed be the stumbling block.

I've been thinking a lot about building a distributed object framework in Ruby, that would provide a range of system services to plain old Ruby objects and objects written in other languages. It's often assumed that duck typing and metaprogramming work against this goal in a fundamental way, and that large systems simply are impossible without textually-expressible contracts among components that can be enforced by compilers. But if you're an old hand like me, just remember how astonishing it is that duck typing works so well, given how contradictory it is to received wisdom! Ruby may have another surprise in store- it may turn out that Ruby's special characteristics make it particularly suitable for the development of large distributed applications.

I know I've raised more questions than answers here. I don't have the answers (yet) and there is a long way to go, but I don't think Ruby should be "improved" to fit traditional large-system methodology. I think the reverse (somehow) is closer to true.

About the Author

Francis Cianfrocca is a principal with Bayshore Networks, LLC in New York, specializing in access-control systems for enterprise applications. He is a co-author of the following Ruby projects: Net::LDAP, EventMachine, Monorail, and Catamount.