Vb Dot Net Vs Csharp

Note: page renamed from IsVisualBasicPreferredOverCsharpAtDotNet

Is VbDotNet preferred over CsharpLanguage within the MicrosoftDotNet community?

Could it be that there are far more users of Visual Basic who seem to be interested in .NET technology? Or does the construction of the newest version of Visual Basic have a greater potential for integration into the philosophy behind .NET?

The question has been asked by recent attendees at a conference where all the talk seemed to emphasize VbDotNet.

I've spent a fair amount of time with both technologies (and have friends on both teams :-)):

-- DonBox

Microsoft has come out recently saying that VB would not gain all of the future features (such as generics), whereas C# would. All indications, as far as marketing goes, make it seem that Microsoft is pushing C# as the premier language.

In April 2004, sources close to MicrosoftCorporation is offering a talk on generics and VbDotNet is cited as well. Have they got a change of heart? Or is it in the fine print anywhere that say generics for VbDotNet is more limited, has a longer wait time, etc?

From Microsoft's own lips: Visual Basic is now a first-class, object-oriented programming language that includes features such as implementation inheritance, structured exception handling, and free threading. In addition, we've created a new language, C#, as the first component-oriented programming language in the C and C++ family to combine the power of these languages with the functional ease of modern, rapid application development tools.

Notice the distinction applied to each programming language:

VbDotNet - (First Class) ObjectOrientedProgrammingLanguage

CsharpLanguage - (First) ComponentOrientedProgrammingLanguage

Does that mean the two are headed down separate paths?

I wouldn't read too much into this emphasis. It has always been simple to create components in VB and continues to be in VB.NET. VB was not, however, strong on all object-oriented features. On the other hand, it has been historically more difficult to create components in C++. But C++ is already object-oriented. The bit of marketing spiel above is just emphasizing what is changing in the two languages.

With that said, however, I do believe that the two are indeed headed down separate paths in some regard. There is no point for a company to maintain two languages that have the exact same feature set and differ only in syntax.

Are generics, mentioned above, a component-oriented feature? No.

Here's my take. I have spent a lot of time in Redmond with the MicrosoftDotNet group (even turned down a job offer) and I have worked with MicrosoftDotNet now in non-research but production selling apps for two companies. There is no question in my mind on what language MicroSoft favors and promotes in most of the DotNet stuff, and that is CsharpLanguage. That is primarily because CsharpLanguage was designed as a CLR and DotNet language from the start versus the retro-fitting of VB.NET. Also, it makes the best use of the CLR features and is a first rate Component Language. I don't see a lot of attention being paid to VB.NET other than in the VbClassic community, where life will go on as it has. Most of the people on the MicrosoftDotNet mailing list at DevelopMentor and the people I know who are doing MicrosoftDotNet projects are using CsharpLanguage. At the company I worked for before, and the one I work with now, there was no question. Both companies don't do VbClassic period and we went right to CsharpLanguage. There is, in my mind, less and less reason to use VbDotNet. CsharpLanguage in its VS.NET incarnation has the same RAD simplicity of VbClassic and Delphi with the automatic form and the drag and drop controls coupled with a powerful ObjectOriented language and with a much terser and enjoyable syntax. Certainly, VbClassic is popular, arguably the most popular language in the world today, and will never go away. But CsharpLanguage is the current darling of Redmond in my humble opinion. -- sg

On the other hand, the vast majority of code samples at TechEd Europe were in VB, not C#. -- PaulHudson

Look at the audience.

VB.NET is missing a few features that C# has, and C# is missing a few features that VB.NET has, but the differences are minor. There aren't any strong technical reasons for favoring one over the other. The choice depends on your background and existing skill set - if you are a VB developer, use VB.NET; if you are a C/C++/Java developer, use C#.

There is something that can be considered very strong argument in favor of VbDotNet: named and optional parameters. For example, calling Microsoft Office Automation interfaces without named parameters and default values is literally a nightmare. Lately, I saw that VB also supports varargs (they call it parameter arrays).

VB.NET also provides easier late-binding behavior.

C# does support parameter arrays (see the description of the 'params' keyword). And C# has several things that VB.NET does not, such as specifying a greater variety of data types in attribute contructors, being able to write "unsafe" code, operator overloading, etc.

