Ruby, and in particular, Ruby on Rails has caught the development world by storm. So much so that Sun Microsystems, through the encouragement and assistance of Tim Bray (amongst others), broke away from their traditional "Java is all you need" campaign, hiring Charles Nutter and Thomas Enebo, the developers of the JRuby project, encouraging them to continue forward with their quest to bring the Ruby language to the Java platform.

Of course, never ones to miss a "me too" opportunity ;-), Microsoft followed suit by hiring John Lam, the developer of RubyCLR, a .NET <-> Ruby compatibility bridge. As he describes,

I’ve decided to stage a friendly takeover of Microsoft. As of January, 2007 my new work address will be Building 42 at Microsoft. I’ll be working in the CLR team to help bring the love of dynamic languages out to the statically typed heathens :)

That said, Ruby is not the only dynamic language to catch the corner of the Redmond-based Giant's eye, who had several years prior hired Jim Hugunin the developer of both JPython (Python runtime for the Java platform) as well as IronPython (Python runtime for the .NET platform.)  In addition, he was the primary developer and architect of AspectJ, something in which my good friend and partner in hacking (the good, *legal* kind) crimes, Russ Miles both (quite literally ;) wrote the book on, to then find inspiration in other areas of Aspect-Oriented Programming, something that would ultimately lead to us teaming up to develop AspectXML (Russ developing the Java integration engine, myself, the XSLT weaving engine) which now sits as the foundation of the AtomicXML project in which I wrote about recently.

Of course, while there are plenty of other languages and people driving things forward, in many ways, you might suggest that the creations of Jim Hugunin (and therefore, Jim himself) sit at the very foundation of the future Microsoft language and platform development. As was reported by eWeek in August,

Microsoft is working on a phased approach to enhancing its support for dynamic languages on the company's .Net platform.

Jim Hugunin, creator of the IronPython language and a development leader on Microsoft's CLR (Common Language Runtime) team, told eWEEK that Microsoft is working to help usher in support for dynamic languages on top of the CLR in a variety of levels or phases.

Jim goes on to describe a three-phased approach which includes the development of extended support for dynamic languages as part of the .NET platform, an instantiation of the best patterns and practices into a code base in which can then be extended from, as well as offering the "lessons learned" during the development of all of the above, in a format that I would assume be provided through channels such as Microsoft Consulting Services (though this is only a guess.)

With all of the above in mind, you might find yourself asking: "What on earth does all of the above have to do with 'letting go to embrace'?"

Mike Volodarsky, a Program Manager on Microsoft’s IIS team, in charge of the IIS7 web server engine, began a recent blog entry with,

10 steps to get Ruby on Rails running on Windows with IIS FastCGI

Since the original tech preview release of FastCGI last year, we've been seeing a lot of requests for getting Ruby on Rails running with our FastCGI.  Theoretically, since the FastCGI component uses a standard protocol to support FastCGI-enabled applications, this shouldnt be an issue - but, in practice, this is very far from reality.  After factoring in setup problems, configuration, and variations in runtime behavior / protocol deviations, every single FastCGI application we've looked at has required quite some effort to support properly. 

So, for FastCGI Tech Preview 2, I spent some time researching what it would take to enable Ruby on Rails, resulting in "experimental" RoR support in the TP2 release.  It is "experimental" because we did only limited testing, and given our lack of experience with Ruby its very hard to tell whether a real Ruby application will work as expected at this point.

I am confident that the experience can be improved significantly with community testing, and any necessary fixes to both the FastCGI component and Ruby.  I am looking forward to any feedback/bug reports that can help us get there - please feel free to leave comments on the blog, or post to IIS FastCGI forums.

Without further ado, these are the 10 steps get RoR working with FastCGI TP2:

With as much time, money, and effort being put into the development of dynamic language development and platform integration from some of the largest, most powerful software companies in the industry, one might be led to wonder why things such as support for Ruby/RoR don't already exist.

The Answer?

