C# vs VB.NET - which is better?

It never ceases to amaze me how every single programmer I’ve ever met has a strong and unshakable fundamentalist religious faith that the language they choose is the best and can provide a wide number of arguements for it.

Historically, you had to have a position on C++ vs VB. Visual Basic being a Rapid Application Development tool, or quick and dirty, whilst C++ was considered more elegant, resourceful and “manly”. VB required a library of additional runtimes and up until VB6 service pack 6, had a lot of bugs, mostly to do with memory management. C++ was always the domain of the purist, who would often look down on the VB guy and his less-efficient binary. C++’ers would snub VB’ers whilst in the office. VB’ers would snub C++’ers when down at the pub, enjoying a project-completed pint while the C++ programmer was still months behind…

VB, dubbed as VBA was the language chosen by Microsoft as a scripting language for their applications. As such, it was the first language used by businesspeople, accountants, scientists and the like who needed to code without needing to learn Object Orientation or non-intuitive coding symbols such as those found in C: {};*. VB was taken up by developers and managers who “just wanted to get things done”, and usually not caring a great deal over memory or sheer performance. For the heavy lifting, you would rarely use VB anyway.

At the end of the day, purist geeks and hobbiests versus owner-managers will be each to their own, but those who are paying for the development - the managers, business owners, and ultimately directors, investors and shareholders, will want the problems solved, quickly. They will not care about your factory classes, polymorphism or multiple inheritance. They will care if you spend ten times longer than you “should” be working on low level code when the business task necessites quick, rapid testing and deployment. A motto I heard at a Microsoft Conference for succesful software projects is, “Build early, Build often”. You often can’t build early (maybe not even for months) if you are particularly low level. You need to keep a bigger picture, get your first “build” out within a day or two. Trust me, I’ve seen many projects (not my own, thankfully) go to the wall because they didn’t get installers built early enough or didn’t have the technology choices down right at the beginning of the project.

There are some cases where both languages are useful. A quick couple of days in VB to prototype and demonstrate a new software tool, followed by C++ modules to do the number-crunching, with the interface in VB.

When Microsoft introduced .NET they made accessibility one of the main design goals. It now doesn’t matter which language you are comfortable with - they all go through the same MSIL compiler and the result is exactly the same. .NET is also fully Object Orientated, so if you’re coming to .NET from a C++ or Java background, you’ll find that line-for-line your code will essentially look the same. However, if you’re coming from Classic Event-Driven/Procedural VB, you’ve got to master Object Orientation.

However, now, C# and VB.NET are for all intents and purposes - exactly the same. With VB.NET, it is slightly more productive, you need less lines of code as the compiler makes more of an effort to understand what you’ve written without the need for end-line characters or curly-bracket delimiters.

VB.NET also trumps C# in a few other key areas:

1. Background Compilation (instead of just a Parser)
2. Edit and Continue (new to 2005 - and a massive productivity boost)
3. Refactoring Support
4. Ability to utilise existing VB6 code
5. Code Snippets

I’m not sure why C# does not offer the above. I cannot see a technical reason for it, as essentially these productivity tools are down to the IDE.

If you were writing in Notepad, who cares which language you use? C# is probably neater for this type of grass-roots coding. But since VB.NET has the nicer IDE, I’ll stick with the more productive language of VB.NET over C#.

A twist to the tale..

Just checking the UK job market, as of today these are the rates for the VB.NET and C# programmers:

VB.NET Programmer, hourly rate
£34/hour, £36100/annum

C# Programmer hourly rate (22% more!)
£44/hour, £38500/annum

Today, C# Programmers are paid 22% more than VB.NET developers to write exactly the same .NET code!

My advice? Stick to whatever feels best for you. If you’re a dyed-in-the-wool C++ programmer, jump to C# and forgo the advanced IDE improvements for the VB.NET crowd. If you’re just starting out, I recommend getting a free copy of “VB.NET Express” from the Microsoft website - the language looks easier to read than C# and the productivity improvements will save you time. Time that you can spend on other persuits; like your family that you’ve neglected whilst you’ve been studying C++.

