Today I came across a blog post by Charles Nutter that was linked to from a post in the IronRuby mailing list. This fellow has a very good blog and writes an interesting post about the current state of ruby implementations, inlcuding IronRuby, from his point of view. I think for the most part, he is spot on with all his conclusions. He makes the statement that Microsoft would never back an open source framework like rails in preference to its own. This seems to have caused a bit of a stir on the rails mailing list and folks are coming up with replies. Here’s mine.
Microsoft used to write IDEs for C++ before all this framework madness happened (I’m talking before MFC even). Folks stayed with Microsoft’s tools over others because they found them to be of higher quality and the productivity enhancements brought by the IDE saved them time and money. Today Microsoft holds industry control of the runtime and compilers itself for their .NET framework, and so for most folks on Windows, they are the only ones that offer a development IDE for it. Sure there is eclipse support for C#, SharpDevelop, and Microsoft has always touted that anyone with a text editor and command-line can build apps but due to the design and breadth of the class libraries this really isn’t feasible. You don’t see most folks using non-intellisense aware Java IDEs these days when Eclipse is around. Now I don’t really believe that Microsoft planned for Notepad to be a real development environment for .NET, I think this statement was more about proving the opportunity for other tools in the market to target .NET.
Rails is not just another bytecode based, intellisense requiring, class-library-laden layer over your operating system like .NET or Java are. Sure ruby could be argued as such but the knowledge of a small subset of Ruby plus the simple and elegant design of the libraries in rails make up a smaller set of APIs that let someone be very productive in their target space (web applications and services) without an IDE, as Microsoft had originally touted for .NET. While Microsoft has been working on creating tools for generating DSL’s with .NET (domain specific languages, where you only need a subset of APIs to deal with a industry or problem domain when coding against it with .NET) Rails has actually delivered this albeit with the entire runtime platform, and targeting web applications as the “domain”.
If you look at Microsoft’s revenue, they are making far more money nowadays on Sharepoint, Exchange, and Windows Servers than on any of their development tools (Team Foundation Server makes them some cash too, but adoption seems relatively low). Many of the features in these products were built on .NET. Should IronRuby produce a high performing, CLR interoperable VM as is its goal, Microsoft encounters its usual dilemma. How do we support previous technology (.NET) and move forward at the same time with a completely different MVC paradigm such as rails enables. Unless you work for Microsoft, and even if you do, some of these strategic conclusions are hard to determine. A possible obvious solution would be that Microsoft will employ IronRuby as a language to use with their ASP.NET MVC framework. They will also use IronRuby, as they have in many demos, to serve Silverlight pages from the server (ala the Dynamic Silverlight effort, again). The problem I see with both of these is that most developers do not make great decisions about which APIs to leverage and not to leverage in .NET when building applications. There needs to be tighter control than just enabling the entire .NET platform’s libraries accessible from these technologies to create maintainable architectures in application’s code bases. I already see a host of browser served, ruby utilizing, .NET framework bastardizing apps that do crazy things from an architectural standpoint resulting in difficult deployment, and wildly different code organization.
One of the successes of rails to me is minimizing the number of APIs you need to do real work, and having standard conventions for placement of things. In the current ASP.NET MVC implementation, there is still a lot of calling C# code to wire up things like routes and opportunities for developers to place code in weird spots. I for one don’t enjoy when I switch from one project to another learning how they decided to do data access, exception handling, and all the other things that every single good ASP.NET app needs. This should be available for free, or though plugins similar to ruby’s mixins paradigm.
Therein lies my dream. I would love to see Microsoft create a MVC implementation that leverages the ruby language’s metaprogramming features to create a framework that uses XAML as its views and a combination of Active Record and REST for its models (whether in a Microsoft-created implementation that has providers for databases other than SQL Server) but is designed from the ground up for using WPF as a MVC runtime and not simply a clone of rails with a XAML view renderer. This framework needs to leverage ruby in its implementation – not just be another .NET framework you can code against with ruby.
I think Blender is cool for creating HI-FI XAML controls, but these should be databound to data served up by this MVC framework and rendered in the context of a controller action so that the same patterns are used as consistently as possible. I’m sick of the browser’s age old, buggy DOM – and if Silverlight is going to support everything in WPF 3.5 at some point, I would much rather code for this and test it on macs and under moonlight going forward. I would also like to see Microsoft ship an application that hosts Silverlight outside the browser on all platforms.
I know most folks probably won’t agree with me, but I think it’s high time that we get rid of some of the bloat that legacy browsers and class libraries bring when we aren’t even utilizing most of it in modern applications if they are designed well up-front. At some point you have to say that supporting the existing APIs in .NET is the responsibility of the .NET platform, and the DLR and Silverlight are new platforms for development that may have minimal interop, but are designed for a wholly different development model. Those who say this is too big of a goal don’t remember the Sun Microsystems and Microsoft from the 90s, who cranked out innovations in the runtime and user interface space every six months!