Hacker News new | past | comments | ask | show | jobs | submit login

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.




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).


Re: had you been using VB best practices.

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.


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.


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.


Re: the Perl 5/6 stuff

This has resulted in Perl 6 being renamed to Raku (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.


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.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: