Re: Not Another C# Versus VB Article (It has a lot to say about Anders and Delphi)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

You'll find the translation below:

http://www.codeproject.com/useritems/CSharpVersusVB.asp

This article is IMO stamped by a number of unfounded prejudices and thus includes some incorrect conclusions. I have taken some of the points made in the section "Propagation of Culture in .NET" and commented them:

| 1.    VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This point doesn't apply to professional development. In a professional environment, almost all developers work with 'Option Strict On', which will make VB.NET more type-safe than C#. If 'Option Strict' is turned off, this decision is based on technical considerations, for example, to ease access to COM object models like those of Microsoft Office. The author of the article constructs a disadvantage out from an additional, useful feature.

| 2.    VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

I don't see any reasons whe the existance of an /additional/ language construct for error handling leads to sloppier code or non-existant error handling. VB.NET supports 'Try...Catch' including 'When', which is superior to C#'s 'try...catch' error handling structure. VB.NET provides advantages over C# in matters of error/exception handling capabilities because it provides constructs which match better with the different afforfances of error/exception handling.

| 3.    VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

That's wrong too. VB.NET supports optional parameters as an additional feature. Optional parameters provide advantages when used inside implementations, and are thus useful in some situations. Don't forget that methods using optional parameters do not suffer from the "overloads hell". When comparing 'MsgBox' to 'MessageBox.Show' usability for the latter in VS.NET is bad because you'll have to pick the right overload from a long list. On the other hand, 'MsgBox' is a function with many optional paramters, but usability doesn't suffer. While overloading makes sense in some cases, I would not see it as a general replacement of optional parameters, because makes writing code harder and will lead to less-descriptive code. One other solution to this problem is to give the methods more specific names instead of overloading a single, generic name. Altogether there is not a single "best" solution, but there are many good solution for different cases -- and optional parameters are one of them.

Overloading vs. Object Technology
<URL:http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf>

| 4.    VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
|  still use them. In new VB projects, this dangerous namespace is included
| by default.

Wrong. Microsoft has never published a recommendation not to use functionality implemented in
"Microsoft.VisualBasic.dll". "Microsoft.VisualBasic.dll" can be seen as a "language extension" of the core VB.NET programming language. It's as useful as 'using' in C# because it provides a shortcut to existing functionality of the .NET Framework. Additionally 'Microsoft.VisualBasic' contains functionality which is not present in the .NET Framework, like support for financial mathematics, 'Left', 'Right', 'Fix', 'Split' with support for strings as separators, ..., and it's absolutely not "dangerous" to use this functionality. Some of the functions provided in 'Microsoft.VisualBasic' are even faster than their .NET Framework counterparts.

| 5.    VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Wrong again. VB.NEt supports are more explicit syntax for interface implementation ('Implements <interface>.<method>') than C#. This syntax makes it more obviosu which method of the class implements which method of an interface. In C# that's not obvious because there is no way to decide whether or not a method implements a method of an interface or simply extends the class without taking a look at the base class.

| 6. VB supports background compilation. While this speeds the development
| cycle for small projects, it slows down the IDE in large projects, contributing
| at least in part to the culture tending to gravitate toward small
| projects.

This was true for VB.NET 2002, but in version 2003 there were significant speed improvements. In VB 2005 there will likely be some additional improvements for background compilation. Splitting up the solution into multiple projects can lead to an improved experience too.

| 7.    C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

There is absolutely nothing that prevents one from using namespaces in VB.NET the way they are used in C#.

Conclusion: An unprofessional developer will write bad code in both C# and VB.NET, a good deveöoper will be able to write good code in both programming languages. Optional additional language features are an advantage if the assist a professional developer with his/her work. They are not bad only because an unprofessional developer doesn't know how and when to use them.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/> 

.

Relevant Pages