Microsoft’s two flagship languages, C# and VB, are set to diverge even more in the next release. One of the major features C# is not getting is XML Literals, and not everyone is happy about that.
Despite the fact that XML Literals were originally designed for C-Omega, the C# team decided to not support them because they didn’t want to “tie the C# language with another specific language/structure”.
The VB team, on the other hand, is betting heavily on deep XML support. Paul Vick summarized the C# teams concerns back in September of 2005:
1. It is extremely risky to put some portion of your language design in the hands of another language design team. In other words, if VB integrates XML as it stands today into our language, what happens in the future as the XML standard continues to evolve? What we do today may be sufficient and there may not be any demand for adding any further features the XML standard may add. But maybe not. And those features will not necessarily have been designed with an eye towards whether they’ll work well in VB. Heaven knows we’re going to have enough issues shoehorning XML into the language, what happens if we hit some really sticky issue in the future? What if XML heads in a direction we’re not willing or able to go in?
2. It is extremely risky to tie yourself explicitly to a technology that may or may not be here 15 years from now. Right now, XML is king. But what happens if some other technology comes along and knocks it off its perch? What if things radically shift in some other direction and XML suddenly becomes a side track instead of the main line?
Paul, the Technical Lead for Visual Basic, also gives some of the reasons why VB choose to support XML Literals despite these objections.
Like so many things in life, it’s all about tradeoffs. The C# team looks at the problem and says, “It’s more important to us that we design a language that is as minimal as possible and whose pieces are guaranteed (as much as anything ever is) to retain relevance for the forseeable future. Therefore, we’re willing to sacrifice some usability and some programmer speed to ensure this goal is reached.” Perfectly valid. The VB team, on the other hand, looks at the problem and says, “It’s more important to use that we design a language that allows people to solve the problems that are confronting them today in as simple and straightforward manner as possible. Therefore, we’re willing to take the chance that some feature that is fantastically useful right now may lose relevance in the future and perhaps even become almost entirely useless (c.f. Gosub, On … Goto, Open/Close, etc.).” Also perfectly valid.
Currently, the top search result for “VB 9 XML literals” is developer Steve Eichert post, XLinq has me wanting to code in VB.NET?!?! :
Ever since I started programming in .NET land I’ve been a C# bigot. The syntax jives with my brain. When I come across code samples presented in both VB.NET and C# I gloss over the VB.NET code in all it’s verbosity and jump directly to the real code (C#) .
I’ve semi-recently gotten to XLinq and it has me envying VB.NET programmers! The Xml literal support within VB.NET is pretty sweet.
Microsoft’s XML Team has posted some of the more recent changes to VB’s XML Literals. These include changing the Attributes axis from an Attribute object to a String, a slight change to the syntax for importing XML namespaces, auto-completion of tags, and treating all XML names as symbols in a manner similar to CLR variables.
InfoQ Asks: Does C# Need VB9's XML Literals?