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 "Propagatio n 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.Sho w' 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.Visu alBasic.dll". "Microsoft.Visu alBasic.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.Visu alBasic'
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.Visu alBasic' 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>.<me thod>') 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/>
