6 ms·

I do have to give MS credit for mostly supporting deprecated products. I do think they should have open-sourced VB-classic and FoxPro. They pissed off a lot of

by tabtab 7y ago

I do have to give MS credit for mostly supporting deprecated products. I do think they should have open-sourced VB-classic and FoxPro. They pissed off a lot of organizations by outright ending any future progress. There were some proprietary or "sensitive" parts in the code base, but they could have documented and replaced those modules with low-performance or filler stubs, and let the open-source community rework those parts. (Note those products still run in Windows 10, the last I heard.) Google will have a hard sell for "enterprise" tools if they keep pulling the plugs. Rewriting custom built applications into non-deprecated platforms is expensive.

WorldMaker 7y ago
Microsoft didn't see a disconnect between "VB Classic" and "VB.NET" like so many users did. They continued the version numbers straight across (the first VB.NET was version 7; it's currently at 16). They didn't feel they outright "ended" future progress, they felt they evolved the platform organically and at least to some extent were confused when users didn't follow along. Microsoft followed the confusion by providing increasingly more migration tools and assists (many of which you can still find online, even if some of the worst mistakes of their WinForms 1.0 era code is uncorrected). (I don't know if a similar reasoning exists behind encouraged migrations from FoxPro to Access, but I'd imagine that given how very long Access supported FoxPro imports and databases, there's probably a similar sentiment inside those parts of Microsoft.) Those kind of compatibility break/evolutionary steps are always hard, and Microsoft could always have handled them better, but seeing as how even open source continues to have the exact same problems (say the Python 2/3 debate or the Perl 5/6 stuff) it's hard to say that anyone in software has a good handle on this stuff. Microsoft at least seems to try every time to offer migration paths and assistance/help.
- pjmlp 7y ago
  I also don't see the disconnect between Visual Basic 6 and VB.NET. Most of the stuff like Me ended up being integrated, and based on my experience at a couple of Orgs where regular office users naturally migrated from VBA into VB.NET, it was quite natural for them to do so. Maybe those that hacked around on VB like it was QBasic (note not QuickBasic), or still stuck with VBX programming model instead of OCX, had issues migrating.
  - WorldMaker 7y ago
    Perhaps oddly, I think the biggest difference is simply how much people didn't like early Visual Studio and the .NET WinForms designer. I look at VB6 and the .NET 1.0 WinForms designer and see the exact same tools just in slightly different positions, but there was a ton of cheese moved in those "slightly different positions". I also buy at least some of the runtime environment arguments. Microsoft did a better job of slipstreaming the VB6 Runtime install into Windows itself (and did a fascinating job of mostly protecting VB1-6 users from the DLL Hell management of said Runtimes, plural) and also early application installer that enough VB6 users had some interesting illusion that they were creating "real" EXE files without a runtime. As opposed to the early days of .NET where few Windows systems could just be assumed to have it installed and slipstreaming it into most InstallShield-style installers was never fun.
- tabtab 7y ago
  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.
  - WorldMaker 7y ago
    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).
- lizmat 7y ago
  Re: the Perl 5/6 stuff This has resulted in Perl 6 being renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). So now there's Perl, and there's Raku. Each going their own way, but with Raku offering a migration path with its Inline::Perl5 module, allowing you to run (almost) any Perl code in Raku.
  - WorldMaker 7y ago
    Right, exactly why I mentioned it, because it is a good example of a different path in open source, and one that still hasn't necessarily proven itself to be "better", but certainly different.

by tabtab 7y ago

WorldMaker 7y ago

Microsoft didn't see a disconnect between "VB Classic" and "VB.NET" like so many users did. They continued the version numbers straight across (the first VB.NET was version 7; it's currently at 16). They didn't feel they outright "ended" future progress, they felt they evolved the platform organically and at least to some extent were confused when users didn't follow along. Microsoft followed the confusion by providing increasingly more migration tools and assists (many of which you can still find online, even if some of the worst mistakes of their WinForms 1.0 era code is uncorrected). (I don't know if a similar reasoning exists behind encouraged migrations from FoxPro to Access, but I'd imagine that given how very long Access supported FoxPro imports and databases, there's probably a similar sentiment inside those parts of Microsoft.) Those kind of compatibility break/evolutionary steps are always hard, and Microsoft could always have handled them better, but seeing as how even open source continues to have the exact same problems (say the Python 2/3 debate or the Perl 5/6 stuff) it's hard to say that anyone in software has a good handle on this stuff. Microsoft at least seems to try every time to offer migration paths and assistance/help.

pjmlp 7y ago
I also don't see the disconnect between Visual Basic 6 and VB.NET. Most of the stuff like Me ended up being integrated, and based on my experience at a couple of Orgs where regular office users naturally migrated from VBA into VB.NET, it was quite natural for them to do so. Maybe those that hacked around on VB like it was QBasic (note not QuickBasic), or still stuck with VBX programming model instead of OCX, had issues migrating.
- WorldMaker 7y ago
  Perhaps oddly, I think the biggest difference is simply how much people didn't like early Visual Studio and the .NET WinForms designer. I look at VB6 and the .NET 1.0 WinForms designer and see the exact same tools just in slightly different positions, but there was a ton of cheese moved in those "slightly different positions". I also buy at least some of the runtime environment arguments. Microsoft did a better job of slipstreaming the VB6 Runtime install into Windows itself (and did a fascinating job of mostly protecting VB1-6 users from the DLL Hell management of said Runtimes, plural) and also early application installer that enough VB6 users had some interesting illusion that they were creating "real" EXE files without a runtime. As opposed to the early days of .NET where few Windows systems could just be assumed to have it installed and slipstreaming it into most InstallShield-style installers was never fun.
tabtab 7y ago
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.
- WorldMaker 7y ago
  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).
lizmat 7y ago
Re: the Perl 5/6 stuff This has resulted in Perl 6 being renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). So now there's Perl, and there's Raku. Each going their own way, but with Raku offering a migration path with its Inline::Perl5 module, allowing you to run (almost) any Perl code in Raku.
- WorldMaker 7y ago
  Right, exactly why I mentioned it, because it is a good example of a different path in open source, and one that still hasn't necessarily proven itself to be "better", but certainly different.