Xml is the code of the future – so long C# – say it isn’t so.

Ok, so the title is a bit sarcastic. I remember the debut of Xml. We used it for data. It was a way to improve on comma-delimited strings. We converted from flat files to xml files for data.

It wasn’t long before scripting could be expressed in Xml, and now I see teams with large libraries of executable Xml in the form of build scripts with NAnt.

I think it’s going to far, however. I’m beginning to hear that all software can now be expressed in Xml if you have the right tools. The implications of that is just shifting from C# programming to Xml programming. Whatever the language of execution is – that’s the programming language.

I share Ayende’s concern for Xml programming. Xml is not a 5th generation language. Just because designers can generate Xml instead of C# doesn’t mean code is going away. It just means that the chosen syntax is different for the generated code.

My stance on code generation has always been:

Machine generates code, human maintains (bad)
Machine generates code, machine runs code, human never has to see code (good). i.e. C# to MSIL
Machine generates code exactly how human would have written it anyway (good – just saves typing).
Machine generates code, human has to modify code and then maintain (worst)

Designers fall into the category that WANTS to be the 2nd bullet point, but that never happens. WinForms tried to do this with the .designer file, but that code still needed to be understood and tweaked from time to time. Designers don’t have good track records because they always constrain flexibility. When you hit a wall, you always have to fall back and change the generated code. That’s the problem. Good intentions, but it won’t happen that way. For it to work, the designer has to be the language.

Designers come and designers go. Languages stay and evolve.

Gil Zilberfeld 5:47 pm on June 22, 2007

I agree with everything here, and of course with Ayende’s views.
Think about it this way: first you design with a designer. Next you have intelisense to “easily” modify your “code”. It looks like you are led in the wrong direction all along.

I’m not saying the tools should make it harder to code, but it is easy to fall into this trap and very hard to go out.
Jim 9:08 pm on June 22, 2007

XML is a powerful tool to be used in application design and development, however like any tool it requires experience and skill to use it appropriately. The idea of using XML to implement and more importantly to override behavior at runtime can be a highly appropriate and efficient way of overcoming technical hurdles. In SaaS environments, for instance, where business requirements make the idea of programming and compiling behavior for a particular customer cost and time prohibitive, XML (on disk, in a database, or generated on the fly) allows the administrator of the software to modify behavior and schema of classes on the fly. This technique is very powerful and definitely does not encroach on the role of C# in developing the application. Classes are still required to load and use the XML at runtime. Like any advancement in application architecture, using XML to model and override behavior is a tool to complement your code and allow you to build more powerful and dynamic solutions to meet business problems. Proper design of such a solution and well designed XML schemas are essential to make the processing of building your metadata as resistant to errors as possible. XML is not replacing C# development, but augmenting it.
ScottBellware 2:03 am on June 23, 2007

Jim,

Most changes to behavior typically require regression testing, which render’s the run-time flexibility of configuration-based behavior pretty much irrelevant. If you’rve gotta take the time to regression test, you might as well just code the configuration as a compiled plug-in in a programming language that is in fact a programming langauge rather than a persistence format attempting to play the role of a programming language.
Jim 11:30 pm on June 23, 2007

Scott,

I think you’ve hit the heart of the issue which is using XML to model behavior intelligently. If XML is being used to control behavior to the point that regression testing is necessary when XML is changed then too much behavior is being modeled in XML and not enough in C#. However, if the individual components (or activities in WF) are well defined, well written, and well abstracted, then a change to the metadata that influences the order, steps, or output of that behavior should be interchangeable (to the extent defined in your schemas).

So, if it’s possible to develop XML that passes schema validation yet can still cause exceptions in the code designed to handle XML conforming to that schema then the code/XML balance, the code, or the schema restricting the XML is poorly designed.
Dorai Thodla 4:36 am on June 24, 2007

This is not an either or situation. XML is extensible. This leads to expressing solutions closer to the problem domain. The wide adoption of XML for data interchange is an example.

The wide use of XML as a way to represent UI (Flex, XAML, XUL) is another.

XML is not likely to replace languages like Ruby, Python, C# or Java, just like SQL never replaced programming languages.

XML is a meta language. But its representation makes it difficult to read.

The major benefits of XML is the high level of abstractions you can achieve in a declarative style.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Xml is the code of the future – so long C# – say it isn’t so.

Related