Hacker News new | ask | show | jobs
by bryanrasmussen 1726 days ago
VB6 is looked down upon.
2 comments

For very good reason, by an overwhelming majority of developers. The fact that a few developers thought VB.NET was even worse than VB6 doesn't lessen VB6's dreadfulness, it just highlights VB.NET's dreadfulness.

https://en.wikipedia.org/wiki/Visual_Basic_(classic)

>The final release was version 6 in 1998. On April 8, 2008, Microsoft stopped supporting Visual Basic 6.0 IDE. The Microsoft Visual Basic team still maintains compatibility for Visual Basic 6.0 applications through its "It Just Works" program on supported Windows operating systems.

>In 2014, some software developers still preferred Visual Basic 6.0 over its successor, Visual Basic .NET. Visual Basic 6.0 was selected as the most dreaded programming language by respondents of Stack Overflow's annual developer survey in 2016, 2017, and 2018.

Stack Overflow Developer Survey 2016: Most Dreaded: Visual Basic: 79.5%

https://insights.stackoverflow.com/survey/2016#technology-mo...

Stack Overflow Developer Survey 2017: Most Dreaded: Visual Basic 6: 88.3%

https://insights.stackoverflow.com/survey/2017#most-loved-dr...

Stack Overflow Developer Survey 2018: Most Dreaded: Visual Basic 6: 89.9%

https://insights.stackoverflow.com/survey/2018#most-loved-dr...

I think VB6’s bad reputation is that it is stuck in the 90s. I don’t know if any version of a language from that time would be popular now (let’s leave FORTRAN and COBOL aside).

I disagree that VB.net was dreadful. But it broke backward compatibility but I think for good reasons: arguments being byref by default in VB6, collections being inconsistently 0 based or 1 based, the SET keyword that wasn’t really serving any purpose and was inconsistently applied, having to provide parameters within brackets or between spaces depending on whether the return value is assigned to a variable or not, etc...

I have a lot of sympathy for the frustration of someone who has to maintain a huge code base when backward compatibility is broken, but I think the changes VB.net introduced were necessary.

Oh, the memories, I loved VB6.

I remember when my father had to use medicall services billing program supplies by a natinal health insurance company, and he had some problems with it.

Luckily, I was a student in Bucharest and I went to their headquarters to play middleman between my father and their "informatician".

This "informatician" was the sole architect, UX designer, developer, tester, release manager for this program -- VB6+ access.

I sort of helped him debug the code, he built me a special version and handed it to me on a CD.

The program was ok UX wise and blisteringly fast. Years later, they hired this corrupt company that built software for the State and produced a horrendous program, that took terrible and just the startup took 15 minutes (parsing hunonguous XML and inserting it line by line into a local sql database, as far as I remember reading the logs).

The contract ran into HUNDREDS or millions of euros. Granted, the scope of the program was a bit wider.

At least VB.net kept my favorite legacy error handling strategy: https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...
Plenty of people still write C99.
It's not the language itself, but the platform. VB6 was primarily used to write RAD GUI applications. The GUI elements VB6 provide are very outdated by today's standards.
I only wish there was a modern tool as simple as VB for crud application.
What's wrong with VB.NET Winforms with the Visual Studio WYSIWYG? I still have yet to find a better GUI building experience (alternately the same thing in C#)
You can still buy PowerBuilder, which was always superior to VB6 for relational applications.
It's been unsupported for 12+ years ? If you have code relying on it and haven't migrated to something supported it means your code is not maintained (don't care what your excuse is, using VB6 in 2020 means you're not actively maintaining the project), written 2 decades ago with the coding standards of the era, the original developer team is gone and probably retired and since nobody is actively maintaining it nobody has much knowledge about how it works.

So yeah anything that's still running on VB6 is very likely crap.

> If you have code relying on it and haven't migrated to something supported it means your code is not maintained

