[viraptor]

> VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm.

What do you mean by this? Visual Studio today has a designer / code editor that works in a very similar way to VB6 that I remember. What do you think is missing?

[highwaylights]

How much time do you have?

P-code debugging with fully rewindable edit and continue.

A one-true-way event model that was derided at the time but was really just years ahead of its time.

Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.

The sweet, sweet With keyword. I know, I know. But I don’t care. Just be more aware of your namespaces.

Also (and I still don’t understand why we can’t have this in VS Code when VS had this in 1998) object combos at the top of the code file for class and method (admittedly VS proper still has this I’m just grumpy at the regression)

[viraptor]

> The sweet, sweet With keyword.

VB.net supports With though?

> Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.

.net framework 2.7 is guaranteed to be installed by default these days so you can deploy one exe without shipping your own runtime. Yes, officially you shouldn't, but there's so much stuff that depends on it now.

[wcoenen]

> net framework 2.7 is guaranteed to be installed by default these days

There is no "net framework 2.7":

https://learn.microsoft.com/en-us/dotnet/framework/migration...

[viraptor]

Typo - I meant 4.7. Although it looks like they finally moved to 4.8 in w11.

[sn_master]

> .net framework 2.7 is guaranteed to be installed by default these days

Yes, but that wasn't the case back in the mid-2000s when VB6 was dying and no one wanted to migrate to VB.Net

[ShadowBanThis01]

One thing that sucks about those combos, if I remember correctly: Don’t they show only the members of the class your cursor happens to be sitting in, and not those in the whole file? That’s just monumentally dumb. I remember cursing at those as I hunted through a bunch of files for some function… only to find it was right there in the file I had up but Microsoft didn’t show it.

I remember scorning Xcode back when it was Project Builder, but saying Hey, at least its drop-down member lists work properly.

[emodendroket]

A lot of people who wrote VB weren’t serious/professional programmers and VB.NET was too complex for them. For the serious programmer group, the stink of “VB” tainted it right out of the gate (despite having complete feature parity for a long time VB.NET jobs always paid notably less than C# ones). So it was kind of a compromise that satisfied nobody.

[analog31]

That was me. I wrote what I affectionately call "crapware," which are small apps that solve a problem but are not intended for use at scale. There was a lot of this stuff, such as little database queries, or hacking together a few industrial sensors with a crude display. Businesses ran on crapware. Maybe they still do. A few thousand lines of code that I wrote for a manufacturing fixture ran bug-free for more than a decade.

I remember that just downloading and installing VB.NET was burdensome, especially in the plant where many of the computers were not networked.

When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.

[ta1243]

I've written a lot of crapware, still keeps my employer working 15+ years on. Meanwhile "replacement" systems have come and gone, but the users still keep using the crapware.

1) See a business problem

2) Put something together to solve the problem

3) Move On

[MichaelZuo]

I was going to say, a few thousands lines of code that reliably solves a real business problem for over a decade is pretty much the exact opposite of 'crapware'...

[emodendroket]

As long as you don’t care about stuff like maintainability or logging sure. The issue is that a lot of times businesses outgrow their bespoke Access app or whatever and then it’s a huge headache to untangle the reliance on it and go more robust. Of course if that never happens it’s great and frees up developers’ time for higher-value work.

[jopsen]

> The issue is that a lot of times businesses outgrow their bespoke Access app or whatever... > Of course if that never happens it’s great..

It could also be argued that outgrowing your initial business app is good thing.

Lots of business don't outgrow it, because they don't grow :)

Indeed, it might be reasonable not to invest too much upfront, before you have scale and can afford to build stuff you won't outgrow.

[MichaelZuo]

I don't get the relation here?, most businesses care somewhat, and certainly the better run businesses do quite a bit, so they'll make sure to record down everything important about the software.

[analog31]

I'm sure this happens all the time. The term is technical debt.

