BT

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

Posted by Francis Cianfrocca on Jul 11, 2006 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Enterprise Ruby by paul browne

Good post , especially given that with the latest release of JRuby, Ruby on rails effectively can run in an existing JVM (an easier path into to enterprise than 'install this new bit of software').

To expand an underlying theme of this post. 6 or 7 years back , Java was the domain of alpha-geeks - the early adopters that 'did things right'. Later , Java went mainstream with people 'who just got things done' - not a bad thing , but not pretty code. Ruby is probably going to follow the same path.

Paul , Technology in Plain English

Versioning, SOA, and duck typing by Evan Leonard

Service versioning is certainly a problem that requires attention. The mix of duck typing and meta-programming within ruby does make it a candidate to solvoe this problem. However, I know others in the strong-typing camp that have plans to make ML rise to the top to solve difficult problems than these. Although ML has a way to go to gain the wide exposure that Ruby has earned in the last few years.

I would like to see competing solutions posed by both of these camps. The results would benefit all!

Re: Versioning, SOA, and duck typing by Sam Wilson

I like ML, but it'll never be a mainstream enterprise language.

It's just too much of a stretch from how must people learn programming (functionally). Widespread adoption of ML would require changes to the basic CS curriculum and years of work before there are sufficient numbers of quality developers to make it a viable solution for any large business.

interesting pov by Alex Popescu

Very interesting point of view. I have, though, some comments.

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.


I haven't been reading (or hearing) this argument for quite a while (many years ago, it was one of the most used arguments when people were discussing about C/C++ and Java). After all these years of Java, I would tend to completely disagree with it. If somebody is gonna write bad/sloppy code, he will do it in any PL. Moreover, I guess we should move to PL/development that allows us to work on the important aspects of the systems we are building and not manage repetitive and small details each and every day. IMO, this all comes down to productivity.

[...]but I don't think Ruby should be "improved" to fit traditional large-system methodology. I think the reverse (somehow) is closer to true.


I agree with you, and I am not sure there are so many people suggesting changes to the language itself. What I have noticed being around Ruby for almost 2 years is the need for specialized tools that are perceived as absolutely necessary when talking about adopting a new direction (f.e. decent debuggers, etc.). Other than this, Ruby is a nice thing happening to developer's world.

./alex
--
.w( the_mindstorm )p.

RE: Will the Enterprise change Ruby, or will Ruby change the Enterprise? by Lasantha Kularatne

This is a good analysis of Ruby. I think Ruby should evolve more. The reason why Java captured the market so heavily was because of its powerful collection of libraries come with JDK. And when it comes to the large enterprise developments, its ability to handle multithreaded aplications and concurrency made Java to grab that share of the market. So I wonder how Ruby can atack these areas.

Lasantha Kularatne
University of Texas at Austin

OO/Java stagnation by Bill Culp

Off the SOA track a bit. The disappointment with Java can be summed up in that OO patterns even when combined in frameworks have not proved sufficiently effective in easing the pain associated with building large systems.

Whats the difference between doing byte code manip and simply using libraries? (The POJO approach) Both avoid all OO techniques of inheritance and encapsulation and polymorphism. The core of OO has not proved especially valuable in years of Java development aside from the idea that a domain model is a good thing.

"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."

Thats library speak right there. So we are taking a step back.
And thats OK as long as we all ackowledge that the happy OO path we were on has reached a dead end at least in Java even with AOP on top.

Ill conceived? Maybe...Java permits polymorphism using multiple interfaces but I cant implement Map and List in the same class.

Theoretical notions aside how well thought out is that notion?
Not very. Maybe SUN underestimated the importance of hybrid collection types or maybe static typing is not the way to go.

But given that SUN cant even plan an interface correctly that is going to be in use for many many years by thousands of programmers maybe design by contract is a bit stuffy.

Re: OO/Java stagnation by Jonathan Allen

Ill conceived? Maybe...Java permits polymorphism using multiple interfaces but I cant implement Map and List in the same class.


I find it hard to believe those boneheads still haven't fixed that. That bug was reported back in 1998.

Can't implement Map and List in the same class because of remove(Object) method

Instead of acknowledging the underlying problem with their interface implementation syntax was broken, they just blew-off the bug that uncovered it. What about all the other cases where a class needs to implement two interfaces that may have overlapping methods?

I still believe in OOP and static typing as techniques. What I don't agree with is Java's narrow-minded obession with pure OO code (as they define it) or their insistance that you only do things their way.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT