Re: Microsoft didn't see a disconnect between "VB Classic" and "VB.NET" like so many users did.
It wasn't backward compatible in the least bit. You pretty much had to start over. The auto-converters were poor, mostly because GUI land doesn't map well to Web Land.
In the Python 2-to-3 change, most just had to re-test and do minor tweaks to existing code (at least so I hear). Few had to start the code-base over. If I had to score the difference on a 1-to-10 scale, the Python change was like a 2.5 and the VB change was like a 7.5.
I think the comparisons are much more apt than that. It's a set of interlocking 80/20 challenges. In both languages ~80% of the language stayed the same, the huge fights were over that remaining 20%. Similarly in both cases users themselves maybe only used 80% of the overall language capabilities but among users it was frequently a different 80%, and one person's unused 20% was another person's critical "must have" deep in their 80%. That in particular is the 80/20 rule that affects what a developer might consider "minor tweaks".
Beyond that there are the exact same basic economic disincentives to migrate: large code bases have larger sunk costs, more friction, and less interest in migrating. It's the really large code bases that have the most reason to be disruptive in any migration.
In the VB6 to VB7 change, some could have just "re-test and do minor tweaks to existing code", even without the GUI converter helping you with all the Designer-generated metacode, had you been using VB best practices. There wasn't anything anywhere near as significant as say a massive change to default representation and syntax of strings (such as Python 3 switching to Unicode by default; VB6 at least came from Microsoft's UCS-2 era, which is also partly how so many of its programs have managed to survive in Enterprise this long). The problems were much more long delayed deprecations and a bit more forced handholding in project organization (classes existed in VB from the beginning, but so much VB was still global variables and disorganized global modules).
As someone involved in multiple migrations out of VB6 at this point in my career, second only to big Enterprise Sunk Costs reasons, I very much feel that project organization was the biggest reason codebases had to "start over". A large VB6 project built using almost nothing but global variables and global modules is a fun spaghetti ball to untangle back into some semblance of OOP. It wasn't anything syntactic or technical (otherwise presumably better migration tools could have been built if it were something mechanical like that).
Even the closest to a technical problem was essentially a universal one that applied somewhat similarly to Python 3 as it did to VB7: C/C++ FFI changed a great deal from ActiveX papering over COM's worst faults and VB pretending DLL calls were easy (and shuffling its DLL Hell under the carpet) to .NET's complicated COM relationship and P/Invoke system that more accurately reflect the FFI reality in Windows (versus VB bubblegum and lollipops). Even then, P/Invokes sure look a lot like VB<=6 FFI calls because they were clearly based on it. (There are also ways in .NET to pretend COM is friendlier than it is, themselves early VB inspired.) FFI can be assumed to be a challenge in just about any language upgrade/update/migration in the history of languages, and that's not entirely a backwards compatibility problem you can fix nor prevent in the language design. (Look at the native interfaces of any and every other language out there.)
(Sure, I've seen the laundry lists of complaints of things that weren't backwards compatible, but compared to the 80/20, it's absolutely fair to compare VB 6/7 and Python 2/3, and to admit there is no magic "right" solution in either case to avoid the migration hurdles both experienced.)
> The auto-converters were poor, mostly because GUI land doesn't map well to Web Land.
While there was a lesser used "webforms" converter, the major converter was direct GUI to GUI from VB6 to .NET 1.0 WinForms, very apples-to-apples, and it did a rather good job given what it had to work with (both the byzantine messes that were the average VB<=6 codebase and the young and not quite polished, but certainly capable in theory of everything previous VB did, .NET 1.0 WinForms). While with hindsight we mostly all agree "webforms" was a bad idea, it wasn't the emphasis in migration stories, and it certainly was never the only option (and where it was seen as the only option likely the local myopia of management that were the ones wanting the instant jump to Web Land "for cheap" in a migration to secure funds for said migration in the lands of sunk costs).
Everybody had a different opinion about what those were. Things that look obvious in hindsight weren't.
Re: While with hindsight we mostly all agree "webforms" was a bad idea
Do you mean in general or early versions? It seems a git-er-done platform for smallish apps without the fuss and muss of MVC. Our Webforms group is more productive than our MVC group. If MVC pays off in the distant future, nobody can really tell yet. Our MVC stack is poorly tuned, but that's the problem with MVC: it requires decent oversight. MVC typically can have more JavaScript eye-candy to dazzle, but I'm not sure it's worth it from a raw productivity standpoint. The org is paying a toy tax.
I'd like to think "don't use global variables", "try not to use global modules, prefer classes", and "goto considered harmful" are relatively universal best practices that were espoused as far back as VB1, as I recall, very little hindsight needed for the best practices I was particularly thinking of.
I mean every version of Webforms. Webforms is entirely dead in 2020. There's no support in .NET 5. It's not surprising that your Webforms group seems more productive, and MVC more "poorly tuned", as both are common misperceptions, and performance and web standards/best practices continue to show MVC better aligned with today's standards and performance than Webforms ever could be. (It's also related to why it isn't surprising some of the Webforms fans are busy building Rube Goldberg machines in Blazor today to replace their lost love.)
I didn't use very many global variables in my VB-classic. I'm not sure what you mean. And, what's a "global module"?
Re: "Webforms is entirely dead in 2020. There's no support in .NET 5."
Deprecated, yes, dead no. MS announced no plans to stop basic maintenance. Even ASP Classic still runs on IIS (upon configuration adjustments). I'm not necessarily saying using deprecated products is "good", only that Web Forms programmers seem to get more done in average for typical custom CRUD apps. It looks like productivity is being shot in the head to keep Future Compliant.
Re: "and web standards/best practices continue to show MVC better aligned with today's standards and performance than Webforms ever could be."
What is "better aligned with..." exactly? I'm not claiming Web Forms is "web scale". I'm just saying use a Chevy instead of Maserati if you don't actually need a Maserati because Maserati's are expensive and high maintenance. Too many want to stick every buzzword in their stack to keep their resume HR-bot-match-compatible. It's fraud in my opinion.
I would note the needs of CRUD are different than the needs of "web" in the CMS-ish sense. MS stacks of late seem to try to cater to both, and it makes for unnecessary complexity. I think they should split and have a CRUD-friendly stack different from a CMS-ish stack.
It wasn't backward compatible in the least bit. You pretty much had to start over. The auto-converters were poor, mostly because GUI land doesn't map well to Web Land.
In the Python 2-to-3 change, most just had to re-test and do minor tweaks to existing code (at least so I hear). Few had to start the code-base over. If I had to score the difference on a 1-to-10 scale, the Python change was like a 2.5 and the VB change was like a 7.5.