Why VB.Net XML Literals are not a good idea

The days of programming in just one language are long gone. To use the power of modern programming environments your code gets interlaced with SQL, XML, XPath, XQuery, Regex, HQL and more. Usually this doesn´t help make your code more readable. All the ´alien´ code lives in strings so it won´t benefit from autocompletion and syntax highlighting offered by modern ide´s and more importantly... no checks by the compiler. Any mistakes you make won't show up until you (or a customer) runs the code.

Microsoft has 'solved' this problem for Xml by making Xml part of VB.Net with Xml literals. You can now sprinkle your code with Xml. While this seems nice I think it only solves part of the problem in a bad way. Productivity won't increase by giving developers the tools to write a lot of unreadable code really fast.

For C# I'd like a more extendable solution for this problem. There's no problem with storing code in strings as long as the editor and the compiler know what to expect. The only extension to the language should be a mechanism to let programmers express what should be inside a string. That leaves the door open for your editor and compiler to call plugins to check the code without blurring the lines between languages.

Print | posted on Wednesday, November 21, 2007 5:56 PM

Feedback

# re: Why VB.Net XML Literals are not a good idea

Left by Michalis Sarigiannidis at 12/3/2007 1:44 PM
Gravatar How about Linq to XSD? The extensions are not out yet, but - if we believe the guys working on them - they are on their way.

# re: Why VB.Net XML Literals are not a good idea

Left by Mendelt Siebenga at 12/4/2007 4:50 PM
Gravatar Thanks. I hadn't seen Linq to XSD before. I'll have a look at it.

Your comment:





 
Please add 7 and 6 and type the answer here:

Copyright © Mendelt Siebenga

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski