February 13, 2007
Several years ago I spent a few months at MSR on C# and XML integration. It’s satisfying to know that most of my complaints have been validated with time. Before this job I had very little use for XML. Once on the job I was appalled by the grotesque XML library APIs. The DOM and XmlWriter APIs were at odds with the superior functional style of tree construction. It appears that XLinq, an implementation of LINQ for XML data, finally offers normal constructors for XML node types. The query language, however, is a mess. LINQ (Language Integrated Query Language) is a good example of how Microsoft tries to solve a surface problem rather than the real, underlying problem. The surface problem is that the XML libraries are complex and offer no compile-time checks. The real underlying problem is that old-fashioned libraries are sometimes not good enough for complex domains. Functional languages solve some of this by having a super-fancy type system that can check some properties at compile-time. Macros solve another part of this by allowing library writers to make-up concise syntax for new domains. If C# added macros (like Fortress) and better typing hints (with attributes), then they could have implemented LINQ using those tools. Since they did it this way, they will have to add more junk to the language for the next batch of must-have features. C# will grow into a verbose mess like Ada.