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?
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)
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.
There is no "net framework 2.7":
https://learn.microsoft.com/en-us/dotnet/framework/migration...
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
I remember scorning Xcode back when it was Project Builder, but saying Hey, at least its drop-down member lists work properly.
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.
1) See a business problem
2) Put something together to solve the problem
3) Move On
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.
One place I helped out at had a pretty awesome access app for doing some business functions. Way better than the Oracle whatever they failed to replace it with.
The problem was, nobody was willing to claim ownership. The business guy who wrote it was long gone, and IT would not accept an Access app.
If the business relies upon that Access app, and IT refuses to accept it, then it's a failure of IT to accept it and then replace it.
IT exists to serve the business.
Many, if not most, professions are not nearly as well organized and optimized as IT, so we don't have things like silos and ticketing systems to regularize our work. I can imagine an IT worker who has never experienced a nonstandard request, but I can't imagine it in my own occupation.
e.g. 'inability to account for new desired behaviors' for presumably a core business system, that the business relies on, would almost certainly imply that.
As to your question, it doesn't really matter what my background is, I could be a ballet dancer and would still be able to reason out how businesses operate and how software historically has integrated. It's not some big secret.
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.
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.
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
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.
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.