Dynamic Language DSL vs Xml Configuration

code 0 comments suggest edit

Disclaimer: My opinions only, not anyone else’s. Nothing official here. I shouldn’t have to say this, but past history suggests I should. P.S. I’m not an expert on DSLs and Dynamic Languages ;)

This week I attended a talk by John Lam on IronRuby in which he trotted out the Uncle Ben line, with great power comes great responsibility. He was of course referring to the power in a dynamic language like Ruby.

Another quip he made stuck with me. He talked about how his brain sometimes gets twisted in a knot reading Ruby code written using metaprogramming techniques for hours at a time. It takes great concentration comprehending code on a meta and meta-meta level in which the code is manipulating and even rewriting code at runtime. Perhaps this is why C# will remain my primary language in the near term while I try and expand my brain to work on a higher level. ;)

However, the type of code I think he is referring to is the code for implementing a DSL itself. Once a DSL is written though, the code on top of that DSL ought to be quite readable. This is the nook where I see myself adopting IronRuby prior to using it as my primary language.I can see myself creating and using mini-DSLs (Domain Specific Languages) here and there as replacement for configuration.

Ahhh… configuration. I sometimes think this is a misnomer. At least in the way that the Java and .NET community have approached config in practice. We’ve had this trend in which we started jamming everything into XML configuration.

So much so, we often get asked to provide XML to configure features I think ought to be set in code along with unit tests. We’ve turned XML into a programming language, and a crappy one at that. Ayende talks about one issue with sweeping piles of XML configuration under a tool. This is not an intractable problem, but it highlights the fact that XML is code, but it is code with a lot of ceremony compared to the amount of essence. To understand what I mean by ceremony vs essence read Ending Legacy Code In Our Lifetime.

With the ASP.NET MVC project, we’ve taken the approach of Code First, Config Second. You can see this with our URL Routing feature. You define routes in code, and we might provide configuration for this feature in a future version.

With this approach, you can write unit tests for your route definitions which is a good thing! Routes basically turn the URL into a method invocation, why wouldn’t you want to have tests for that?

The reason I write about this now is that I’ve been playing around with IronRuby lately and want to post on some of the interesting stuff I’ve been doing in my own time. This post sets the context for why I am looking into this, apart from it just being plain fun and coming from a haacker ethic of wanting to see how things work.

Technorati Tags: DLR,IronRuby,Configuration,DSL

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



