InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Does C# Need VB9's XML Literals?

Posted by Jonathan Allen on Mar 01, 2007

Sections
Development
Topics
.NET
Tags
Visual Basic.NET ,
XML ,
C# ,
LINQ

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?

Does C# Need VB9's XML Literals? by Tomas Petricek Posted
  1. Back to top

    Does C# Need VB9's XML Literals?

    by Tomas Petricek

    I think it is goo that there is finally some difference between C# and VB (in the Orcas). C# is focusing more on being a language based on smaller set of general principles, great for writing bussines logic etc. while VB will be ideal for writing user interfaces (and similar) with advanced support for everything you need to put the application together as quickly and easily as possible.

    BTW: I think that XML literals in C-omega were more general than these in VB, beacuse they were used for initializing not only XML data, but also object structure. This concept is used in C# 3, but is realised using "object initializer" syntax.

    Tomas

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.