Jack Vaughan just posted an email interview we did about the DLR and the future for polyglot software developers. In early October I did a talk at Remix Boston about the current state of DSLs on the .NET Framework and what the Dynamic Language Runtime will buy us in terms of additional expressibility.
The interview is on TheServerSide.NET, but I’ve included the raw transcript sans editing for the record…
You think developers will more likely become polyglots in the future; why is that?
Those languages include DSLs, correct? And many of those will be specialized toward specific programming tasks [modeling, testing form creation], is that right?
We see this working in the Ruby on Rails community as they have lots of little DSLs (migrations, validation, rjs) that work together in orthogonal areas of one application. So when I say that “in the future we’ll need to know 100 languages” what I mean is that we’ll be using straw man frameworks that express the kinds of task we do in domain specific languages. These areas don’t have to be particularly large, in fact the DSLs getting attention right now tend to have a laser-like focus. Haml from the Ruby communty springs to mind. It’s a little language that expresses HTML in a highly-readable Ruby syntax.
What a lot of us in the .NET world are hoping is that we’ll have the tools to go down the Internal DSL route. This means having dynamic languages like IronPython and IronRuby and access to integrate the Dynamic Language Runtime (DLR) into our applications and frameworks. I see Internal DSLs as a more attainable step toward language oriented programming than their External DSL counterparts. Microsoft has an offering in this department, the DSL toolkit, but it is firmly in the External DSL camp. It’s a great vision but many Agilists would prefer, at this stage in our industry’s growth and development, to model problems in code. The maintainability angle is easily achieved in a dynamic language such as Ruby with a few syntactic tweaks, there’s a good testing story, it prevents the need for custom translation/transformation, and – while Ruby has constraints – we’re not constrained to a visual, “boxes-and-arrows” programming paradigm.
How would you describe MonoRail in the context of the above discussion?
MonoRail is a Model View Controller framework for .NET web applications inspired by Rails. I see frameworks as a logical place to start developing DSLs. For example, in your model you can express declarative validation in a somewhat custom syntax. My hope is that MonoRail, which is already an excellent offering, and the forthcoming ASP.NET MVC framework will support the dynamic languages so that more Internal DSLs can be built to express functionality within the viewpoints of the MVC micro-architecture.
In my opinion the clearest example of a Domain Specific Language on the .NET platform is LINQ. LINQ is a little language targeted at expressing queries over objects, SQL, XML, really any kind of data for which a developer (or Microsoft) is motivated enough to write an implementation for. It is an Internal DSL.
Motivation is the keyword. Internal DSLs have taken off in the open source community and having a platform that supports this concept is a key driver in growing both the quality and quantity of .NET open source projects. Technologies such as IronRuby, IronPython, and the DLR should provide some fuel for the innovation fire.