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.

Taxman clueless over Arctic Systems costs

A short post today as it’s Sunday afternoon and it’s sunny outside :) I’m going to comment on an article by Accountancy Age of the same name over here.

I’m sure we all know about Geoff and Diana Jones. They run Arctic Systems, a small family-run business which is representative of many thousands more businesses across the UK. They won (several times), their tax rulings in the courts where HM Revenue & Customs attempted to have the earnings of both partners calculated as if it was all the sole earnings of Geoff Jones.

According to a recent Freedom of Information Act enquiry conducted by AccountancyAge, HM Revenue & Customs, admit to having never estimated the legal costs of the Arctic Systems Case.

The Artic Systems case has been one of the most contraversial tax cases of this decade, a tax case not just on Geoff and Diana, but on all small businesses owned by couples. The principal issue is that our Government see that if you are a married (or civil partnership) couple - operating in the same business - then you should pay more tax than if you were not. The case started in 2004, and it wasn’t until recently in July 2007, an appeal case by HMRC at the House of Lords lost by 5 votes to 0 in favour of Geoff and Diana. Google for “Section 660a” if you need to know more.

Geoff and Diana Jones, Arctic Systems

But what about the costs? In fighting these unfair tax cases (not all are unjust, but S660a and IR35 cases very often are) HM Revenue & Customs are spending our public tax money to fund these speculative cases. HM Revenue & Customs have a reputation for long, prolonged tax investigations on freelancers and small businesses. Tax investigations, which last often as long as three or four years, cause a great deal of stress and uncertainty, usually damage the businesses in the long term (HM Revenue & Custom dragging your clients through the mud), and at the end (assuming you don’t lose), HM Revenue & Customs simply “drop the case” and walk away. Paying nothing to compensate you for your loss of earnings and the immense stress.

This fresh new evidence that HM Revenue & Customs did not estimate the costs of the legal case tells us all that the way in which our public tax money is spent needs to change. Before embarking on tortuous bullying legal campaigns against husband and wife businesses, they should count the costs to the public purse - and at least - estimate the costs of the defendant.

If these cases were between two private individuals, the loser would be expected to pay the costs of both sides. Not so with HM Revenue & Customs.

Let’s also call to the Government to bring more visability to the tax system, and end the clear discrimination against couples who run businesses together.

What do you think? I would be very interested to hear your thoughts.

Next Page »