10 responses

  1. Avatar for MichaelD!
    MichaelD! April 18th, 2008

    You are ENTIRELY correct with your philosophy on configuration! Of course, I'm just saying that because I'm in complete agreement with you. :)
    However, IMHO, you should never ever release code that is Configuration Fodder (TM) that doesn't have the configuration component available for it. I was rather taken aback to see how Routes are expected to be constructed for MVC, gasping wildly while opening the Global.asax. :o Routes should totally be defined in configuration, and you're setting a poor example/practice by providing sample code otherwise, (IMHO :D).
    In fact, I would take this one step further by saying you should never release code that doesn't have configuration *AND* configuration DESIGN support for it.
    That is: Code First, Configuration Second, AND Design Third!
    Aren't we getting a little old to muck around in xml files? :)
    Enterprise Library is a great implementation of this process. Sure, it might be a bloated base, but their Code-->Configuration-->Design Support paradigm is SPOT ON(!!!), and all Microsoft products should follow this methodology for their products.
    We should never have to touch XML, just the GUI to construct it. :)
    Anyways, great blog. You have a new subscriber!

  2. Avatar for Dan Finch
    Dan Finch April 19th, 2008

    I agree - this has been on my mind alot. I recently tried to bake my own angle-bracket generator end-all distributed web application framework and full-featured content management system, and I started with configuration. After failing hard and I came to the conclusion that I should use "startup scripts" during major development and then write configuration after and only after everything which can be done with configuration can also be done in code. This is where WCF wins my heart - configuration, as prevalent as it is in WCF, is little more than a startup script.

  3. Avatar for Will Perry
    Will Perry April 19th, 2008

    XML is fine and dandy, but the tooling is so backward. We need the full support for code completion, intellisense and refactoring that is available in General Purpose Languages. XML is powerful, precisely for the reasons that Micheal D points out - we do need designers, but we also need it to be readable, testable and generateable (i think that may be a new word), XML is a good solution when you need to solve all those problems simultaneously.
    And lets not forget, a lot of the emphasis on configuration is around how Sys Admins can deploy code. XML is a familiar tool to this group of people, but perhaps powershell style start-up scripts could offer a higher level of customization and understandability without adding to the workload of administrators

  4. Avatar for Eric Larson
    Eric Larson April 20th, 2008

    One reason I think XML has been used the way is has in languages like Java/C# is because it provides a way to offer dynamic features without recompiling. XSLT is one example where you can conceivably add a huge amount of functionality and effectively script an application. This is slightly different from configuration, but the essence is the same.
    You don't see the same kind if issues with dynamic language often because the data structures are more flexible and convenient to write. I think this is partly why JSON is such a popular format. It allows a simple and relatively intuitive means of describing what would have originated in configuration object/hash/array/etc.
    If you consider the difference between:

    my_options = { 'root-url': 'http://example.com/app',
    'db-uri' : 'mysql:///localhost:5432/app' }

    With something like this:

    HashTable configHash = new HastTable({
    'root-url': 'http://example.com/app',
    'db-uri' : 'mysql:///localhost:5432/app'

    I this it becomes a little clearer how XML could be considered helpful for configuration.
    With that said, I try my best to avoid XML in configuration scenarios. In Python there is ConfigObj along with YAML that makes for much kinder configuration.

  5. Avatar for Bil Simser
    Bil Simser April 21st, 2008

    C# *is* my primary language. Love it, hate it, it works for me, and I use it every day. Will continue to do this until it goes away. I am however a proponent of opening myself up to new stuff, and find Ruby to be very sexy and useful.
    DSLs hands down over XML. It's the difference between night and day. EntLib 3 has done a great job of hiding the ugliness of editing app.config and it's the right way to do it. However, it's still xml behind the scenes and fallible. Almost every project I use EL3 on needs some hand editing love from time to time.
    I would love to see EntLib4 (probably too late) or EntLib5 to have a Ruby DSL as the input/output mechanism for it's configuration. Keep the GUI designer interface built into Visual Studio, just change the stream.
    DSLs are 100x more intent revealing and while I may not even look at the configuraiton file, knowing it's there in a form that I can understand without reams of documentation is a huge bonus, especially to maintenance developers. As it is right now, I'm looking at sending 3 or 4 2.0 apps built with EntLib 2.x to maintenance which means I have to give them a course in understanding the XML nodes that are valid and what they mean.
    A DSL that describes itself is the self-documenting panacea that XML touted itself to be. I have yet to see any XML file I can understand (except for the most basic) but I've never met a DSL I didn't like.

  6. Avatar for Adam Kahtava
    Adam Kahtava April 21st, 2008

    Anything but XML configuration!
    On a side note: while digging into the ASP.NET AJAX Futures Release I came across XML-Script that touted the promise of writing AJAX using XML (with out writing a line of JavaScript). It turned out to be another false promise, and an example of a XML configuration driven culture.
    DSL over XML any day!

  7. Avatar for Lance Fisher
    Lance Fisher April 22nd, 2008

    For a good example of a crappy XML programming language, look no further than MSBuild. What a pain to do anything out of the ordinary with it! How much nicer would it be if build scripts were built with any .NET language rather than a crazy XML file turned programming language.

  8. Avatar for Joe Brinkman
    Joe Brinkman April 22nd, 2008

    Phil I think this is one of those cases where we have become so used to the data == code mentality that we sometimes forget the usefulness of letting end users manipulate the data - whether in the raw form or through some other editing tool. It is so much more efficient to change a single line in a config file than it is to change a line of code and recompile. Moore's law has lulled us into a false sense that the performance hit from JIT compilation is negligible. Anyone who has ever been the first to hit an ASP.Net site after an app recycle will tell you otherwise.
    Also, we should not forget that Admins != Coders and our system designs (and the underlying APIs which help shape those designs) should reflect this fact. Asking an Admin to change a config file or edit a database record is far easier than requiring them to change a line of code and recompile.
    The MVC team is making a good decision to make sure that features like URL routing are testable but I think you still need to make sure that those same features are configurable at runtime since the people usually desiring to change those routes are not going to be comfortable with a code editor.

  9. Avatar for Haacked
    Haacked April 23rd, 2008

    @Joe but where do you draw the line? Would you let your sysadmin use a GUI to change the actual code of a running app?
    It reminds me of a story about a rules engine used by a major credit card company. They had a very nice GUI interface for changing rules. One day an "analyst" changes some minor rule for calculating interest based on various conditions and the next day realizes he just lost the company millions of dollars via a mistake. There were no tests!
    Although routing seems like config, I'm not so sure it should be treated as such.

  10. Avatar for n who r u?
    n who r u? December 17th, 2009