DevSource: It sometimes seems as though Visual Basic is the Rodney Dangerfield of Microsoft languages: "it don't get no respect." Presumably, the Enterprise Library to which you refer in your blog (which doesn't support VB) is yet another example. Is this an accurate perception about VB? Why do you think it exists (even if it isn'tso)? And what would have to be done to address the problem?

Gee, I'm glad we got to this dagger-in-the-heart question so quickly....

Before we get into this, though, please let me clarify the issue about the Enterprise Library. The problem is not that it doesn't support VB, because it definitely does. A .NET compiled code assembly can be used by code written in any other .NET language. So if all I want to do is use the Application Blocks of the Enterprise Library as block-box components, everything is fine.

However, the purpose of the Enterprise Library is not to simply provide canned functionality. It has two other fundamental purposes. The first is to show us clear examples of how to implement what Microsoft considers to be best practices for developing in .NET. The second purpose is to allow developers to take these best practice implementations and incorporate or extend them into their application in a way that they seem fit.

Now, while I personally have no problem reading or writing C# code, there are definitely many VB developers who don't have that background. Having only the C# code for the Enterprise Library will make it difficult for them, both psychologically and in reality, to fully understand and customize this code. I was particularly upset at this situation, since it is essentially a step backwards; in the previous versions of the applications blocks, at least most of them were available with both C# and VB source code. To be fair, the Enterprise Library does come with extensive documentation, tutorials, and Quick Start samples, and these all support/promote C# and VB on an equal footing.

Now, back to your original question.... There are definitely many quarters where VB is clearly disparaged and doesn't get the respect it deserves. I remember back to one of the first articles I wrote on VB3 for a local developer magazine, where I said that the biggest obstacle to developing in VB is the psychological one of programming in a language with the word "Basic" in its name. Maybe Microsoft should have changed the name to something else, like V#.

Many people would be amazed at the types of sophisticated applications that have been developed in VB. One of the projects I am most proud of is a project we completed several years ago. It was to develop a Windows-based development and debugging environment for robot applications — kind of like Visual Studio for robot applications. The code was 99% VB6, including real-time serial communications to talk to the robot controller hardware and a compiler for parsing the robot programming language and generating the low-level hardware opcodes. It worked great, and we clearly developed it in a lot less time than it would have taken in C++. In just about any industry you check, there will be impressive, high-end VB applications.

I think that we were making increasingly serious headway against the "real programmers don't program in VB" perception as VB progressed from VB3 to VB6. By VB6, the limitations were few and well-defined, and the benefits clearly appreciated. Unfortunately, things seem to have taken a turn for the worse with the initial release of .NET. This was due to the fact that there was a tremendous amount of noise and excitement around C#, both from Microsoft and outside sources. Everyone wanted to jump on the bandwagon and code in the newest, coolest language. Also, unfortunately, in the early days of .NET, almost all of the samples you would find would be in C# only. And while you could do anything in VB that you could do in C#, since they both used the exact same framework classes and runtime, the VB language itself did fall a bit short of C#, in that it was missing things like unsigned integers, operator overloading, and some other language constructs. (All of these missing constructs have been implemented in .NET 2.0 / Whidbey.)

Let me address what I find as the most irksome, and outright wrong, claim that I hear. I have heard this not only from outsiders, but also from many MS employees themselves! They claim that C# is the serious, better language and the language of the future at Microsoft, since all of the new .NET code being written at Microsoft is written in C#. While it is probably correct that most .NET developers at Microsoft develop in C# rather than VB, it is not completely true. There are a lot of new tools and even framework components that are being written in VB.NET.

But that isn't even the point. The point is that I would expect most coding at Microsoft to be in C#. Why? Because Microsoft is making the same rational (and correct) decision that I recommend to my clients. Since most Microsoft developers come from a C/C++ background, the obvious choice of a .NET language for them is C#. When I get asked about what language to use (as I constantly do), the first thing I do is ask about the background of the developers. That should normally be the main determining factor.

We are just completing a project for a client for whom I previously did some VB work 5-6 years ago. This is a combination development, mentoring, and moving to .NET engagement. He was a little hesitant, since he assumed that I would want to it in VB.NET. Now, while I probably could have convinced him to do it in VB, once I found out that the primary developer that we would be mentoring was experienced in C/C++, I told him that the obvious choice for them was to develop in C# — and that is what we are doing. So the reason most .NET development in Microsoft (today) is done in C#, is not because it is considered to be a better language. It is simply based on the background and experience of its developers.

Finally, let me mention a recent event that indicates that Microsoft is trying to dispel the myth/perception of VB being an inferior language. At the recent VSLive! conference in San Francisco, there was a special "Indigo Day" to sort of launch the new public unveiling of details of the Indigo technology. In one of the Programming Indigo sessions, none other than Don Box himself, sat and wrote his server-side demo code in VB.NET! You are not going to get more hard-core than that. I think that we have seen, and will continue to see, more and more articles, samples, and other information appearing in VB.NET as well as, or even instead of, C#.