This week I'm going to focus a bit more on opinion than instruction. (Translation: I'm going to complain about something, but I hope to be constructive in the process.) I recently accepted an offer to become a Visual Basic (VB) instructor for a local university extension. When I got the course curriculum used by my predecessor, I immediately noticed a couple of problems. The first problem was that the topics were outdated for Visual Studio 2005. The second, more important problem was how much time was spent comparing the differences between Visual Basic .NET and VB 6.0 instead of addressing how to migrate from VB 6.0 to Visual Basic .NET. This constant comparison has, in my opinion, slowed Visual Basic .NET adoption and in some cases caused VB developers to transition to Visual C# for .NET development.
The VB community as a whole has tended to focus too much on where VB has been instead of on where it's going. For example, about a year ago, many VB 6.0 developers staged an uprising regarding .NET adoption and the phasing out of VB 6.0 support. Some of the people who participated in this uprising were the same people who had influenced decisions on the way Visual Basic .NET was developed. In some cases, particularly with regard to object keywords, this influence has been detrimental to the VB language.
One basic concept of .NET is that it's an object-oriented (OO) environment. VB, Visual C#, Visual C++, and Visual J# follow an OO paradigm. Most Visual C#, Visual C++, and Visual J# developers are familiar with object-oriented programming (OOP) terms such as "abstract," "constructors," "overriding," "overloading," and "static." However, .NET developers who learn just VB use only two of those key terms: "overriding" and "overloading." The result is that VB developers are left without knowing some key terms that other developers use everyday in community discussions, job interviews, generic programming classes, and other venues.
Having disparate terms isn't just a minor inconvenience. It can cause problems with unfortunate consequences. For example, at InterKnowlogy, I conduct job interviews and have seen how some VB developers need prompting when asked about something like the purpose of an abstract class. It doesn't bother me, but the hardcore Visual C# developers who are conducting the interview with me always seem concerned about the interviewee's technical abilities--an unfair judgment, but one that occurs.
So, as part of my back-to-basics coverage in this newsletter, I want to talk about object keywords. Let's start with the term "abstract." This keyword is common across most OO languages. You can find an excellent definition, which I'm going to quote one sentence from, in the Visual C# documentation at http://msdn2.microsoft.com/en-us/library/ms173150.aspx.
The first line in the definition says it all: "The abstract keyword enables you to create classes and class members solely for the purpose of inheritance." As those with OO experience know, this means that you can't create an instance of an abstract class. You must create your own class definition and inherit from the abstract class to get the class's limited implementation.
So what did the Microsoft VB team choose to use instead of the common "abstract" keyword? They chose "MustInherit." On the surface, "MustInherit" seems like a very clear keyword until you look at the VB documentation at http://msdn2.microsoft.com/en-us/library/aee8f02w.aspx. In the first line of the documentation's Remarks section, you'll find the sentence, "The purpose of a base class (also known as an abstract class) is to define functionality that is common to all the classes derived from it." (Before you write me, I know that technically this sentence is in error because it makes it sound like all base classes are abstract/MustInherit classes.)
The first problem is that VB's definition for MustInherit doesn't match Visual C#'s definition for "abstract." This problem is made worse by the fact that Visual C# uses the "abstract" keyword at both the class and method levels, whereas VB uses a second new keyword--"MustOverride"--at the method level. The second problem is that VB documentation associates the "MustInherit" keyword with the traditional "abstract" keyword to attempt to explain its use. So why did the keyword have to change?
Ideally, all .NET developers should be able to speak a common tongue. In reality, however, .NET developers need to learn both sets of object keywords--the VB keywords and the keywords used by most other OOP languages-- regardless of which language they specialize in. There was a great deal of concern about moving VB developers to OO development, but in this case, hindsight seems to suggest that the Microsoft VB team should have stayed with the commonly used OO terms--it would have benefited VB developers.
So, what can be done to get all .NET developers to speak a common tongue? I think that the VB team should align many of the OO keywords in a future VB release, even if only optionally for VB development. That way, VB developers could start to use and migrate to the commonly used terms. Unfortunately, aligning the keywords won't work in every case. For example, the "constructor" keyword in Visual C# is equivalent to the "New" keyword in VB, but the "new" keyword in Visual C# is "Shadows" in VB. However, the new/Shadows keyword is one of the least-used object keyword in OO development. If everything else were aligned, it would be much less of a distraction when discussing OO concepts across .NET.