I think there's a kind of no-mans-land, where programs get too big for an individual hacker to manage, but too small to muster the programming department. Getting small tasks done on any kind of timeline is usually just a no-go.

[jacquesm]

I came across such a project recently built using FileMaker in 2001 or so. On the original hardware, no less.

[ralphc]

Please encourage them to make a backup and get it into a VM. You should be able to find Windows 2000 if it will run on that.

[jacquesm]

I actually did just that. But I can't enforce things, only recommend.

[sn_master]

Also, most machines did not have the .Net framework installed, and back then it was 20 MB download which was gonna take ~2 hours on dial up back in the day vs MSVMVM6.dll which was on all Windows versions from 98 until 7 at least.

[deaddodo]

> When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.

VS6 was still the majority IDE well into the mid-00s, at least in an academic setting. I still remember getting handed an academic license DVD to use for my C++ courses in University around that time.

The disconnect between "classic" and ".NET" VS took a long time to break, I would say until about VS2008/2010.

[nextaccountic]

what you called crapware is just scripting, but with a gui rather than running in terminal

it's like a quick and dirty shell script or what once could be a tcl or perl script, but today would most probably be a python script

[SamuelAdams]

I think today python fills that void - people who are not serious programmers but need to put something together. Think academics, data analysts, etc. And since Python is cross platform and easy to get started with it is a lot more attractive than VB.

[cstejerean]

It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

[Blackthorn]

Honestly it's harder to put together a quick GUI application in anything than it was in the VB6 days. By losing VB6, we've lost a lot of power and ability to do GUI things quickly.

[sn_master]

WinForms in C# was pretty decent tbh. Not so sure about WCF/Metro/Modern and whatever it is now that Microsoft been releasing. They just stopped caring about consistent UI for apps on Windows altogether since ~2010 or so.

[emodendroket]

WinForms is fine but it makes it way too easy to put all your behavior in the code behind instead of doing things nicely. Which I guess is what you want for a non-programmer tool but it is a hassle for me. Either way the .NET UI situation is a mess and I’ve never seen the sense in picking up the latest flavor of the month since it will be out of favor by the time I have occasion to use it.

[Turskarama]

You say was but winforms is still supported in VS2022 and is probably my go-to if I need to hack together a small windows program.

[markus_zhang]

What's the bottleneck to build a modern VB6? Just curious.

[emodendroket]

The people most interested in such a product are not those with the skills to build it.

[mike_hearn]

There are VB like tools. These days they're all SaaS though. Oracle APEX is one well known one, there are plenty of others out there.

There are at least three massive problems faced by anyone who wants to hew closer to the VB6 model:

1. Deployment tech.

2. Getting people to pay for it.

3. Developer culture.

In order:

Deployment. There are tools and UI toolkits today that support VB6/Delphi-like development, but they aren't web based. For example, you can also do VB6 like development using Java or Kotlin + JavaFX + Scene Builder (or Swing and one of the visual form designers for it). This leads to the question of how to deploy the result. Unfortunately, for the past 15 years or so the answer has been pretty much "you can't".

In the VB6/Delphi era the answer to deployment was "take your EXE and stick it on a shared Windows network drive". For internal business distribution this worked fine. Java had JRE+Java Web Start, which also worked fine inside businesses. Unfortunately neither approach works anymore: Windows is no longer ubiquitous, tools don't produce standalone EXEs anymore, users don't know how to handle zips and folders (these skills have atrophied). Also security has got tighter so throwing EXEs around is harder, and people expect software updates to work smoothly. Java dropped WebStart and never replaced it with anything good enough, so the tooling actually regressed with time too.

This isn't fundamental and is fixable. I spent the last couple of years fixing the tooling situation [1]. You can now deploy desktop apps as easily as you do for a web app. Conveyor does signing, packaging for Win/Mac/Linux, and integrates auto-update as part of the packaging process. It will even generate icons and a download page for you and then upload the results. You do still need code signing certificates, however, and getting those isn't as easy or cheap as it is for SSL certs with LetsEncrypt.

