This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: When a step forward looks like a step backwards...
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
One of the things that would be amusing if it wasn’t so annoying is the way that a step forward can be perceived by people as a step backwards. Case-in-point: the commonly heard refrain that C# is the “official” language of .NET (and Microsoft) because so much of the frameworks are written in C#. Scott has a pretty good set of arguments against this canard framed in the context of the present day, but the thing that I find really ironic is how all this hand wringing is so woefully ignorant of history and how it is backhanded evidence of the essential correctness of the strategy of moving VB to .NET.
To wit: can anyone tell me, for the ten years (give or take) between the introduction of VB 1.0 and the introduction of VB .NET 7.0, how much of the Win32 APIs or the COM APIs were written in VB?
Of course the answer is: none, to my knowledge. In fact, the VB team itself did not use VB in any meaningful way in its own product. The VB runtime functions were all written in C/C++. The VB forms package was written in C/C++. All of the VB controls were written in C/C++. Beyond the VB team, every major Microsoft product and operating system was written using C/C++. Every. Single. One.
Now, during that time was there massive hand wringing about how “C++ is the official language of Microsoft” and how “I’m going to use C++ over VB because that’s what Microsoft uses”? Of course not. Why not? Because VB and C++ lived on two almost completely different planets. C++’s great advantage was that it had full and easy access to the entire power of the platform; it’s greatest disadvantage was that you had to do every damn thing for yourself. VB’s great advantage was that it took care of a lot of the nitty-gritty for you and make programming easy; it’s greatest disadvantage was that it didn’t have full and easy access to the entire power of the platform. (Instead, you often had to turn to advanced books or gurus to accomplish what should have been simple tasks.)
The reason why there is so much angst about this question now is because, for the first time, we’ve accomplished a relatively level playing field on .NET. VB is no longer limited in what it can do with the platform – if you need to customize what you’re doing with WinForms, for example, you have pretty much an unlimited ability to do so. And C# and C++ (using their CLI binding) now can take advantage of all the cool automatic features that VB users have been taking advantage of for decades.
So the bottom line is: as far as an “official” language goes, things are the same as they ever were. Actually, that’s not true: with the introduction of VB .NET, for the first time Visual Basic is being used in a meaningful way inside the company. Several of the libraries in the CLR 1.x were written in VB, and there will be even more VB code in the CLR 2.0. So, ironically, VB is actually much more of an official language at Microsoft than it has ever been, yet the external perception is just the opposite.
Which is why this particular line of argument grates on my nerves like nails on a chalk board. My suspicion is, though, that this erroneous line of thought has mostly been fueled by legitimate problems in the past with the messaging around .NET. What matters to people is not so much what the frameworks are written in, but instead what language we use to talk to the public with. All the hoopla around the new C# language combined with the natural affinity that many MSFT people feel for C-style languages (c.f. the last few paragraphs) meant that, for a while, things like talks, samples, and all manner of other code displayed publicly skewed heavily in the direction of C#. This was a mistake, and one that we’ve been working hard to correct – we’ve been very active in educating people internally as to how their language choice for example code can be perceived outside of the company. We’ve made a lot of progress, although there’s always more work to be done.
As for the whole “what the frameworks are written” in thing goes, maybe we should just decompile the frameworks using Reflector, recompile it using VB, and provide a “VB CLR”… (Note to the humor impaired: this is a joke.) Except, of course, for the non-trivial chunks of the frameworks that are written in C++…
Previous Topic
