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.
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.
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.
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'...
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.
The issue is there’s no engineering process around it, even in a shitty organization where the “engineering” is garbage.
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.
OK but does IT exist to serve the business by accepting responsibility for stuff that doesn’t meet their standards and they can’t really support? Why have qualified people at all then?
I can't speak to IT specifically, but generally the answer would be yes. Stuff happens, resulting in "nonstandard" or unexpected requests, and the decision on how to deal with them rests with the business, with reasonable input from the people involved. In my own work, this can often happen by accident when departments and business units are reorganized and acquired. I once got an entire product line dropped in my lap, that didn't work at all, hardware or software.
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.
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.
So when it goes wrong in many predictable ways it’s a nightmare. All the stuff software engineers put around software to make it reliable, fault tolerant, and generally having the expected behavior is not just for laughs but the result of hard-won experience.
It seems like your describing more of a problem with the system between the screen and the chair.
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'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.
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.
> 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.
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.
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.
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.
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.
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.
Correct, but it hasn't been upgraded in over a decade. It no longer produces apps that are consistent with Microsoft's own the way it was until Windows 7.
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.
> 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.
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.
