Things VB can do that C# can't

Rockford Lhotka talks about Things VB can do that C# can't....

Comments

[Wesner Moise]

C# is generally geared toward computer scientist, and is primarily designed for library construction. While performance differences are virtually small between the two languages, you cannot argue that VB performs betters, as VB tends to trades off performance (more checks, late binding, runtime overhead) for ease of use, while C# attempts to be a more productive, yet performance-oriented, alternative to C++. In particular, the VB runtime functions perform slower than the .NET counterparts (they do additional work) and ultimately call into the simpler framework counterparts. For example, see Mid and Len using Reflector. Microsoft generally uses C# for Windows development and a VB programmer would not be taken seriously.

VB tends to be better for component-oriented program (especially Office) and general developers, who may not have a computer science background.

The list was not constructed accurately, as the author demonstrates lack of experience with C#.

1) One key VB feature is that it eliminates an entire class of runtime error you get in case sensitive languages - where a method parameter and property in the same class have the same name but for case. These problems can only be found through runtime testing, not by the compiler. This is a stupid thing that is solved in VB by avoiding the archaic concept of case sensitivity.

Point #1 is not really an issue. Any potential errors are fairly rare. Properties are generally PascalCased and parameters are camelCased. Secondly, this is a feature prized in the C# community. Also, the intellisense corrects any casing issues, so it's not really an inconvenience.

You should also point out that the case-insensitivity of VB can result in the same type of ambiguities. A VB developer may attempt to call Count (a property) which is confused with count (a parameter). However, I believe the editor actually automatically corrects the casing.

2) Handle multiple events in single method (superior separation of interface and implementation).

Point #2 is also not unique to VB. The author clearly has not used C# event mechanism. C# can map events to the same method; this is the standard behavior in C#. The Handles keyword provides a declarative notation that does not provide any more expressiveness than the one-line of imperative code it replaces. This is primarily an ease of use alternative.

3) WithEvents is a huge difference in general, since it dramatically simplifies (or even enables) several code generation scenarios.

The author clearly does not understand the implementation of WithEvents; see Paul Vick's blog for details. WithEvents provides a declarative notation for a feature that can be written (and is internally written) in one line of code using AddHandler. This is primarily an ease of use alternative. When the variable is set, the VB calls AddHandler for each method associated with the variable, and RemoveHandler when the variable is changed.

4) In VB you can actually tell the difference between inheriting from a base class and implementing an interface. In C# the syntax for both is identical, even though the semantic meaning is very different.

This is a non-issue. In the framework, interfaces are preceded with the letter I.

5) Implement multiple interface items in a single method (superior separation of interface and implementation).

This is not unique to VB. Interface methods with the same name to the same implicit public method. What VB does add is the ability to map an interface method to an arbitrary method. This feature is dubious and can be imitated in C# with three lines of code by providing an explicit interface implementation and calling the arbitrary method.

6) Also, independent naming/scoping of methods that implement an interface method - C# interface implementation is comparable to the sucky way VB6 did it... (superior separation of interface and implementation).

I must point out that VB in 2003 does not allow derived classes to override an interface implemented in a base class. This is supported by C# and is used quite frequently in C#. VB Whidbey removes the restriction.

The separation of interface and implementation is not a valid point, since explicit interface implementation in C# provides the most general level of separation.

7) Multiple indexed properties (C# only allows a single indexed property).

This is a valid feature criticism. C# developers must define use methods. Let me point out in VB that the syntax for accessing indexed properties and methods calls is identical.

8) Optional parameters (important for Office integration, and general code cleanliness).

This is a valid feature criticism. C# developers must use operator overloading. The reasons for the omission of this feature is the poor versioning of optional parameters.

7) Late binding (C# requires manual use of reflection).

This is a valid feature criticism. Note reflection is at least 400 times slower than early binding. Secondly, calling reflection manually is not that cumbersome. Examples, here is how to call a method.

obj.GetType().GetMethod("Method").Invoke(obj, args);

8) There are several COM interop features in VB that require much more work in C#. VB has the ComClass attribute and the CreateObject method for instance.

The attribute is also available in C# and a framework CreateObject alternative is available.

9) The Cxxx() methods (such as CDate, CInt, CStr, etc) offer some serious benefits over Convert.xxx. Sometimes performance, but more often increased functionality that takes several lines of C# to achieve.

C# developers generally do not use the Convert class as it is quite redundant and more likely to perform words. C# supports direct casting syntax that map to IL instructions. I believe that the Convert class was originally introduced to support the needs of the VB team, not C# team.

10) The VB RTL also includes a bunch of complex financial functions for dealing with interest, etc. In C# you either write them by hand or buy a third-party library (because self-respecting C# devs won't use the VB RTL even if they have to pay for an alternative).

The runtime library is accessible to C# using Microsoft.VisualBasic.

11) The InputBox method is a simple way to get a string from the user without having to build a custom form.

True, a form is required ... but it does not provide a professional user interface.

12) Sound a Beep in less than a page of code.

Calling the Beep equivalent does not require a page of code, just 2 lines of code using PInvoke.
Beep requires a PInvoke declaration, and one line of code for each call to MessageBeep.

[DllImport("user32.dll")] public static extern bool MessageBeep( int beep );
MessageBeep(-1);

By the way, this is not a professional user interface.

[Anand]

Wes, Atleast you got a feel of what the VB programmer feels when he sees all the carp that gets written on how C# is better that VB etc...

And I would like to point out the Lhotka does have books published on C# too. So I would say that the part on "the author demonstrates lack of experience with C#" does not hold.

And Wes, I do program in C#, though I try to minimize it and though I love VB, am not aiming to start off another language war. ;-)

[mearls@hotmail.com]

Why can't we just get along?

[sudhakar]

Ah ! Now I can see, how comments can make a blog post more valueble and readable !! ...nice comment wesner...exhaustive.

[Mr Auditory]

Come on guys, C# and VB do the same crap 99.99999% of the time. C# is popular in order to stir up the market and allow the programmers that truely are GOOD at their field to land jobs over guys that don't know squat.

And I prefer VB, it's easier to read even though I LOVE C and started years ago in C++ for Borland. One thing Lhotka did say that was right on was about how well DEC nailed it back in the 80's. That machine was bulletproof.

later