Comparison of C Sharp and Visual Basic .NET

#

The original .NET Framework distributions from Microsoft included several language-to-IL compilers, including the two primary languages: C# and Visual Basic. There is heated debate among the greater .NET community about which language is better in general, or for specific purposes. Below is a comparison of the two languages.

Compatibility

It should be noted that all .NET programming languages share the same runtime engine, and when compiled produced binaries that are seamlessly compatible with other .NET programming languages, including cross language inheritance, exception handling and debugging.

No second class languages

One of the main selling points of .NET has been its multi language support, and the concept of "no second class languages". That is, all of the various Microsoft languages should have the same level of access to all OS features, and all expose the same level of power and usability.

Visual Basic has been significantly updated from its VB1-6 days. Older versions of VB were [Object based]], that is to say not fully object-oriented, had less access to API functions, and had many other limitations. In .NET, most of these limitations have been removed, while keeping the bulk of the ease of use VB was known for. VB.NET is fully object oriented, and has full access to the .NET framework. C# has taken concepts from other languages, notably Java and Delphi, combined with a syntax similar to C and Java.

Culture

While there are some technical differences between the languages (detailed below), there are also many differences in the cultures of the developers who use them. Many .NET developers came from either the VB environment, or the C/C++ environment. These two groups had very different coding standards, best practices, etc. Many of these paradigms came from language or IDE features. While the historical reasons for these practices are no longer applicable in all cases, the culture differences remain.

Visual Basic .NET culture

VB historically was a RAD tool, as well as a tool that was usable by untrained developers, or management. As a result of this wider user base, VB allowed for many shortcuts and ease of use features. These features allowed for the uninitiated to create code, but also contributed to maintenance and debugging issues. Examples of the shortcuts allowed in VB

• Optional declaration of variables
• Optional Weak Typing using late binding
• Optional Parameters

C# culture

C# developers tend to be prior C/C++ developers, or Java developers. C# is syntactically very similar to C and Java, the IDEs and command line tools work very similarly, and the culture is the same. Also, C# inherited quite a bit of its style and culture from the Delphi/Object Pascal programming language.

Language features

The bulk of the differences between C# and VB.NET from a technical perspective are syntactic sugar. That is, most of the features are in both languages, but some things are easier to do in one language than another. Many of the differences between the two languages are actually centred around the IDE.

C# features advantages

• Supports unsafe code blocks for improved performance at the expense of not being verifiable as "safe" by the runtime
• Operator overloading (not available in VB prior to 2005)
• Iterators (C# 2.0)
• Anonymous methods (C# 2.0)
• Nullable structures are fully supported with the ? notation (C# 2.0)

Visual Basic .NET advantages

• With keyword for using the same object repeatedly (this feature was intentionally not added to C# [1])
• Named indexers (essentially, properties that take arguments)
• Partial compatibility with legacy Visual Basic code
• The My namespace, which simplifies the use of many framework classes by encapsulating their functionality in a flatter, more accessible structure
• More granularity with exception handling with the Catch…When clause, which allows for custom exception filters
• The Handles keyword allows declarative wiring of events to functions; Imperative (C# style) event wiring is also available.
• Optionally ignore ref/ByRef behavior for passing arguments. (C# requires a temp variable to do this.)
• Optional parameter support is useful when using COM automation. This is especially important when working with Microsoft Office.

Potentially problematic Visual Basic .NET features

VB.NETs supports several syntactic "shortcuts", which exist mostly due to the language's legacy support. While these can be valuable in some circumstances, they are also often a significant source of errors and headaches.

• Optional variable declaration
• Optional strong typing

Potentially problematic C# features

• By default, numeric operations are not checked. This results in slight faster code, at the risk that numeric overflows will not be detected.
• Unsafe code blocks. These allow pointer manipulation which can corrupt memory if not used carefully.

Adoption and Community Support

Both C# and VB.Net have high adoption rates, and very active developer communities. However, C# does have an advantage in terms of the level of community support. While Microsoft fully supports both products, internally C# has higher adoption, and Microsoft provides more examples and performs more live demos using C#. Some of this disparity may be explained by the splintering of the VB developer community - Some VB developers have chosen to not upgrade to VB.Net. It is difficult to compare statistics from search engines since although items of interest on C# can be found by using the search term C# or C Sharp, equivalent searches for VB .Net are complicated by the fact that some articles choose to use the full name "Visual Basic .Net". However for the record:

Examples of the increased community and industry include:

• A Google search for C# returns 115,000,000 hits. VB.Net returns 109,000,000 (August 6th 2006).
• blogs.msdn.com, the blogging site for Microsoft employees, has 31,600 posts that discuss C#, while only 7,720 mention VB.Net (August 6th 2006)
• Technorati, a technology-centric blog index finds 20,930,758 with the term C#, while only 23,377 contain VB.Net (August 6th 2006)
• A Google search for "C#" returns 80,700,000 hits. "C Sharp" returns 4,210,000. "Visual Basic .Net" returns 13,200,000 "VB .Net" search returns 32,700,000 hits. (August 6th 2006)

As counter examples

• Google Groups, a usenet search engine returns 2,050,000 hits for "VB .Net", and 1,410,000 for C#
• Amazon returns 478 hits for C#, and 610 hits for "Visual Basic .Net" (August 6th 2006).

Other Languages

C++/CLI (Formerly Managed C++)

C++/CLI (a replacement for Managed C++) does not have the adoption rate of C# or VB.NET, but does have a significant following. C++/CLI syntactically, stylisticly, and culturally is closest to C#. However, C++/CLI stays closer to its C++ roots than C# does. C++/CLI directly supports pointers, deconstructors, and other unsafe program concepts which are not supported or limited in the other languages. C++/CLI is used for porting native/legacy C++ applications into the .NET framework, or cases where the programmer wants to take more control of the code; but this control comes at a significant cost of ease of use and readability. Many of the automated tools that come with Visual Studio have reduced functionality when interacting with C++ code. This is because reflection cannot provide as much information about the code as it can for C# and VB.net

J#

J# runs a distant fourth in terms of adoption. J# is a language primarily designed to ease the transition of Java applications to the .NET framework; it allows developers to leave much of their Java or J++ code unchanged while still running it in the .NET framework, thus allowing them to migrate small pieces of it into another .NET language, such as C#, individually. J# does not receive the same level of updates as the other languages, and does not have the same level of community support. For example, Visual Studio 2005 supports automatic generation of Unit Tests in C#, VB.Net, and C++, but excludes J#. Microsoft recommends against developing new applications in J#.

Minor Languages

There are many additional languages available for the .NET Platform.

MSIL

As all .NET languages compile down to MSIL, it is only logical that some people code directly in IL. This can be done for performance or security reasons, or just for fun. It is a very common practice to make source changes in the original C# or VB.NET, and then compare the resulting IL, to see what benefits or consequences might result. Coding directly in IL often makes code that is difficult or impossible to de-compile to a higher level language like C#. Either the decompile fails, or the resulting code is not very readable. This is analogous to writing directly in machine code, and then decompiling to C++. It is possible to code an entire application directly in MSIL, but this would be very cumbersome.

External links

• CodeProject VB vs C#
• Cultural differences between C# and VB.NET
• Syntactical differences between C# and VB.NET