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.
End of Article