As Mike points out in the same quote from above, "and given our lack of experience with Ruby its very hard to tell whether a real Ruby application will work as expected at this point."  Or in other words: We're talking about two completely different worlds; approaches to software development that, while similar in purpose (i.e. develop software applications), are far from the same when it comes to the foundation in which they build and extend from.  Ruby and Python, as already pointed out, fall into the category of dynamically-typed languages, where as programming languages such as C# and Java, and therefore the .NET and Java platforms, are designed around what is termed a statically-typed language.

To better understand why this is significant, we would need to better understand what 'typing' is all about,

The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). Static type-checking becomes a primary task of the semantic analysis carried out by a compiler. If a language enforces type rules strongly (that is, generally allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.

To think of this another way, a statically-typed language understands the definitions of the data in which it processes well ahead of the time it will actually do any of the processing.  On the other hand, a dynamically-typed language doesn't have any real understanding ahead-of-time as to the definitions of the data it will be processing, learning-as-it-goes, so to speak. 

Because of this, the ability to adapt-on-the-fly to the ever changing world around us is something a dynamic language is very, very good at. 

Of course, on the flip-side, dynamic languages tend to be quite a bit less efficient than their statically-typed counterpart, who, because of predetermined understanding as to the data's definition, can rip through the processing of this data with extreme efficiency.

To think of this yet-one-more-way, two(2) times two(2), as we all know, is four(4).  But what about two(2) times too(as well)?  The difference is obvious to our educated eye in which understands ahead-of-time that while two(2) and too(as well) sound the same, (their meaning) is quite different.  The first, is a digit;  A number in which is based on a well defined and structured foundation of mathematics.  The second is a string; A sequence of characters from the Latin alphabet in which in the English language is defined as,

too      /tu/ Pronunciation Key - Show Spelled Pronunciation[too] Pronunciation Key - Show IPA Pronunciation –adverb

1.	in addition; also; furthermore; moreover: young, clever, and rich too.

2.	to an excessive extent or degree; beyond what is desirable, fitting, or right: too sick to travel.

3.	more, as specified, than should be: too near the fire.

4.	(used as an affirmative to contradict a negative statement): I am too!

5.	extremely; very: She wasn't too pleased with his behavior.

—Idiom

6.	only too. only (def. 10).

Of course, maybe "defined as" is not quite liberal enough to describe the above "definition."  To be more accurate, we would need to make a statement such as,

"In this context, 'too' is defined as ..." to then follow with one entry from the above list that provides a more clear understanding as to the meaning of the usage of 'too' as it pertains to the context in which it is contained.

What about '2'?

2
adjective
1.	being one more than one; "he received two messages" [syn: two]
noun
1.	the cardinal number that is the sum of one and one or a numeral representing this number [syn: two]

Ahhh...  Now that's *MUCH* more clear, as is hopefully the difference between a dynamically-typed language, and a statically-typed language, the former providing much more flexibility as to its meaning, the latter providing much greater efficiency in understanding and therefore processing this understanding. Are both important as they relate to the world of computer programming?  Absolutely!  But the foundation upon which each is built is *COMPLETELY* different, leading to difficulty in the implementation of a foundation in which both can build and extend from.

Of course, both Microsoft and Sun Microsystems are attempting to accomplish some amazing things (and doing a pretty good job of it, in my opinion) by integrating these two obviously different programming paradigms into a single platform in which can provide both the flexibility and efficiency that both approaches bring to the table.

But in the mean time, as made obvious by Mike Volodarsky's above linked post, sometimes embracing both means and requires letting go of one's ideals (not to be confused with morals) such that a greater goal can be accomplished: Adapting to the world around you, instead of attempting to force the world around you to adapt to you.

Oh, and yes: If not obvious, this is the third in a series of four entries, the first two of which I promised to showcase I wasn't anywhere near as crazy as you might have thought I was.  While there are those who will argue "Don't be fooled... He *IS* as crazy as you think he is!", I would argue that, in fact...

Errr.... Well, maybe I'll just keep my mouth shut and let you decide that for yourself. ;-)

Until next time, my friends...

Peace.