While I agree with pretty much everything prole writes,
my overall assessment is very different: I love VB.NET.
This is mostly because most of what in the writeup looks like
a criticism of VB.NET is neither a bad thing nor specific to VB.NET.
Some examples.
-
MyBase designed to make you feel like a five-year old?
-
As prole clearly states, the concepts of MyBase and Me are not
specific to VB.NET; they are common to most object-oriented languages,
including Java, and their common predecessor, Smalltalk (1975), which
knew them as self and super. Now Smalltalk was in fact designed to
be a programming system that five-year olds can use, so MyBase is indeed
a concept in VB.NET designed for use by a five-year old.
The unstated assumption, however, is that this would be a
reason to shun VB.NET and prefer Java instead.
Java has the exact same concept. It just uses a different name
for it.
-
How Microsoft convinced so many people that
You can do x without writing a single line of code!?
-
This was what Smalltalk set out to do, its single great innovation.
To programming language specialists like you and me, object oriented
programming means language features such as inheritance, polymorphism,
methods and messages, up to and including the MyBase concept.
To Alan Kay, one of the Smalltalk inventors, it means putting programs
together by direct manipulation of user interface objects. Yes,
Microsoft's programming tools, which take great effort to support this
approach, have managed to convince very many people that the approach
actually works; what is more, the many applications produced with them
constitute proof. This is hardly surprising, since it rests on a great
deal of solid research, performed by the Smalltalk team and those who came
after them, including Microsoft. There is nothing factually
wrong with the remark that Microsoft convinced many people to put
software together this way; what is wrong is the implicit assumption
that other object-oriented languages or tools are somehow to be preferred
for that reason. It is like saying: I love E2, except that it's so easy
to contribute to. Furthermore, there is nothing VB.NET specific about
this criticism: Microsoft's tools support other languages such as C#,
managed C++, J#, C++, VB6, JBuilder does it for Java, the
Smalltalk system did it in the seventies, and any modern IDE
for any language must do it if it wants to be successful.
-
Keywords
-
As prole already guessed, most of them were taken from VB6. This is
hardly surprising, since VB.NET is nothing but C# for VB6 programmers:
its syntax is as close to VB6 as possible, and it comes with a whole
array of predefined functions that correspond to VB6 equivalents;
supporting the VB6 keywords was a design goal.
The need to stay close to VB6 also produces silliness such as the
"q"c character denotation syntax. Again, proles comments
are right on the mark, but what is the complaint here? These features
were designed for VB6 programmers; if you don't know or like VB6, VB.NET
wasn't meant to be used by you - use C# or some other .NET
language.
-
Wrapper classes
-
If prole needs to make a primitive type a little more flexible,
she can write a wrapper class for it. If Harry wants to make the
same primitive type a little more flexible, he can do that, too.
He will. And I will. And any other programmer will. Wouldn't it
be nice if the language automated this process so we could actually
save some work and share the same wrapper classes,
be convinced that they are correct out of the box, and so forth?
That is what VB.NET does. Except that it is actually .NET which
does it, so all languages that compile to .NET support this,
including VB.NET and C#.
-
Structures
-
The same is true for structures, a compromise between
value types and objects. I don't like them any more than prole
does, but they are a .NET feature.
Good barking, but VB.NET is the wrong tree.
-
Statement separation
-
VB.NET does have a statement separator: :.
In fact, it has two: newline is the normal one.
I wouldn't use anything else:
putting multiple statements on the same line is poor coding style.
Teach a writer how to use layout, and he might be read one day.
If C or C# had had the nerve to apply such an advanced concept to
their if statement, they would have saved us from a whole
category of bugs. Of course, there is such a thing as job security.
-
Whitespace-dependent &
-
OK, so the compiler isn't sure how to read a& b,
since a& is a valid expression, and has nothing to do with
string concatenation. The ternary operator looks like a function:
IIf. VB6 compatibility strikes again.
-
No ++
-
Wait a second - being able to mistype a++ + b
as a + ++b is supposed to be a good thing?
Sure, C's ++ operators made sense, because they were
in the PDP 11 instruction set.
I don't think VB.NET is used much on the PDP 11.
-
Sub versus Function
-
I don't know about you, but when I declare a function in C, C++,
or Java I have to say whether it returns void or not. What does
void mean, anyway? It means that the function is really ... you
guessed it, a subroutine! Sure, understanding void makes me feel
like a grown-up; I was taught programming in Algol 68, the language
C took it from, and Algol 68 has a need for void, since it has a
type system in which functions are regular type constructors. In C
on the other hand, void is little more than an excuse to cast
function arguments to void * that the programmer can't be bothered to
type correctly. I prefer VB.NET, which supports properly typed function
arguments in the form of delegates.
-
Conditions
-
In programming languages, the evaluation of arguments
of logical expressions can have side effects, and takes time,
so evaluation order
matters; in standard predicate logic, it doesn't, so logic isn't any help
in deciding in which order evaluation should happen. Always evaluating
left to right, like Java does, seems to be the best approach, but many
programming languages, like VB6, require both arguments to be evaluated.
VB.NET, thorough as it is, offers both: And
and Or preserve VB6 semantics, while AndAlso
and OrElse are for the rest of the world. Run FxCop to
get the list of Ands and Ors to replace.
-
Casting
-
Indeed, VB6 programmers like their type conversion functions
such as CInt, CDbl, so it is no surprise to see CType for
performing a similar conversion. To just cast, use DirectCast.
In summary: every single point raised is a valid issue, but none of
them represent specific
VB.NET concepts or shortcomings; yes,
some of these concepts turn out to work for the five-year olds they
were designed for, and yes, that eats into your
job security. Let's all
go back to
fixing buffer overflows in string operations.