No, it does not. It means that Microsoft no longer provides support for the IDE. That does not prevent the developer from maintaining their own VB6 code. With some extra steps, the official IDE and compiler for VB6 can still be installed on Windows 10. Running programs built from VB6 is still supported.

> written 2 decades ago with the coding standards of the era, the original developer team is gone and probably retired

This applies regardless of the programming language to any codebase that has been around for long enough.

>No, it does not. It means that Microsoft no longer provides support for the IDE. That does not prevent the developer from maintaining their own VB6 code. With some extra steps, the official IDE and compiler for VB6 can still be installed on Windows 10. Running programs built from VB6 is still supported.

If you're comfortable with this then I don't think you're actively investing in your software.

>This applies regardless of the programming language to any codebase that has been around for long enough.

No, if you have a team actively maintaining the project you have the knowledge transfer in-house which is the second part of that sentence.

> If you're comfortable with this then I don't think you're actively investing in your software.

What exactly does 'actively investing' mean in this context and why is it needed? If the software is actively maintained so that it continues to meet business requirements, is that not enough?

> No, if you have a team actively maintaining the project you have the knowledge transfer in-house which is the second part of that sentence.

That is orthogonal to what programming language is being used. When the project is actively maintained, knowledge can be transferred regardless of the programming language.

>What exactly does 'actively investing' mean in this context and why is it needed? If the software is actively maintained so that it continues to meet business requirements, is that not enough?

If you're actually investing in maintaining something that's running on a deprecated platform that's decade over EOL and nobody wants to touch with a 10 foot pole - that sounds like a crap project by definition.

Anything that's sufficiently funded to be actively developed would have figured out a migration plan by now, the only scenarios where it wouldn't sound like terrible projects to work on.

>That is orthogonal to what programming language is being used. When the project is actively maintained, knowledge can be transferred regardless of the programming language.

No it's not when the language is deprecated by the owners for over 12 years at this point. It's like having software that only works on windows xp and maintaining it because you can still boot a VM to run it. Good luck working on that POS.

> If you're actually investing in maintaining something that's running on a deprecated platform that's decade over EOL and nobody wants to touch with a 10 foot pole - that sounds like a crap project by definition.

The platform it runs on is Windows 10, which is not deprecated. Microsoft provides an 'It Just Works' guarantee on Windows 10 for VB6 applications. It does not matter whether someone wants to maintain code. The company pays people to do it. Just like how there are many people who do not want to work on proprietary software but do it anyway because their employer pays them to do it.

> Anything that's sufficiently funded to be actively developed would have figured out a migration plan by now, the only scenarios where it wouldn't sound like terrible projects to work on.

Actively developed means that bugs are fixed and features are added as needed by the business. It does not mean jumping on the latest tech trends when there is no business justification. And I am pretty sure that the users are happy that they can use a fast, responsive application instead of a lumbering, bloated Electron app.

> No it's not when the language is deprecated by the owners for over 12 years at this point. It's like having software that only works on windows xp and maintaining it because you can still boot a VM to run it. Good luck working on that POS.

That is a strawman argument because the VB6 IDE and programs compiled with it run on Windows 10 natively, without a VM. And running VB6 programs on Windows 10 is officially supported.

That’s kind of life though.

We have a COM component written in VB6 running in IIS on windows containers on Amazon in EKS.

It works but it’s crap!

At my last job there was a team of 4 or so people who had originally written some vb6 code that they were still maintaining. This was as recent as 2020 and since there were no plans to stop I assume it's still ongoing with, at best, some plans to move off being made what with how slow things moved.

Even they agreed it was shit though.

Welp, what if I told you a Sixth Form (Y12, age 16-17) in a UK school has a computing course that just started and is reportedly using VB6 ... I'm really not sure what to say?
yeah it wasn't said when it was moved from though? The reference to Machine learning implies more modern, but not necessarily so.

At any rate even when it was maintained still looked down on, I guess a Dijkstra based side-effect.

There is RO Mercury?