A related issue is database and server side logic hosting. VB6 development assumed it was OK to just connect directly to a database using its native protocol and that e.g. every employee would have a DB user. People are more protective of their databases these days and would find this level of simplicity to be radical. I've experimented with that too and given a talk on it at KotlinConf [2]

Payment. VB6/Delphi were developed in an era when people expected to pay hundreds or even thousands of dollars for each version of their IDE/compiler. There were no subscriptions but in practice new versions would come out every couple of years or so, so if you wanted to keep up you'd need to budget a few hundred dollars a year. Skipping versions was common.

Nowadays, people's payment expectations are different. They expect programming languages and platforms to be free and open source. They take absolutist positions on it, saying things like, "it's not open source so I can't ever use this". This rule vanishes if something is a proprietary SaaS however. This kills the incentives to develop better tools for standalone "business crapware" development as mentioned elsewhere in the thread - apps have to be tied to a subscription SaaS or else you can't get paid to work on it. In turn that makes it hard for people to learn by just experimenting locally. For programming languages, every new language that comes along in the past 15 years or so is essentially either a hobby project of celebrity employees (e.g. Go), or a way for rich tech firms to solve tech debt and productivity issues (e.g. Kotlin, Rust, TypeScript), or commercialized by selling long term support (Java). The closest to a real commercial language is Kotlin and that's very indirect, it incentivizes IDE sales, as IDEs are still something people are sometimes willing to pay for (but most use whatever's free).

It's possible that the pendulum will swing back here.

Developer culture. Part of why devs are so hardline on stuff being free is that they want to add it to their CV and learn tech that they can take with them to their next job. This means going where the crowd is. If you wanted to do something VB6 like you'd have to do things very differently to how they are done today (e.g. probably not web based) and that would mean people would stay away just out of fear that they'd stray too far from the herd.

Still, despite these problems, there are ways you can do that. Like I said, take Java/Kotlin+JavaFX+Scene Builder+Conveyor and you have something similar to the highly productive 90s era platforms. You do of course need the confidence to learn tech that some consider old fashioned, and which isn't as widely used as React or whatever.

You could even just go all-in on the Apple platform! Swift+Xcode+their Interface Builder still works.

[1] https://conveyor.hydraulic.dev/

[2] https://www.youtube.com/watch?v=jKeHKe9ttas

[lelanthran]

> It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

I would say that it is harder, but not significantly so.

Lazarus gets mentioned a lot on these forums, but have you tried it? I use it to whack together decent native looking applications.

It's a single download, it comes with a comprehensive list of components which you drag onto a form to build the GUI, never breaks old apps on an update, and works on Windows, Mac and Linux.

[emodendroket]

Python is also more palatable to professional developers than VB ever was.

[bdavisx]

And as a programmer who preferred more c style languages, vb.net sucked (and I understand that's just, like, my opinion man). Way more verbose with weird syntax. Can't remember the exact syntax for lambdas, but it was a joke.

[reactordev]

VB6’s concept of OOP was different. Sure the same keywords are found: Module, Sub, etc but it was rewritten to run on IL/NET VM. Fundamentally changing it from a COM compatible language to a .Net framework compatible one.

[wvenable]

VB6's concept of OOP was simple enough it could have been translated into .NET and .NET is broadly compatible with COM. I'm certain Microsoft could have made it work. They really needed to consider VB6 as a backwards compatibility target instead of building VB.NET as a modern replacement. VB.NET really has no reason to exist; it's not compatible enough with VB6 but then also includes a bunch of VB6's weirdness.

[gabereiser]

Yeah, I agree. They didn't know it at the time but .Net and C# (their answer to java) would take over everything they did.

[deaddodo]

The visual editor is the same...but even with VB Classic, you couldn't just design a UI and have it magically work, you needed to wire up the logic. That component has a much higher learning curve backed by a particularly more difficult to grasp language.