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++…
Hm. I was out doing random bits of consulting using Access and VB as my plaforms of choice during the VB4 through VB6 heyday, and more than once I lost business on the grounds that "Microsoft doesn’t use VB internally because it’s a toy language". Maybe that attitude didn’t make it back to Redmond but it was sure out there in the field. This notion that VB isn’t good enough for Microsoft’s own use has been around for a long, long time – and exploited as shameless FUD by some topheavy consulting houses, too.
Maybe you should just start writing your samples in IL. After all, that’s the *real* language. 😉
Although I’m a C# bigot, I’m generally thrilled with VB.NET. Thrilled that it is on a level playing ground with other .NET languages, and has access to the same full richness of the CLR and framework that C# has.
My biggest problem with VB6 was always that once you tried to go outside the VB6 box, things got really nasty really fast. At least now if I ever am forced to write VB code (or port our existing VB6 code to the managed world), I know that I won’t be limited in what I can accomplish by the language.
Thank you for this, Paul.
Among the VB programmers I know, however, the perception that VB is a second-class citizen within Microsoft stems from the fact that VB6 code won’t compile in VS.NET without significant modification. The VC++ team, on the other hand, made a big deal about its "IJW" technology: Just open your VC6 project in VS.NET and recompile; "It Just Works!" This tells VB programmers that Microsoft considers its C++ code assets more valuable than our VB assets.
It’s encouraging that Microsoft is now using VB for internal development; perhaps internal developers will raise a bigger stink the next time the VB team considers breaking changes to the language. Unless and until you make it MUCH easier to bring existing VB code forward, however, I’m afraid you’ll continue to have a perception problem among VB developers.
Interesting point of view! Let’s follow that to a logical conslusion, shall we?
It’s fairly easy to see that Microsoft’s new AntiSpyware product is written in VB6. How well did that go through the migration wizard? Did you realize a 95% savings in conversion effort, as we’re told to expect?
You _are_ planning to convert it to VB.NET before RTM, right? I mean, you don’t want to spoil a perfect track record and release a shrinkwrap product using Classic VB, do you?
Pingback: Lorenzo Barbieri @ UGIblogs!
Weren’t a lot of the wizards in VS 6.0 and VB 5.0 written in VB? You can argue whether or not the wizards are important to real developers. But I think it showed that Microsoft understood VB’s place in the Visual Studio environemnt. You don’t write an OS in VB, you write useful applications and components in VB.
The biggest problem with all the arguments is that they treat C# and VB.NET as if they are wholely indepenent languages. They both compile down to IL, which is really the official language of the CLR. As Kevin said.
Paul, this post was great. I have programmed in VB4/5/6 for as long as I can remember now. Like you said, in VB6 the nice thing was that it made so easy to do most of the stuff you need (especially with the growth of the COM component vendors) that made windows programming very accessible to the hobbysts while still being powerful enough for many enterprise solutions.
I think that the difference with the introduction of VB.NET was that it is not as easy to get started with as VB6 was. VB.NET is in many ways comparably complex to C#. I don’t think VB.NET is as attractive to the new programmer as VB6 were. It’s obviously the right choice for someone coming from VB6, but for someone trying to learn .NET without previous programming experience, the amount of documentation and articles (not just written by MS) written in C# can really make lots of people to turn away from VB.
My hope is that after each new release VB keeps getting more and more productive, even if that means not implementing all the CLR power. I don’t want to get hardcore VB guys to be upset with the idea of not having the same features as our curly-braced sibling… productivity is one of the most important features in a professional language IMHO.
>>Several of the libraries in the CLR 1.x were written in VB
A genuine question stemmed from curiosity:
Which System.XXX classes are written in VB in v1.x?
Did you guys see this survey Dino referenced?
Based on these horrendously poor migration numbers, it’s clear that only a small fraction of the giant VB developer base is migrating to VB.NET.
My concern is, I am starting to see much evidence of a "sea" of C# *programmers*. (No pun intended.) The VB world always had that one major strength: numbers. Sure, snooty C programmers may have thought VB6 was a toy language, but who could argue with millions of productive developers? Now, in the .NET world, I’m questioning whether we even have that!
Bottom line, if you want the most online code samples, if you want the best support from Microsoft, if you want to contribute code to the most significant .NET open source projects, you want C#. Now WE, as VB.NET programmers, are in the minority.
And that hurts.
Don’t get me wrong, I’ll still do VB as I have for 10 years, but the hard evidence of this ongoing change is difficult to deny.
Hey, this is great. Tell me again how this new philosophy inside Microsoft helps me migrate my code?
Jeff:> Bottom line, if you want the most online code samples, if you want the best support from Microsoft, if you want to contribute code to the most significant .NET open source projects, you want C#. Now WE, as VB.NET programmers, are in the minority.
Eh? This is nothing new and has been the case since VB came into being. It’s just now that the name of the language has changed, its no longer just C/C++, its C/C++/C#. There are zillions of C/C++ samples online, Microsoft being a major in C/C++ gave those programmers the best support and if you wanted open source the number of C/C++ apps can’t even be counted. Now just because C# has joined the equation, doesn’t mean VB folks are a minority. The VB community was huge when the C/C++ legacy was in force, it remained big when Java entered the game, and there’s no reason to think 6 million or so developers will magically vaporise just because the seemingly oh-so-mighty C# has entered the game.
This will remain true no matter how many cute stories some VB defectors post about going to C# and never looking back.
And some of the C# developers gloating over the bizarre notion that C# is somehow infinitely better than VB.NET because MS uses it more, should take a look at the BCL code in the SSCLI sometime. About 90% of the code in there can be written in VB.NET easily. The truly hard core stuff like the jitter, metadata import/export, assembly loader, etc is *still* done in C/C++.
Jeff:> … And that hurts. A lot.
Thing is though, why on earth should it? Do we VB programmers magically become less productive? Does VB become lesser in any way? Do all those apps people have written out there magically stop working? Do the thousands of books written on VB get burnt or something?
I think we all need to do a lot of soul searching into why we use the languages we use. This C# evidence this, VB toy that blah blah is really getting old.
If you (and I use "you" in the general sense here) woke up tomorrow and found yourself to be the only language VB programmer left, would you still code in VB? The answer to this question shows whether one is a mature independent thinker or just a sheep following the crowd.
Paul Vick:>…the commonly heard refrain that C# is the “official” language of .NET (and Microsoft) because so much of the frameworks are written in C#.
LOL, and what some of the C# programmers who propagate this vitriol don’t realise, is that they are doing themselves a great disservice. Trumpeting the framework as the hallmark of C# prowess is highly foolish given some of the unbelievably brain-dead things going on in namespaces like System.Windows.Forms and System.Collections.
If I were in love with C# as a language I’d be very very terrified about it being Microsoft’s "official" language. If Microsoft keeps doing business as usual, then every one of its failings will be a little thorn sticking in the side of the C# community.
And when another one chimes in about how C# programmers are supossedly smarter than VB programmers, I’ll merely point at the System.Windows.Forms.Control class and have a very good laugh.
"C# is the language of .NET."
– Microsoft employee, MSDN, November 2000 (since removed from MSDN…)
The arguments I usually give against VB are:
* The framework is written in C# and therefore C# is tested more thoroughly. This is evident if you look at the number of bug fixes VB.Net has compared to C#.
* VB.Net produces larger executables (30% larger on average)
* VB.Net doesn’t have XML comments (yea, I know, whidbey)
* VB.Net is slower if you use a micro benchmark with strings…
* Incremental compilation in the IDE basically prevents development if you have a large project
and arguments against C#:
* It doesn’t have exception filters
* It doesn’t have parameterized properties
* It doesn’t have late binding
Now, these points change somewhat with Whidbey, but having seen the power of anonymous methods and iterators, I’m sure I could formulate a powerful argument.
RichB:> The framework is written in C# and therefore C# is tested more thoroughly.
Now that’s a more plausible argument than the "it is microsoft’s official language" rhetoric.
RichB:> …This is evident if you look at the number of bug fixes VB.Net has compared to C#.
Granted there will be bugs in the whole shebang – framework, IDE, compilers, etc. I’ve managed to get the VB.NET compiler to choke several times, but have yet to encounter a show stopping bug. In the times when I did choke the compiler, I didn’t lose any work, I was merely asked to save it and restart the IDE. Is your experience different?
RichB:> VB.Net produces larger executables (30% larger on average)
This may be so but I find the figure you give to be highly suspect. Can you point me to an example please so I may see this feat for myself?
RichB:> VB.Net is slower if you use a micro benchmark with strings…
Benchmarks can be written and designed to prove anything you want. I have a parser for a VB-like language written in VB.NET and it handles 250,000 lines of code *per minute* on P3 998Mhz machine. If one knows what they are doing, performance in VB is a non-issue.
RichB:> Incremental compilation in the IDE basically prevents development if you have a large project
That’s an implementation issue not a language issue.
RichB:> …but having seen the power of anonymous methods and iterators, I’m sure I could formulate a powerful argument.
Yeah and prove what exactly? Do you really have that little confidence in C# that the only way you’ll keep using it is if you can formulate some vacuous proof that its better than VB?
If C# is your language of choice then just do all of us a favour and use it to deliver value to your client and pay your mortgage. That’s a much more lucrative use of your time than formulating trivialities which to be honest, no one really cares about.
Pingback: Richard Clark
Pingback: Brad McCabe's WebLog
Answers to some random questions:
* In CLR 1.x, the Microsoft.VisualBasic part of the CLR was written in VB. This is expanded in CLR 2.0 and I believe some other namespaces are now affected…
* I’d be interested in looking at the data that VB executables are "30% bigger on average." Our internal data is that executables that do the same things compile to the same amount of code using both compilers. So either there’s a problem with the tests that you’re quoting, or we’ve missed something in our own tests.
* To the best of my knowledge, the C# and VB compilers have not had different rates of bug fixes.
* I’d also be interested in looking at the micro benchmarks on strings. I don’t put much faith in micro benchmarks (because it tends to be the macro things like memory allocations, I/O, etc. that are the real performance issues), but I suspect again that the tests are measuring differences in functionality rather than differences in performance. VB gives you more functionality with strings than C#. If you strip down the functionality, the IL is the same…
RichB:> VB.Net produces larger executables (30% larger on average)
Eric Mutta:> This may be so but I find the figure you give to be highly suspect. Can you point me to an example please so I may see this feat for myself?
Compile every single QuickStart SDK exe in both csc and vbc. Discard the projects that are only written in a single language. Generate a CSV of the file sizes. Import into Excel. I’ve looked again at the charts I created and it’s more like 20% rather than 30%. However, a significant number of the 226 exes were 30% larger.
Eric Mutta:> Do you really have that little confidence in C# that the only way you’ll keep using it is if you can formulate some vacuous proof that its better than VB?
Eric Mutta:> If C# is your language of choice then just do all of us a favour and use it to deliver value to your client and pay your mortgage. That’s a much more lucrative use of your time than formulating trivialities which to be honest, no one really cares about.
That’s totally uncalled for. I programmed solely in VB from 1995-2000 commercially, so I expect my opinion is valid. In fact, my comment merely summarized a document I was paid to write by a client back in 2002 on the merits of C# and VB.Net. My opinion of VB is that it is a very valuable language which is too much like C# and should be a lot simpler. I’m encouraged by Paul’s comments about possible future directions for VB.Net Orcas.
PaulVick:> To the best of my knowledge, the C# and VB compilers have not had different rates of bug fixes.
I remember seeing a list of bugs fixed. Possibly in release notes for a service pack. I’ve searched, but not been able to find these notes. The best I can come up with is KB articles:
C# Bugs: 814824
VB Bugs: 814602, 819349, 831489, 820655, 814605, 814603
These are from a KB search for kbcompiler kbbug for VB.Net 2003 and C#.Net 2003. 2 of the VB bugs are IDE related. I know this isn’t exactly overwhelming, but then I can’t find the release notes I wanted.
PaulVick:> VB gives you more functionality with strings than C#
I appreciated that when I created the benchmark and inspected what was going on. Depending on your point of view, it is either fortunate or unfortunate that people developing in VB do not tend to realize this. I’ve written programs in MSIL so I tend to spend a fair amount of time in ildasm.
RichB:> Compile every single QuickStart SDK exe in both csc and vbc…
Did you take into account the differences in how both languages implement the same features? Did you consider the fact that vbc generates code to check for integer overflows? code to initialise variables to 0? did you build both versions in release mode? do the samples themselves even implement the exact same functionality?
Getting an exe that is 20% larger just doesn’t make any sense if you ensure that the above things were taken into consideration. And if you tested 226 exe’s I highly doubt the same rigour was applied throughout the comparison process.
RichB:> That’s totally uncalled for. I programmed solely in VB from 1995-2000 commercially, so I expect my opinion is valid.
No, what’s totally uncalled for is:
a) your insistence that C# is somehow more superior than VB (something glaringly obvious in the undertones of your initial post) when anyone with a half-way functional brain knows that the languages are virtually identical.
b) the idea that just because you can cook up a list of the pros and cons (naturally biased towards C#), you automatically and irrevocably prove your point.
c) the fanciful notion that just because you once programmed in VB, you are automatically immune from a backlash when you attempt to formulate empty claims regarding its inferiority relative to your current language of choice.
RichB:> In fact, my comment merely summarized a document I was paid to write by a client back in 2002 on the merits of C# and VB.Net.
Well money talks doesn’t it? Let’s see. You stopped programming in VB back in 2000. Here you are trumpeting C#. In 2002, after you’d used C# for a while, a client comes and *pays* you to compare the two. You cook up a report that naturally favours C#. Classic behaviour of a VB defector who’s trying to justify their existence in the C# world.
RichB:> My opinion of VB is that it is a very valuable language which is too much like C# and should be a lot simpler.
What logic is this? You once programmed in VB, then you switched to C#. Here you indicate that VB is important and should be simpler than C#, by which we are to understand that you think C# is too complex. So why in the world did you switch to C# in the first place?
RichB:> Depending on your point of view, it is either fortunate or unfortunate that people developing in VB do not tend to realize this.
Typical blanket statement with the same old superiority undertones. Which VB people are these that you refer to?
> If you (and I use "you" in the general sense here) woke up tomorrow and found yourself to be the only language VB programmer left, would you still code in VB? The answer to this question shows whether one is a mature independent thinker or just a sheep following the crowd.
It’s ironic, because this entire statement runs counter to the spirit of VB. We’d have to be the crappiest mature independent thinkers ever if our "radical" language choice is VB.NET! The choice of language, for VB developers, is driven by purely pragmatic reasons. We use VB because we WANT to be part of the herd.
VB developers are smart: they realize there are certain advantages conferred when you’re moving with the herd. Part of what makes VB so productive– a LARGE part of it– is the market potential of (what used to be) such a large group of developers.
Choosing VB.NET, in the current state of the .NET world, *is* unusual. And that is fundamentally at odds with the design ethic and history of the language. In the "real" VB world, you could cherry pick the best third party tools from huge catalogs. The market is so large, vendors would be crazy not to offer a VB-specific version of their product. But in the current VB.NET world we’re living in, there’s no VB.NET version of Resharper*.
And this isn’t limited to third-party tools. Code samples. Enterprise library. Open-source projects. You name it, it’s easier, faster, and better in the language that is the most popular. Which is something VB used to have going for it. Now, not so much.
I guess I’ll just have to buckle down and enjoy my new mature, independent thinker’s language. I might as well stop by the Apple store and buy a Mac while I’m at it.
* Yes, there will be a VB Resharper for 2005. But the point remains: all we can get is scraps from third parties? How the mighty have fallen, my friends.
Jeff:> It’s ironic, because this entire statement runs counter to the spirit of VB.
You misunderstand my point. Quoted in context, the herd I’m referring to is *not* the VB herd, but the C# herd and the sheep in this case are these VB defectors we see rambling on on about the "C# evidence" in an attempt to justify their illogical decision to move to C#.
Jeff:> Choosing VB.NET, in the current state of the .NET world, *is* unusual.
Go on. Let’s hear you reiterate the same vitriol often given as justification for that assertion.
Jeff:> …But in the current VB.NET world we’re living in, there’s no VB.NET version of Resharper*.
Oh, shock! horror! An *entire* community falls due to the absence of one tool. Hundreds of thousands of VB books are burnt and CNN reports C#-powered UFOs vaporising the masses of VB developers out there.
Jeff:> And this isn’t limited to third-party tools. Code samples. Enterprise library. Open-source projects.
Did you even read an *ounce* of what I asked about on the 3/2/2005 at 10:29?
Jeff:> …You name it, it’s easier, faster, and better in the language that is the most popular.
You are either delusional, blatantly ignorant or both. Just keep making these blanket unqualified assertions if it helps you sleep better at night.
Jeff:> Which is something VB used to have going for it. Now, not so much…I guess I’ll just have to buckle down and enjoy my new mature, independent thinker’s language.
*Yawn*. Be sure to let us know when your IQ magically increases because you now have to use semicolons and curly braces. Hell, with the higher salary you’ll be earning, maybe you can even purchase movie rights and get your 60 seconds.
Jeff:> I might as well stop by the Apple store and buy a Mac while I’m at it.
I can already hear Gates lamenting the loss of one yoctogram of his market share.
Seems like people are missing the point I think Paul was trying to make about the specific issue which is raised with respect to the .net framework and C#… i for one appreciate the different point of view we’ve been given which suggests that VB.net is a more popular choice at microsoft than ever, which goes some way to dispelling the myth.
Personally I was always happy with the typical reason given and never cared much for this pro-c# argument, which was that most microsoft employees come from a C/C++ background. But Paul certainly put a small twist on things.
As for the VB.Net vs C# thing…I’m clearly not a fan of the overall direction VB.Net is taking, but only a fool thinks that the language matters more than the person writing it. Give an idiot a "better" language and his or her code will still suck the big one. It don’t matter if your user C# or VB.Net, if you use the SQLDataSource chances are ur violating basic layering methodology. DataSets aren’t the most object oriented way of representing domain logic whatever language you prefer. FOOLS I say….
Did someone in here kill Eric Mutta’s dog? Also, could you possibly dial down the rage-o-meter a few notches?
Anyway. My point is that there’s a lot of hard numbers* to support the assertion that VB is nowhere near as popular in the .NET world as it was as a standalone dev environment. And that’s precisely why a lot of people chose it back in the day: popularity breeds productivity.
So I guess we’ll see what happens. Maybe Microsoft can do a better job of driving adoption somehow.
* Don’t take my word for it. Just do some searching on CodeProject and count the results.
Jeff:> Did someone in here kill Eric Mutta’s dog?
Yeah, that silly one that comes on WinXP’s Explorer search window. How many years do people get for committing dogicide these days? :->
Jeff:> Also, could you possibly dial down the rage-o-meter a few notches?
Gladly. I’m not usually this acidic but there’s such a thing as people taking it too far. Could you dial down the following please:
Jeff, I’ve been to your blog and find a lot of what you have to say on there to be interesting, but some of the things you are saying on here are just not right.
I mean consider this CodeProject thingy you mention. Since when did that become representative? And how is that different from how the state of affairs has been since VB’s inception? You want representative data, you go to SourceForge. C/C++ beat the pants out of all the other languages, VB included. This has been the case for *years* and VB has still remained popular throughout that time. Do you seriously believe that just because C# has entered the game this will change?
Java came before C# and guess what? Sun is *still* trying to come up with tools, initiatives and what have you, to try and entice the masses of VB developers that still remain. There’s as much chance of that happening as there is in the common house fly winning a Nobel prize for contributions to quantum chromodynamics.
What’s much more likely is that in 3 to 5 years time there’ll be a new language similar enough to VB6 but not in the spirit of .NET, and that is what will finally convince those VB6 people still holding back to move forward.
Meanwhile, don’t let these cute stories from some VB defectors and whatever "evidence" they come up with worry you. Now if you’ll excuse me, I’ll get back to that interesting article I was reading on your blog 😉
Pingback: Coding Horror
Pingback: Richard Clark
I have been a VB.NET Fan since the day it was born. As of VB-2005 – upgrades – I’m a few bucks poorer than I was a few years ago. I think I’ll stick with VB-2005 for awhile. I realize that 2007 is already on the burner and with all of these flavors of NET – who knows when M$ will get it right.
Although I’m a fan of NET – the entire programming language VB-2005 is a Joke! (IMHO). The software is so bloated and rittled with numerous bugs – (too many to list) – that you’d think the VS-TEAM would have learned from the past via Service Packs – instead of pumping out new version every year! Oh – and we have Net 1.0, 1.1, 2.0, etc…. when does it end.
Why do I stay with NET – even though I think it’s a Joke? Because somewhere down the line – the VS-TEAM will adventually get it right. Not by shear luck or because the TEAM has hundreds of bright minds and cheery eyed faces. It will be because they have thrown everything at it – and will know what works and what doesn’t by the time they get there. They will have heard the whines and cries that fill the NET FORUMS around the world – as I sit back and sip on my cup of tea laughing: See – I told you so!
VB 2005 is, as well as the previous Net Versions – paved the way – with the support of us die-hard-programmers, who paid the full price for these upgrades and subscriptions fees! Where are the Real World Net Business Applications? Name them – because I can only find Net Controls, Net Conversion Tools as well as Net AddOns etc… Who is making their first $Dollar with VB-2005? I suspect very few indeed!
I make more money showing companies how not to use NET (at this point in time) (If it works – don’t fix it) – because there is no proof that your NET Application today – will even work with tomorrows version.
All of our Applications that have been used over years – that are continually working – and will work for many years to come – don’t need NET. However, we can wait while Net gets it’s act together – become more stable – lean – reliable – before it can be trusted!
VB Net 2005 must have been programmed by a C# programmer. LoL
I have been using VB from version 1.0. Heck I even used VB-DOS for quite some time.
I have been using VB6 since the first day it was released. I still prefer the SDI interface which has been around forever but seems to have been misplaced by Microsoft.
I have tried all the various incarnations of the VB.not languages and have not found a single reason to upgrade. In fact, not only are there no good reasons to upgrade, there are a lot of really good reasons NOT to. Heck it took Microsoft until VB2005 to put back the most important debugging tool created for any language (stop, edit, continue).
I work with very large groups of VB programmers and we all still use VB6. No one asked, ever, for any of the "features" put into the VB.not languages. The one, single thing we have always asked for, faster program execution, still hasn’t been addressed. Yes, we have all the code feature clutter of C++ now, but the apps we compile do not actually run faster. They’re slower if anything. A 50,000 line VB6 commerical application I wrote, took weeks of uprade work to make it compile in the first .Net edition of VB and it executed at roughly half the speed. It was a disaster.
If you’re making stand along windows applications of any sort, there simply is no reason to upgrade to any portion of Visual Studio 2005.
And I really don’t care if the C++ programmers look down upon the VB developers of the world. I make just as much money as they do. And as a private contracter, I probably made more. Why? Because I was able to deliver to customers software as robuts as any developed in C++, but do it in half the time.