Useful Links:

C# to VB.NET and VB.NET to C# Converters

http://labs.developerfusion.co.uk/convert/csharp-to-vb.aspx

http://labs.developerfusion.co.uk/convert/vb-to-csharp.aspx

C# and VB.NET Language Comparison (if you read and understand this, you won’t need to use the converters)

http://www.harding.edu/fmccown/vbnet_csharp_comparison.html

XML in SQL Server 2005

Those of you who are familiar with SQL Server 2005 will know that Microsoft have provided a brand new “xml” datatype for use with it.

The new xml datatype effectively allows a database administrator or developer to create SQL databases which contain heirarchical information within the context of a single field. This is an incredibly powerful data design paradigm. Using the standard data types for relational database management systems, you would have to create at least one normalised table per entity class, with each property of the entity class being designed for - ahead of time - by creating the table schema design for it. This works very well if you know well in advance exactly what data you are planning to store.

But what if you have to store information on a product which has a vast quantity of varying properties (such a car). You couldn’t add these as properties of a table, since you would quickly run out of space or have a lot of unused, redundant fields.

Traditionally, this would be exposed as a design flaw later on in the project lifecycle, necessitating the addition of lots of child tables with foreign keys, and therefore a large amount of code would need to be changed in order to accomodate this.

Enter, XML. Already used as the basis for most modern day information storage and transfer needs, it is now possible to store XML strings directly into columns within your SQL database. This is supported in any .mdf database engine, including SQL Server, SQL Everywhere, SQL Express and SQL Mobile.

This is wonderful news for object orientated programmers, who now have a flexible way of storing rich, hierarchical information, which can be extended at a moment’s notice without requiring any breaking changes to be made.

The XML in the database can also be queried. Previously to the XML datatype, I have seen XML data were stored as ntext (eww), varchar (yuck) or BLOB’s (binary objects). The new XML datatype can be queried directly. This is going to be as close as relational databases come to pivot-tables

Last week, in a recent database implementation for one of my clients, I noticed that SQL Server 2005 was throwing some very odd errors back to my SQL data class: “SqlException: unable to switch the encoding”. Long story short, SQL Server 2005 does not support UTF-8 to store data, and the “standard” XML well formed declaration contains encode=”UTF-8″.

Nearly everyone starting out using the xml datatype will hit this error. The error will be thrown the moment that you attempt to insert sample XML into the column:

System.Data.SqlClient.SqlException:
“XML parsing: line 1, character xxx, unable to switch the encoding”

SQL Server 2005 expects to receive UTF-16 encoded XML, and will not accept XML if it contains a UTF-8 declaration.

The solutions are to either:

1. Remove the declaration from your XML when inserting to your SQL database
2. Change the encoding to UTF-8.

If you want to do change the encoding to UTF-16, you could try using the following code to perform your conversion:

System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
System.Xml.XmlDocument newDoc = new System.Xml.XmlDocument();
System.IO.StreamReader r = new System.IO.StreamReader(”C:\XML.xml”);
doc.LoadXml(r.ReadToEnd());
r.Close();

System.Xml.XmlDeclaration xmldecl;
System.Xml.XmlElement root = newDoc.DocumentElement;
xmldecl = newDoc.CreateXmlDeclaration(”1.0″, null, null);
xmldecl.Standalone = “yes”;xmldecl.Encoding = “UTF-16″;
newDoc.LoadXml(doc.DocumentElement.OuterXml.ToString());
newDoc.InsertBefore(xmldecl, root);

Or if you’re in a hurry (and have a hard-coded declaration string):

xmlString = xmlString.replace(”<?xml version=”"1.0″” encoding=”"UTF-8″“?>“,”");

I hope this helps someone. If you find the code above useful, please leave a comment.

« Previous Page