Interop tends to be something we like to avoid, and to only take on when it's absolutely necessary. For me lately, this is starting to seem like a kind of odd and arbitrary way of thinking.

Only a couple of years ago the common wisdom in the .NET world said that we should try to use the same .NET programming language within a single and project. It wasn't sensible to mix and match .NET languages on a project. C# and VB .NET didn't really offer compelling advantages over each other, and it would be a bit odd and arbitrary to mix and match at will in the same project.

In my project today, we have a mix of C#, Ruby, and Boo. Each language is used in parts of the app where it makes sense and where not using it would lead to a lessor solution. In the past I would have thought this pretty much unthinkable, where today I barely think anything of it. It's a best-tool-for-the-job perspective. Since Dave Thomas' call to the community to learn a new programming language each year, a good chunk of the fear that kept me rooted to one-and-only-one language has lost a good chunk of its persuasion.

Lately, I'm constantly bothered by thoughts of Ruby on Rails. Every now and then something comes up on our project that leads me to think, "If I were doing this in Rails I'd be done by now." It's such an obvious choice as a framework for building web apps. With Thoughtworks and Thoughtworks alumni bringing Rails and Ruby ever deeper into the enterprise, I'm perpetually nagged about whether building a web app on .NET is the right thing for our customers.

There are absolutely some parts of the app things I want to use .NET for, but the part that is just web pages, AJAX, business objects, and web-transactional data access with .NET feels more and more like swatting mosquitoes with hammers.

Monorail and frameworks like it try to address ASP .NET's excesses while allowing programs to remain in the .NET process space, memory space, and type system. I'm wondering now if keeping the part of the app the runs on the web in the same process space, memory space, and type system as say the MSMQ client or any other part of the architecture that is inherently message-based is necessary.

I find myself balking at a solution that chooses to do interop between Ruby and .NET. Platform interop is a bigger pain than language interop, and I don't really spend any time seriously considering the interop option. I'm less convinced that avoiding interop here is such a smart thing.

I want all the parts of my web app that should run in the same space to run inside the same space, but do I need it to be the same space as those parts of my app that are out-of-process? If the answer is "no", then I need to put real consideration into using Ruby on Rails for the web app if it's the best framework for the job that I need to do.

The issue with interop is that it hasn't been very easy, but the tools for interop are better and more common than they were even two years ago. Platform bridges seem to be more acceptable now, and language interop seems increasingly to be a foregone conclusion. We now have interop scenarios like JRuby that have literally dissolved what was once an out of process service boundary allowing apps and frameworks that were exiled from the Java virtual machine to run as first class citizens of the JVM and leverage the plethora of Java libraries available to the Java developer.

Microsoft's DLR will ultimately allow me to intentionally choose framework interop. I can design for it. I can ostensibly use Ruby on Rails on the CLR via the DLR, and make native use of the .NET libraries where appropriate from within the Ruby code. John Lam and Jim Hugunin are smashing process boundaries and providing interop opportunities that look less and less like interop and more like mere "Add Reference" scenarios, much in the way that JRuby has done.

Tools like the DLR should shake up our ideas about certain kinds of local interop and might cause us to begin to choose to do interop rather than to avoid it. When interop becomes easy, our perceived obstructions will fall into obsolescence. Our focus ceases to be firmly on managing complexity when some technological shift makes the underlying causes of the complexity to disappear.

I'm having a hard time figuring out why I would want to continue building the HTML forms over data part of my app with a set of tools that hasn't kept up with the ease that other frameworks bring, and I'm certainly not comfortable yet building enterprise infrastructure with a framework whose principal focus is forms over data. I could choose to bring them together in the same app with the judicious use of tooling that makes it easier to do, and design that not only makes it possible, but would be sensible for even a non-interop solution.

When we get in-process interop like the kind that comes from JRuby and the DLR, we not only have the ability to build web front-ends using enablers like Rails, but we also get to leverage advancements that the Ruby community has made in our .NET apps. I would much rather be doing test-driven development with RSpec than NUnit, no matter how much syntactic sugar I can wrap around the NUnit API with C# 3.

Here's the kicker: The more I think about application architectures built using Ruby on Rails for the web front end, and .NET for all the out-of-web-process enterprisey stuff, the more I'm forced to see a clearer separation of responsibilities for the various major services in my app. In fact, if I hadn't been thinking through these interop scenarios, I would have given less thought to a partitioning of the application that is starting to seem ever more appropriate and possibly even more empowering.