Quote Originally Posted by capsulecorpjx
Besides, if it isn't broke (VB6) don't fix it.
They aren't fixing it. It is no longer supported
In seriousness, .NET was not an attempt to "fix" VB6. .NET was an attempt to introduce a portable object oriented software platform, like Java was - except with a slightly wider target audience. VB.NET, while not a successor to VB6, is Microsoft's incarnation of Visual Basic as a .NET language.

If, and here, I stress, I am referring to anyone, your favourite language is VB6, and you loath .NET for whatever reason, and Microsoft because they did not make a successor to VB6 - then you have a pretty narrow minded view and that is not a desirable attribute in a developer. Learning new languages/platforms should come naturally - it's part of the job.

Quote Originally Posted by esposito
The list of "inaccurate articles" seems to be endless. Here is another one:
Are you looking for articles that slam .NET in favour of VB6, or attempting to construct an non-subjective view of the situation? If, as I believe you are, are simply striving to find more and more ways to make .NET look bad, without presenting both sides of the debate in order to form an objective opinion, then of course you will succeed. Equally, if you want to slam VB6 and glorify .NET as the future of coding - you may find endless ways to do so.

P.S., sarcasm, while humorous when mildly witty, is unhelpful to a cause such as this

Quote Originally Posted by szlamany
4. Whenever the Framework version changes, you will have to upgrade your applications and provide the final user with the correct version. (Poor backwards compatibility)
MS has not become the poor backwards compatibility villian just because of the VB6-->VB.Net disconnect. That was a required step in order to embrace the CLR/framework. Not something they wanted to do - something they had to do - there was no choice. VB6 was based on 1970's concepts - it is not and never was a professional programming language - which is what .Net is now
Although I wholly agree, I believe Esposito was referring rather to new framework versions. In any case "poor backwards compatibilty" is not a valid point to make, since the two major versions of the framework that exist today can be safely used concurrently (as I and many others are right now) and you only need to ensure that the user has the version of the framework that your application targets. In addition, modifications to .NET 1.1 source code required in order to compile it for .NET 2.0 are very minor, if any. And as for what will happen in the future, that we can only speculate upon, and speculation cannot form the basis of a sound argument.