However it has to be admitted that all of these features are also "new" in C# as well. There are some improvement unique to VB and one is worth discussion as an example of the sort of feature VB needs to be RAD.
It is the introduction of implicit line continuations. Arguably one of the most irritating features of the classic VB syntax is the need to end lines that continue on the next line with an underscore. Now you can forget the underscore as long as the punctuation makes it obvious that you haven't finished the statement.
For example if you start a new line after a comma clearly more is to follow. Start a new line without closing an opening bracket and you care clearly going to carry on writing - or you have just forgotten to close the bracket. Similarly if you start a new line after any binary operator you either are about to continue the expression or you have made a mistake.
You should be getting the idea by now. This approach to line continuation is in the real spirit of VB. It's a great help to RAD if the compiler tries to understand what the programmer is typing rather than the oh so typical -
"missing semicolon at line 14"
error message which always makes me think -
"well if you have noticed that - add the semicolon for me".
All of these, and many other changes are handy extras but there are one or two changes that seem to be in the same category but really they effect the usability of the language far more than you might expect.
Instant objects in VB.NET
As another example of the compiler trying to make life easy consider instant objects.
Beginners often find it confusing that they have to create say a Form class and then an instance of the class. It's perfectly logical but it can be messy with lots of extra confusing names and it's certainly not the way VB 6 did it!
Eventually VB .NET got back to the VB 6 way of doing things so that you can create and work with a form without the need for the me keyword or instantiation.
For example, if you have created a new class called Form1 you can refer to it using statements like
Similarly you can refer to any of the methods or properties defined in the Form1 class as if the class was an object. Of course if you want a second instance of the form you have to create an instance and an instance variable for it using the new keyword e.g.
Dim MyForm As new Form1
Notice that begin able to use a class as if it was an object isn't the same thing as a static class - this is auto instantiation.
What happens of course is that the compiler automatically generates the instance and substitutes a reference to the instance everywhere the class name occurs.
To a C# programmer this sounds messy but to a RAD programmer it's perfectly logical in its own way – why proliferate names when you only want a single instance of the class.
It's to the point and concise.
VB .NET isn't VB?
Visual Basic isn't just C# using slightly different syntax, it is a language suitable for RAD use in the long tradition of Basic. There is a lot of truth in the opinion that it started out like C# but has tried to get back to its RAD roots over time.
As a result it is better than most programmers think it is - mainly because they approach it as if it was just C# or C# with some funny syntax and its unique features tend to be overlooked. For example, how often do you see something like:
Dim Form As new Form1
when there is no other instance of Form1 in use (you can just use Form1 as if it was an object).
The problem is that VB .NET started out as a copy of C# that was syntactically changed to look a bit like VB 6. Over time it has acquired some new C# features and a much smaller number of features that make it more suitable for RAD. However even at this well developed stage VB .NET is no RAD language and the defunct VB 6 still beats it in this role.
When Microsoft ripped VB 6 from its programmers it did not give them an improved version of the language - that is VB .NET was never VB 7 but VB .NET 1.
Even today there is a role for VB 6 in introducing beginners to a language that was quick to get started with and which had just enough expressive power. When Microsoft killed VB 6 there was a rational - everything had to move to .NET but now .NET isn't as relevant to Microsoft's plans. In fact if Microsoft could uninvent .NET it would and why does it support C# and VB .NET at all? These languages had a purpose once - they were ways to get .NET and Windows into every programmers toolkit. This is what VB 6 was before .NET.
There are many programmers who just don't get it. There are better languages than classic VB, there are more elegant languages than classic VB and there is VB .NET which, as it is now VB 15, has to be better than VB 6? All of these are a misunderstanding of the situation. VB 15 is another language loosely based on VB 6 syntax.There is still room for VB 6.
Microsoft didn't improve on VB 6; they killed it off and have spent the intervening time trying to reinvent it.