While there certainly may be individual tasks where one language outshines the other, I don't think either is a clear general-purpose winner.

What about the OtherDotNetLanguages? Is C# explicitly preferred over them? If so, will this continue?

It's clear that Microsoft will be favoring C# and VB.NET over the OtherDotNetLanguages, but the others have their place. For example,

Uh. So my choices for .NET development boil down to VB, C++, Java, a thing that's a mixture of C++ and Java (C#) and Java script? Well, that's a great step... round in a circle back to where we already were. Does Haskell have a place? Mercury? Or is it a case of any paradigm you like so long as it's clumsy OO with a heavy procedural accent?

There are places for everything. The OtherDotNetLanguages page offers several alternatives to Microsoft's favored languages, including both HaskellLanguage, MercuryLanguage, and Microsoft's own implementation of SmlLanguage. There is nothing unreasonable about Microsoft's decision to focus their resources toward the most popular languages among their customers. How big a market would there be for Microsoft Visual Haskell .NET?

It's certainly not all roses. .NET is heavily geared toward the somewhat limited conceptulization of OO coming from C++ and Java (and now C#). This makes some languages very difficult to implement on top of it. A more general (and powerful) vm would have been nice; this way, it is more momentum for continuation of this programming style. I can understand why MS would do this, but it isn't *technological* reasoning, by any stretch.

Right. How big a market would there be for "Microsoft Visual Haskell .NET"? A much, much bigger one than for "Haskell". Microsoft have the commercial clout to make a market for any technology they see fit. We know that there are groups within Microsoft who are interested in these technologies, so...

Sure. But .NET is a limiting technology in some ways. It will be very difficult to put some languages on top of .NET, at least "properly", so even if a group wants to do it, it may not be possible...

There is no point for a company to maintain two languages that have the exact same feature set and differ only in syntax.

Actually, there is a point. Some VB developers will resist learning C/Java-style syntax, and some non-VB developers will resist learning VB syntax. You may think that's stupid (and I would agree), but it is true. Providing alternate syntaxes for the same thing encourages acceptance of .NET by everyone. If there was one-and-only-one .NET programming language, the platform would probably suffer.

Care to name some? I am a VbClassic developer, but do all current programming in C#. VbDotNet is not VisualBasic anymore, and I don't want anything to do with it. -- ThomasEyde

One of the long-term effects of DotNet's MicrosoftIntermediateLanguage will be many languages that have the exact same feature set and differ only in syntax. Managed C++, C#, J# and VB are all drifting toward MSIL.

Actually, C# 2.0 takes a number of steps away from MSIL - in the first version, just about everything mapped 1:1 from C# down to MSIL (in a similar way to how C maps down to assembly), but in 2.0, things like anonymous delegates and iterators introduce a fairly large amount of abstraction over the underlying implementation (see: http://www.interact-sw.co.uk/iangblog/2004/02/16/anondelegates).

This can be seen as a good thing, in that choice of language no longer determines what is possible. It may eliminate the stigma attached to users of each language (VB is for dummies who can't write real software; C++ is for anti-social hackers; etc.). However, it will also lead to HolyWar arguments of the form "Your favorite language is no more powerful than my favorite language, so you should use my favorite language."

I suspect that, particularly post-Whidbey and beyond, VbDotNet will start to gain mind- if not immediately market-share as it starts to diverge in capability from C#. To take one aspect, irrespective of one's personal view of the practice, edit-and-continue in VB6 has had a powerful attraction to developers. Adjusting things like off-by-one errors during execution offered a substantial perceived efficiency effect. And VB had got better and better at handling run-time code changes over releases so it presented a perceived major hit when VbDotNet interrupted that flow, whatever the other benefits offered.

Whidbey reintroduces e-and-c for VB; AFAIK, it won't appear in C#, because that community isn't missing something it never had. What I understand of the other scheduled language environment changes in the two languages is that C# is being pushed toward increased capability, while VB is seeking to offer greater developer productivity by delivering more high-level constructs.

FWIW ;)

-- MikeWoodhouse

CategoryDotNet CategoryComparisons

EditText of this page (last edited November 12, 2007) or FindPage with title or text search