As if ColdFusion wasn't under enough pressure from Java and C#, Ruby (with its accompanying framework, Rails) has garnered enormous buzz within the IT community and support from highly-respected developers. On the surface of it, this is bad news for ColdFusion: more competition. But surface impressions are often wrong and never more so than in the case of Ruby.

Ruby is altering the nature of the debate about custom corporate software -- the kind of software most of us make a living writing. A year ago, the debate centered over J2EE v. .NET: the Battle of the Titans for predominance in the IT space. It's worth noting that both Java and C#, Java's flagship for .NET, are strongly (i.e. statically) typed languages. Indeed, it was argued, only strongly typed languages have the needed rigor to deal with the complexities of IT applications. And then, along came Ruby.

Ruby is dynamically typed and Ruby developers, far from apologizing for the language's lack of support for static typing, revel in it. "What is a type?", they ask. "Why should a type be tied to an inheritance hierarchy -- even if that inheritance is one of specification rather than implementation, as in the case of interfaces?" It's a very good question -- all the more since it was assumed that typing forms the basis for polymorphism in OO languages. But with Ruby's dramatic entry onto the IT scene, we can see that we mistook polymorphism (the ability for different objects to act on the same message in different ways) for type promotion.

Ruby apologists promote "duck typing" as a purer form of polymorphism. "If it walks like a duck, looks like a duck, and quacks like a duck, it's a duck!"  With duck typing, the test for types doesn't require that different objects descend from the same class (or interface) hierarchy, but simply that objects can respond to the same messages. Without the restrictions of static typing, Ruby developers allow classes to borrow methods from other classes (and even individual objects to borrow from other objects) in a mechanism known as "mixins". Dynamic typing promotes object composition over class inheritance.

Ruby has also transformed the debate from one over languages to one about best practices in software engineering. Ruby (and Rails) assume developers will adopt best practices and has built-in support for things like Model-View-Controller architecture and test-driven development. In fact, Ruby takes much of the best from a number of languages including Smalltalk, LISP, Perl, Python. Need to handle regular expressions? No need to download a library or toolkit for this -- Ruby has it built in. The same is true for XML parsing, HTML and FTP, CGI support, database interaction, GTK and Qt bindings and even a pure Ruby BTree library. Paul Graham has persuasively argued that truly impactful languages are not those written for to keep mediocre developers from doing any great harm (think "Ada"), but those that empower the best in the programming community. Ruby certainly fulfills this directive.

"That's great for Ruby," you might say, "but what about ColdFusion?" ColdFusion has long had dynamic typing, rich built-in libraries, and mixin ability. It shares a good deal of what might be termed the "Ruby philosophy". But IT managers have found it safer to insist on Java or .NET. It's not that either of these languages makes developers more productive, but that they are both safe choices. The old dictum, "Nobody ever got fired for buying IBM" had given way to an updated version: "Nobody ever got fired for choosing J2EE or .NET".

Managers are often a very risk-adverse lot. I have spoken with many managers who "knew" that Java and .NET were far superior to humble ColdFusion, although they had nothing but talking points from Sun or Microsoft to support their decisions. With Ruby's success in the IT world, managers may find the safety to re-examine their assumptions. It's up to us to help them see that ColdFusion can play a significant role in re-invigorating web development as we haltingly make our way to the Web 2.0.