Can we declare programming in Xml to be dead yet?

I’m writing a brief article today as a brief teaser on my StructureMap lessons learned talk for NDC 2009.  One of the 3 main themes of this talk is just about how our aesthetic expectations of a framework have changed and increased over the last 5 years.  As an example, StructureMap circa 2004 could only be used with copious amounts of verbose Xml and/or StructureMap attributes scattered all over the code.  Personally, I would find the StructureMap of 2004 to be completely unusable and fall far short of the expectations for framework usability I have today in 2009. 

I think the single biggest improvements in StructureMap usage for me personally is using the Registry DSL with Intellisense and type safety to do the configuration as opposed to copious Xml with lots of strings.  The same thing applies to Fluent NHibernate’s DSL compared to the old error prone hbm.xml files. 

I did quite a bit of work in server side Java in 2007 and the only thing I remember is how much I hated all the freaking Xml cruft.  I don’t have anything against Xml in general, or at least for the things Xml was actually meant for in the first place, but I’m completely done with coding in Xml. 

So my question to you is can we declare the mid-2000′s fling with programming by Xml files to be a dead or dying trend?  Is there anyone out there that still believes in “just make it an Xml file so we can change things without compiling?”  Microsoft is still churning out tools that have quite a bit of Xml heft behind them (what’s up with their love affair with Xaml?), but do you think that trend is at least waning?

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous Coward

    XML was never really meant as a language for creating configuration files, for providing API information or for serializing data. And indeed, for these uses, JSON, YAML and other languages can be better than it. XML was designed with documents in mind, and at that, it is better than everything else that has been invented so far. Could you imagine redoing the OpenDocument format in YAML? Creating web pages in JSON? No. These languages were just not made for this, and would do a very bad job at it. They don’t have as much support as XML for validation, schemas, namespaces and transformation, all things that are essential when working with documents, and they were simply not designed with documents in mind. XML is not dead: the only things that are dead are incorrect usages of XML. It still remains the best for all the things it was meant for.

  • Steve

    I hope so, I never understood why XML was such a big deal.  A structured, explicit, verbose, text file format.  It seems to fit with the same programmer ideology as Java.  Where doing the thing in the correct way is more important than doing the thing.  I find it cumbersome to work with and offering no advantages over other structured data formats.

  • Artie Gold

    XML provides a syntax that can be easily parsed and easily manipulated — that is its great strength (think in terms of decorated s-expressions). Using it as a common interchange format makes perfect sense. At the same time, exactly because of its syntactic regularity, placing a syntactic skin on top of it is pretty easy to do — and you really don’t want to be looking at reams of “code in XML” (or anything else, for that matter) in its native form.

  • http://WowGoldPig.com buy wow gold

    It will depend with the persons or company who’ll be using it.

  • Per Erik Stendahl

    “Can we declare programming in Xml to be dead yet?”

    According to the SharePoint team at Microsoft: HELL NO!

  • AndrewLV

    o.s, isn’t it really just a different way to look at the same problem? Where I previously worked we had config files 100s of lines long, considering we had one for each stage of development (at least one dev, QA, Stage, Production), that’s a lot of code sitting in XML that is difficult to verify.

    Using Jim’s method, he has the same number of files, but due to them implementing an Interface, his code won’t compile if a setting is missing. You can’t say the same for Xml Configuration Files.

    Xml Config Files do let you easily change things on the fly, but I’m not sure that’s necessarily a good thing. Granted, using Castle Windsor, I’m sure you could do the same thing with Jim’s method as well.

    Done right, I think an IConfig method isn’t that complicated at all.

  • o.s.

    @Jim Greco

    To answer both your questions. No and no. My *point* is that based on what you were trying to accomplish your code could be simplified to a much simpler design. You have greatly overcomplicated a simple task.

  • AndyB

    Jeremy / James

    A very pleasing and topical post for me. The problems I had with Spring configuration in my last project were unbelieveable and its the major lesson learned. The fluent terminology is new on me (with the exception of Fluent NHibernate) but one that I’m looking out for more and more now that I understand the major drive for it.
    Instinctively, I looked at the other tools that I produce a lot of XML files for and NAnt is the one that jumps out at me. I’ve used 2 completely unrelated editor tools in the past. These help me with XML syntax, but not with testability, etc. Excuse the ignorance, but does anyone know of any fluent NAnt movement?

  • http://www.jameskovacs.com james.kovacs

    I would argue that programming in XML is alive and well – whether we like it or not. Look at XAML, WF, MsBuild/NAnt, and many other technologies. You might get a pretty design surface over them (which is often more pain in anything beyond demoware), but you’re still programming in XML. The fluent APIs in Windsor, StructureMap, Fluent NH, and others are much better than their XML counterparts. Hopefully they continue to draw interest. At the heart of it, XML is a reasonable data format (not perfect, but reasonable), but XML for programming is a PITA. One of my big worries for the next five years… Are DSLs the next XML? A well-crafted DSL can be amazingly productive, but equally so is a well-crafted XML data document. Are we going to throw DSLs at every problem like we did XML and wind up in a similar conundrum in five years time, except with us bemoaning the inappropriate use of DSLs?

  • Brian

    5 years ago when I said all this XML config crap is for the birds I was nailed too the wall….

    Anyway though, I’m glad to see this post, it helps me feel vindicated for times in the past where this opinion was very very unpopular in certain circles.

  • Jim Greco

    and an multiple = with multiple

  • Jim Greco

    An interface and an multiple implementation is too complicated? Do you find unit testing hard too?

  • o.s.

    @Jim Greco
    Your design seems much too complicated and it stems from not using XML for what it is meant for which is a portable format for the interchange of data and *not* code. So XML is perfectly fine for storing data such as connection strings but a disaster waiting to happen for coding.

  • Bryce Fischer

    I think XML has its use. Like you, I’m skeptical of using it as a configuration file, as it can be quite verbose.

    It is quite useful for providing common format for interchange of data. But I think the days of it being considered a “human readable” format are over. With schemas, namespaces, etc… anything but the most simple XML file is far from readable without a good XML editor.

  • rf

    I find the use of XML in so called build scripts to be a source of particular frustration. XML should only be used for declarative data – in other words, configuration. Referring to an XML file as a “script” indicates a major problem. Only the most trivial builds can be described using declarative syntax alone. Builds of any complexity cause the configuration to quickly become horribly difficult to maintain, and you end up doing much of it in code anyway.

  • http://jonas.follesoe.no Jonas Follesø

    Interesting post Jeremy, and I’m looking forward to meeting you at the NDC this summer. I’m presenting on the MVVM pattern + Silverlight 3 business applications. So as you probably can guess by my choice of topics I’m a big XAML fan.

    But you got some interesting points, and I largely agree with you. I always prefer fluent DSL’s for config (IoC, Hibernate) over the error prone XML alternative. However, for UI I think the declarative nature of XAML works well – both from a tooling perspective and it’s also a good format for people with a web background. But I think your point about the WPF API being build for XAML, and not for developer friendliness is spot on. I often find my self struggling on how to achieve something using procedural code over XAML, and the code tends to be big, verbose and hard to follow with lots of untyped strings and object casting.

    It will be interesting to see if we (as the community) can come up with some other cool alternative approaches to WPF using some UI DSL + the new XAML/BAML Reader and Writer being introduced in WPF 4.0.

    Cheers,
    Jonas Follesø

  • http://realfiction.net Frank Quednau

    This should be expressed as a T-Shirt: “Say NO to XML programming” or something like that. I think I might get some interested…any takers over here?

  • Jim Greco

    “How do you change configuration for different environments with code over xml? Do you alter code as part of a pre-build event?”

    Never.

    It’s a simple interface (“IConfig”) with different implementations for each environment (each developer has one like “GrecoConfig” for their environments, “QAConfig”, “StageConfig”, “ProductionConfig”, etc.) .

    StructureMap injects the right implementation at run-time. A system variable controls which one to inject. One-time setup and you never worry about it again.

    Now everything is refactorable;
    Testable;
    Properties can be complex (i.e., I can have NumDays be an integer instead of a string that is parsed into an integer, I can have a ConnectionStrings object vs. just a string, etc.);
    Inheritance (qa, stage, and production use the same sql box, why repeat that 3 times?);
    Settings won’t allow for compilation if they aren’t there (what happens when you forget that new key/value pair that you added to the development xml config but not the production xml config)

    I see no reason any of this has to be in XML. If your deployment system sucks, work on it so deploying a stable build to any environment is a snap.

  • http://www.robertbeal.com Rob

    Fluent all the way for me.

    We had too much pain with oversized Windsor xml config files. Now they’re all fluently loaded in one small class. Much more manageable. Plus it’s all strongly typed, so no more runtime errors due to something missing from the xml config. If anything changes we get a compile time error which is much more preferable.

    Fluent NHibernate is the next thing we’re looking at to make our mapping files a little more robust.

    Xml has it’s place, but in terms of IoC and NHibernate I don’t know why you’d want to be able to change the config once deployed. May as well just have it compiled to start with.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Mike,

    Not really, and I vastly prefer the markup approach or WPF Xaml or Html/CSS versus the WinForms way. I do wish they’d made WPF’s Xaml more of a markup DSL instead of taking the serialization format shortcut. I think the way they implemented WPF’s XAML sacrifices some usability. I’m also willing to concede that maybe I’ve just never gotten completely used to Xaml in WPF.

  • Mike Christiansen

    I was thinking about it a little more and I wonder if it’s fair to go after XAML without going after HTML too. Do you perceive a fundamental difference between the idea of laying out the UI in XAML for a client app vs laying it out in HTML for a web app?

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Mike,

    The problem with Xml is the crazy ways we’ve used it far and beyond its original intention.

    Personally, I run very hot and cold on WPF. I love the underlying technology, but I’m iffy on Xaml and I think using WPF programatically is a near nightmare.

    I’ve had some luck using C# DSL’s on top of WPF and I still think the WPF + IronRuby combo could be killer. The raw “push button” API for WPF sucks hard because it’s optimized for Xaml rather than developer usability.

  • Mike Christiansen

    Your offhand dis of XAML put me in a defensive mode at first, but when I thought about it I realized it’s WPF I’m really a fan of, not XAML per se. I found XAML less cumbersome than traditional WinForms development, but it is cumbersome for the same reasons other forms of XML is cumbersome (although I’d say it’s level of Intellisense support is better than most).

    I didn’t miss the boat on some cool alternative to WPF did I? Or a cool alternative to using XAML with WPF? Bypassing XAML is certainly possible, but I’m not sure how easy it would be to make it concise enough to be readable.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Steve,

    Think readability and expressiveness too. Plus, even if the tooling got better to give you class, property, and method level intellisense in Xml editing like you’d need to make hbm xml files efficient, think how ugly that ends up looking.

  • http://unhandled-exceptions.com/blog Steve Bohlen

    I wonder how much of this (movement away from XML towards fluent-config stuff in code) is driven by important software design goals and how much is simply driven by the (relatively) poor tooling support for XML provided by many popular IDEs.

    For example, let’s assume for a moment that invoking RENAME of a class in the IDE cascaded the rename down into the XML that referenced it…would we *still* find XML config to be unacceptable–?

    This reminds me of the legions of (.NET) developers who similarly ‘hated and despised’ javascript largely due to the poor tooling support for it in Visual Studio rather than as the result of an actual software design decision about the value of javascript in improving their solutions.

    I wonder how much of the move away from XML towards config-in-code is really based on tooling limitations vs. design / requirements needs…

  • Matt Hinze

    The pendulum is definitely swinging away from XML, and for good reason. Will it swing too far, and is that possible? That’s the interesting question.

  • Jon

    How do you change configuration for different environments with code over xml? Do you alter code as part of a pre-build event?

  • matt

    How much of the pain is due to the amount of crap that has to go into XML that makes the hand coding painful at best (namespaces, angle brackets, closing tags, etc)?

    If you had perfect intellisense around a more compact syntax (JSON) and an easy way to know valid vs invalid, would it be interesting to express your intent in a non-code text file? (you could argue that you’ve already got this in C# initialization syntax, but is there benefit in storing this in something other than a compiled assembly?)

    How would one build tooling on top of the fluent nhibernate dsl or the structure map registry dsl? (I ask because I’m not familiar with either (two more todo’s added to the queue)). The nice thing about xaml / xml, etc is that tooling can operate on that pretty easily, as opposed to using codegen style transformation between the tooling representation and a c# seriialization format.

  • Victor Kornov

    You need to make a distinction between admin & developer configuration. They go to different places.
    Admin conf in xml or whatever is a good & necessary thing.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Jim Greco,

    You’re going a little bit farther than I would. We still keep NHibernate properties, connection strings, and file paths in config files. It’s the StructureMap.config file though.

  • Jim Greco

    Completely agree and it’s the most liberating thing ever. All of my configuratiion, even my connectionStrings, are hard-coded. The advantages of easy testability, refactoring capability, and intellisense blows away any argument for XML.

    “especially for doing overriding configuration details at deployment time.”

    You can do this with a configuration interface and an IoC.

  • Brian Yarger

    While I certainly think XML is dying as the only configuration mechanism of a framework, I still think it’s a valuable option, especially for doing overriding configuration details at deployment time.