Eric points to an editorial from Visual Studio Magazine that I think is really spot-on, although I think the title is a bit of a misnomer.
Patrick is, I think, accurate about some of the whys and wherefores of VB.NET’s history, and about the need to recapture some of what has been lost in the transition to .NET. There’s no question, for example, that not having edit and continue has been a huge loss, something that has been keenly felt within the company as well as without. It’s going to be a major feature in Whidbey and one I’m very excited about getting back. (I’d better be, since one of the things I’m supposed to do is make sure we do edit and continue right. If it’s wrong, my head is going to be one of those on the block…) And there’s even more stuff that we’re working on in addition to that, but we’ll get to that later, I hope…
The only issue I have with the editorial is the use of the phrase “language divergence.” The phrase is problematic because it’s so general that it can mean a lot of things that are not what we’re working towards. For example, it doesn’t mean that VB.NET is going to stop providing excellent support for the platform. It also doesn’t mean that we’re going to try and “dumb down” the language or compromise on the power and flexibility that we afford developers today. What it does mean, to us at least, is that VB is not just “C# without braces.” Our goal is not to just ape whatever another language does, our goal is to server our customers as best as we possibly can. If that means that we do some things differently than C# does, then we’ll do them differently. If that means we do some things the same way as C#, then we’ll do them the same way. Some people (not Patrick) have used “language divergence” as a shorthand for a mindless “not C#” philosophy, which would be incredibly short sighted and is not what we’re doing. Just as C# borrowed a ton of concepts that VB made popular, we feel free to borrow their best ideas right back. Why not, if it helps our customers?
So, in the end, I think the whole “C# vs VB” argument is a non-starter. The real question is: are we doing a good job making your life easier? Are we the best tool for developers out there? That’s the important thing and what we focus on every day.
Do you by any chance support Trackbacks? I find myself linking more and more to your blog…:-) Good Stuff Paul.. Keep it coming…
Trackbacks are coming… I hope!
How about eradicating all differences, converging both languages 100%, and conjoining expertise to deliver the very best in both ease of development AND power & control? It’s kind of like the MS Access and FoxPro products: Why have two? I dunno, it just seems to me to be redundancy without ultimately benefiting the broader programmer base. I have learned VB.NET and ASP.NET and thought it strange that so much page space in the Microsoft Press books were dedicated to dual examples in two different languages. Particularly since so much code was practically identical in both instances. Seems like a waste of time, money, and trees to me. But Gook Luck!
Hopefully Paul can answer, or point to an existing official Microsoft answer, Geoff’s question, but my feeling is that it is one of perceptions. Although many VB experts have moved to C# (as well as a number of others who have seen the similarities and decided to go straight to the language closer to the "bare metal"), many VB users "don’t like curly braces" and "non-proffessional" reasons. (Professional programmers ought to be able to code effectively in any language given a good source of sample code or training, or both.)
Similarly, C++ and Java users wouldn’t "lower themselves" to using VB. (Microsoft only say C# has some of the /best/ features of VB6.)
For the database environments, in addition to perceptions like above, there’s large existing bodies of code (and databases) to support, too. That is, of course, a touchy subject in the VB.NET case…