Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Our 100 Language Future

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?

We’re polyglots right now. Think about it: to get your average data-driven web application of the ground you need to know HTML, CSS, C#/VB.NET with ASP.NET (php, Rails, etc), JavaScript, various XML dialects, and SQL. That’s a lot and we’re used to coping with it already. With the adoption of good Agile engineering practices like TDD, coding standards, and collective ownership and scripting languages such as Ruby and Python we have a new option in langauge oriented programming that scale in a team setting: Internal DSLs .

Those languages include DSLs, correct? And many of those will be specialized toward specific programming tasks [modeling, testing form creation], is that right?

Yes, absolutely.

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.

This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to Our 100 Language Future

  1. Dave Laribee says:

    Sure, look at antlr or even XML Schema.

    In the near term, I have more hope for internal DSLs as they’re easy to get started with; the base syntax is familiar.

  2. Jimmy Bogard says:

    That can be scary to some folks. More choices doesn’t always equate to better choices. I can see some work needed in the future for meta-DSLs, where you can ask the DSL, “what is your lexicon”, instead of relying on 100 wikis describing the 100 languages. Can’t wait though, DLR can’t get RTMd fast enough…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>