I feel that all my life, I’ve been channeling Rodney Dangerfield (may he rest in peace). For those of you too young to remember ol’ Rodney, he was a comedian, most famous during the ‘80s, whose catchphrase was “I don’t get no respect.” When you hear someone refer to Rodney Dangerfield as part of a metaphor, the assumption should be that they’re referring to the fact that they, too, don’t get any respect. (Nothing like having to explain your jokes, right?)
In any case, when I was a kid, the cool kids smoked cigarettes and rode motorcycles and played football (this was the early ‘70s, in Texas, mind you). I, on the other hand, played the piano and did my homework. Not cool. No respect. After college, when I started teaching, did I teach a cool subject and coach a cool sport? Nope. I conducted the glee club and taught geometry. When I started in the software industry, I started in technical support. Even back then, when software support actually occurred in the US of A, tech support got no respect. Certainly, the developers who worked at the company didn’t respect us. So I figured, “I’ll get a job in development, and then I’ll get some respect.” Not so. I got a job working on translations with the development team, and the “real” developers gave us no respect. So then, I figured “I’ll get a job on the real development team, and then I’ll get respect.” Well, not quite. In our company, the software team I was on didn’t get any respect, because their product didn’t sell as well as the “big” product.
Even after leaving the corporate world, I’ve “tied my cart” to products that, well, never seem to get the respect they deserve. I spent years programming in Microsoft Access, and you know how most of the development world feels about Access as a development platform. When the .NET revolution began, I, of course, focused on Visual Basic, because I had spent years and years honing skills with that language. And now, look: Visual Basic doesn’t get respect. “Real” developers use C#, right? (I say that sarcastically, in case you missed that subtlety.)
Actually, I shouldn’t complain. I get the respect that I need. I’m just looking for a tie in with the technical portion that follows. But I did have dinner last night with the woman who’s conducting the community theater production I’m currently playing piano for. We were discussing trying to control the 13-piece orchestra, and she popped out, “Well, you know, I’m the Rodney Dangerfield of conductors.” My response: “One gets the respect one demands.” And that’s my theory: if you do work that garners respect, you get the respect. (And she does, and people respect her. I have no idea where the comment came from.)
Did I mention that Rodney Dangerfield actually spoke at the festivities surrounding my college graduation? I feel he’s been with me all my life…
But back to Visual Basic, and getting the respect one demands. Visual Basic, in the .NET world, has been continually fighting public perception issues. I still love programming in Visual Basic, but there are times when the disdain in an audience is palpable when I do a code-heavy presentation using Visual Basic in public. (Real programmers, by the way, can read and write Visual Basic and C# with similar ease. That’s my theory, and I’m sticking with it.)
In Visual Studio 2008, both Visual Basic and C# have added some really great new language features. I love implicit type declaration, the use of anonymous types, and more. C# has some advantages in the new environment, but I must confess: there’s one specific area where Visual Basic has pulled way out in front, and severely demands the respect it deserves. That area is in the support for LINQ over XML. (Actually, Visual Basic excels at LINQ in general, but most clearly, when it comes to handling XML.) Let me show you some comparative code samples, to prove my point.
Assume you can create an XML file containing customer information, and you’d like to create a new customer. In C# (or in Visual Basic), you could write the code like this:
[C#]
XDocument customers =
new XDocument(
new XDeclaration("1.0", "utf-8", "yes"),
new XComment("Sample customer information"),
new XElement("Customers",
new XElement("Customer",
new XAttribute("CustomerID", "MICRO"),
new XElement("Company", "Microsoft"),
new XElement("ContactName",
"Andrew Fuller"),
new XElement("Country", "USA"),
new XElement("Orders",
new XElement("Order",
new XAttribute("OrderID", "10643")
)
)
)
)
);
You have to admit, the new System.Xml.Linq.XDocument class (and its friends, XElement, XAttribute, and so on) make creating XML content a lot easier. But it’s still a lot of tricky code, requiring careful placement of parentheses and commas. On the other hand, you can create the same fixed content in Visual Basic using embedded XML, like this:
[Visual Basic]
Dim customers = _
<?xml version="1.0" encoding="utf-8"
standalone="yes"?>
<!--Sample customer information-->
<Customers>
<Customer CustomerID="MICRO">
<Company>Microsoft</Company>
<ContactName>Andrew Fuller</ContactName>
<Country>USA</Country>
<Orders>
<Order OrderID="10643"/>
</Orders>
</Customer>
</Customers>
What’s more, as you type this code in the Visual Basic editor, the editor creates closing tags for you, and formats the XML as you type.
Suppose you have a list of customers in a collection of XElement instances, and you’d like to display specific elements and attributes. In C#, you might write code like this:
foreach (var item in items)
{
Console.WriteLine("{0}: {1,-40} ({2})",
item.Attribute("CustomerID").Value,
item.Element("Company").Value,
item.Element("Phone").Value);
}
Not only must you call functions (Attribute, Element, and so on) to retrieve the values, you simply pass the name of the item you want to the function, and there’s no compile-time checking of your typing. Visual Basic, on the other hand, supports XML literals, which not only allow you to simply refer to values within the XML content, but if you’ve added a schema for your data to your project, you even get IntelliSense from the schema as you type. I can’t show that here, but you can certainly appreciate the neater code (and can imagine the IntelliSense you’d see as you type):
[Visual Basic]
Console.WriteLine("{0}: {1,-40} ({2})", _
item.@CustomerID, _
item.<Company>.Value, _
item.<Phone>.Value)
Both Visual Basic and C# allow you to use LINQ to transform XML content, using the query’s from and where clauses to the “columns” and “rows” of data to work with, and the select clause allows you to generate new XML content as you iterate through the data from the input XML. For example, the following C# code formats a Customer list so that it becomes a Contacts list:
[C#]
XElement contacts =
new XElement("Contacts",
from c in customers.Elements("Customer")
where c.Element("Country").Value == "USA"
select new XElement("Contact",
new XElement("Name",
c.Element("ContactName").Value),
c.Element("Company"),
new XElement("Phone",
new XAttribute("type", "Work"),
c.Element("Phone").Value),
new XElement("Phone",
new XAttribute("type", "Fax"),
c.Element("Fax").Value)
)
);
The result of running that code, in its context, is XML content that looks like this (with one contact for each customer in the original list):
<Contacts>
<Contact>
<Name>Liu Wong</Name>
<Company>The Cracker Box</Company>
<Phone type="Work">(406) 555-5834</Phone>
<Phone type="Fax">(406) 555-8083</Phone>
</Contact>
</Contacts>
Combining Visual Basic’s support for embedded XML, and XML literals with its support for replacement tokens (runtime-replaced values surrounded in code with ASP.NET’s <%= %> delimiters), you can rewrite the previous code like this:
Dim contacts = _
<Contacts>
<%= From c In customers.<Customer> _
Select <Contact>
<Name><%= c.<ContactName>.Value %></Name>
<%= c.<Company> %>
<Phone type="Work">
<%= c.<Phone>.Value %></Phone>
<Phone type="Fax">
<%= c.<Fax>.Value %></Phone>
</Contact> %>
</Contacts>
At first glance, it seems complicated because of all the strange tokens, but as you study the code, it becomes clear that this is an elegant way to perform repetitive XML transformations.
Is superiority in the LINQ over XML arena going to convince C# developers to move to Visual Basic? I doubt it. But it does prove that the Visual Basic team is doing some truly interesting and innovative things, and demanding respect for the language. I firmly believe that you should always use the tool that gets you the results you need in the most expedient manner possible-when working with LINQ over XML, that’s certainly Visual Basic, as far as I’m concerned. If Visual Basic keeps adding features like these, I’m hoping it can shed that Rodney Dangerfield aura, and get the respect it deserves.
