Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why did Visual Basic die?
420 points by _f1dq on Sept 11, 2023 | hide | past | favorite | 522 comments
I've been a software developer for almost 30 years. I remember using VB back in the 90's and I was thinking about it the other day and it dawned on me; despite all the advances in technology since then, nothing I have found compares to that development experience today. I would go so far as to say we've gone backwards in a big way.

Now, I'm no fan of Microsoft products but, I have yet to find a tool that can allow me to be as productive in so short a time as Visual Basic. Yet I can't help wondering what problems it had that caused them to abandon it? Moreover, why hasn't someone come out with a solid replacement?




I actually wrote a long article on this [1]—and had a chance to interview some of the team that built the original version of VB that was sold to Microsoft. (Alan Cooper and Michael Geary; Michael actually frequents HN pretty regularly!)

My opinion is that it was a confluence of a few factors:

- Microsoft was very worried about the threat of Java/Sun, and rotated hard into .NET and the common language runtime as a response.

- The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case). Couple with the shift to .NET, Microsoft listened to them: VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm. That left the silent majority high and dry.

- The web emerged. Working with the Win32 API was suddenly less relevant, and younger devs adopted PHP en masse, rather than adopting VB. (And existing VB6 devs upset about the change also migrated over when they could build for the web instead of Windows) Unforced error on Microsoft's part, since IE had 96% browser marketshare in 2001.

[1] https://retool.com/visual-basic/


The web and the way MS handle the web killed it. Microsoft was pushing everyone towards these horrible activx components. Many moved to PHP or Adobe Flash.

I was using MS Access back in the day to solve business problems - it was like a VB6 DSL focused fully on data-driven applications. It was extremely time efficient thanks to that focus - what took me days to build took a VB developer (or PHP developer) months. That died thanks to web (and the web version being horrific and a dataleak waiting to happen).

The move to C# and the path they've followed since then was, looking back, the way to go. I only wish that they had done more to make the experience for native programmers better out of the box.


In my experience, ActiveX was not what they pushed. They pushed Asp.Net Webforms which used VBScript for the template language. The ViewState monstrosity made it an awful experience. Specifically how it send way more data than needed to and from the server on each request. I shiver when I think of it.


The real problem was worse than that: it was not a technical, but a legal one: Licensing!

You need to buy CALs for every concurrent user (yes, not only SMB/terminal services users) was the way to go according to some MS license experts, and the licensing was totally incomprehensible, as is today. No wonder most didn't want to risk building a business on these maybe not so solid foundations.

Still I only dare using asp.net for serving public webpages from Linux.

Of course the technical problems were also present, but many didn't even get to think of that as the BSA bullying was keeping them away already.


I think GP is describing the period before the .net switch. I remember back in those days having to do web stuff on MS platforms, which meant classic ASP, which was great for the job it was designed for: gluing together ActiveX components.

Unfortunately, nobody anywhere ever trusted ActiveX because it (at least gave everybody the impression it) had holes the size of a bus, so you were stuck using a limited language with no library support to do all the glue and all the heavy lifting, it was a very unpleasant period of time if you found your way into a Microsoft shop.


The ViewState problem is easily avoided by keeping it on the server


The ActiveX era pre-dated ASP.NET.

When the web was new, it was so clearly not designed for apps that pretty much everyone agreed it was absurd to use it that way. The UX and DX was just such a horrifically huge downgrade. Instead, HTML was for documents and linking, and apps would be given a rectangle (maybe the entire rectangle) through which they could appear in the browser. Netscape partnered with Sun for Java applets. ActiveX was therefore a response to that.

ActiveX made a lot of sense for Microsoft at the time. Firstly, it let the enormous base of Windows devs put stuff into a web page almost overnight. Secondly, it leveraged existing tech that was already designed for embedding one app's UI inside another app (OLE), and for shipping widget libraries to visual designers (OCX). Thirdly, ActiveX was a lot faster and more efficient than Java applets, being based around tightly written Win32 code. Finally, people weren't so focused on security back then and anyway, Microsoft had recently been investing in adding code signing to Windows. It appeared to them at the time that code signing would be sufficient to stop abuse. We know in retrospect it didn't quite work out that way for them, although it's been pretty successful on Macs.

And in fact ActiveX did see quite wide usage, albeit mostly as IE's answer to Netscape's plugin interface. But it didn't take off in a big way because:

1. ActiveX apps were native code and native code is very low level and thus very large compared to JavaScript and HTML. Performance is great because the CPU eats it directly with no intermediate translation layers, but you pay for it in code size. Back then bandwidth and CPU were both tight, but HTML/JS were light on both at the cost of UI latency and primitive controls. People picked low startup time followed by high latency and primitive controls.

2. The UI they picked for code signing was a (standard at the time) popup modal dialog. It had very poor usability, being filled with tons of complicated words, often asking you to approve software from a company you'd never heard of (i.e. products/websites did not use the same name as the company that produced them) and worse, malicious web pages could put you into an infinite loop where if you clicked cancel they'd just immediately ask you again, forcing you to click yes. Which was equivalent to downloading and running an unsandboxed program. Back then browsers went years between updates so once they shipped that mistake, it was very hard to fix quickly and so the reputation of ActiveX became very poor.

3. They had no way to sandbox native code at this time, the Windows kernel just didn't support it at all and it probably wouldn't have occurred to them anyway.

The first problem was fundamental to the approach. The second problem was an unforced error.

They could have tried to switch over to a sandboxable bytecode; VB used what they called "P-code" on an interpreter already. But they didn't. Java was becoming too popular, too fast, and they lost confidence in their own tech stack. Instead Gates threw the company into a crash effort to clone Java. By the time .NET had the ability to do ActiveX controls they'd already moved on from that approach and were trying to make DHTML work instead.


I have the opposite take, as a non-native programmer in the early 00s.

All the PostBack loops in ASP.Net and WYSIWYG editing in VS.Net 2003+ felt like they were trying to appease native programmers to a fault. VB.Net wasn't bad but it was frustrating how hard it was just to script something without boilerplate. Being limited to IIS was also bunk.


>The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case).

This is the single reason why most computing tools, ( not limited to VB ) never reached wide enough audience. The nerds keep asking for complexity, but the majority actually wanted even more simplicity.

HyperCard, Delphi, VB6, Flash.


I think there's a deeper problem with development tools in general:

There is no tool that goes from 0 to 100.

The tools you listed (I'd also add Excel) were great for people starting out, people who had an itch to scratch, people solving a problem. But inevitably, the programs they made worked too well, they got adopted, got added features, became mission-critical, and now outgrow the tool they were written in. And that's when you get the "nerds asking for complexity". Those people didn't start out nerds, they started out as users solving a problem, but now their little "make a formatted report out of this Excel sheet" tool is running the whole companies realtime sales forecasting and they scaled up along with the project.

I think the plan with VB.NET was that ("start out with VB and if you need it you can seamlessly graduate to C#!"), and Chris Lattner planned the same thing with Swift ("it will replace Python!") but none of those plans were ever carried out properly.


I have a theory on why: it's because the scope of a general-purpose-ish language inherently increases; there are always users that are mostly covered by the featureset, who just need one more feature and they'll be fully covered, so they'll ask for that feature. But by satisfying them, you'll bring more non-users from their nowhere-near-covered position up to the "99%-covered" boundary, and then they'll want their own last-1% feature.

The same people who want simplicity in their language/tooling also want to not learn a second almost-identical system just to achieve that last 1%, so refusing to expand your scope here isn't necessarily "optimizing for simplicity".


I worked for a company where we built a prototype for a rewrite of their flagship product in VB. Meanwhile a big team of programmers implemented the “production” version in VC++. But at that time a bunch of the controls available in VB were not in VC, so they lagged quite a bit. Of course management saw the prototype working (it was a CRUD app for property management) and said why not just use this. The C++ programmers turned up their noses at working in VB and were summarily fired, leaving me and a team of contractors to finish the job. 100% the right business decision and a good lesson on getting too precious with your tech.


> The nerds

The people with money really. Few people care what the nerds complain about, but Microsoft will listen to Fortune 500 companies that hold thousands of top tier paying users and their complaints about how such or such feature would help them save days of work every months.

This the ultimate "vote with your wallet" I think, those with bigger wallets will have bigger votes.


An unfortunate byproduct of this, that I think is an unpopular opinion in these parts, is increased in product analytics/telemetry. People eventually learn that the feedback you receive re your product only rarely reflects the experience of the majority of users.


Adding features to a popular tool later can make it messy. Building a tool where you can add features easily makes it elegant eg Lisp.


This article was excellent, @RyLuke — I read it a few months ago when it was first published and passed it on to just about everyone I know in my MSFT network.

I cut my teeth on VB6 back in the day — for someone that didn't know much about programming at the time it felt like I suddenly had found a new set of superpowers. VB6 was a big confidence booster + momentum builder that set me on a path to a happy career.

Awesome that you were able to connect with Alan and Michael and thanks for the trip down memory lane.


> 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?


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)


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


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


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


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


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.


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.

1) See a business problem

2) Put something together to solve the problem

3) Move On


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


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.


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


If Nobody in the business is willing to sponsor the application then it shouldn't be there.


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.


Someone has to pay. If you avoid the business processes, and just dump your science project on “IT”, you’re not serving the organization well.


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.


Why would it be a 'nightmare' if they recorded everything down and understand their software, what it does, what it doesn't do, how it operates, etc.?


Database corruption, unexpected bugs, inability to account for new desired behaviors… have you worked on software before?


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.


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


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.


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


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.


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


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.


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.


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.


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


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


Such a good comment and totally spot on. Yes, most people with the skills to build a modern day VB6 would not want use it


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


Amazing reply, includes a lot of information that I wasn't aware of even though I was the OP there! Thanks.


Thanks for the detailed explanations, makes sense.


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


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


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.


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.


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.


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.


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.


Vb.net was a bit weird yes but visual basic did need work. Vb6 did not have multithreading which was really starting to hurt its efficacy by 2002. You could work around it by using events as much as possible but there were still some things that were blocking. Also the events were not even on a separate thread either leading to the need to pepper DoEvents everywhere.

This was a dealbreaker for vb to ever become a serious language and kept it squarely in the hobby bob / prototyping arena. But who wants to prototype in a language that requires a full rewrite in another language to go to production?

In the long run this was always unsustainable. The rewrite to .net fixed this but it was a significant departure from vb underpinnings and in particular the seamless winforms integration that was pretty amazing.

Also, with .net came multilingual capability and c# got really popular quickly and displaced vb.net


VB was probably 80%+ line of business CRUD apps. What would you write in VB that needed multi-threading? You're not writing trading systems or games in it.


> VB was probably 80%+ line of business CRUD apps.

That's more a result of it not supporting it I'm sure. It could have been a great general purpose language if it was a bit more powerful.

I used to write apps in it and I often ran into these issues. Mainly small business custom administrative stuff. Like a management system for a chain of hostels. It was still important to have multithreading because things can get updated by other users, or even clients themselves through the internet (in fact I spent a lot of time adding ASP frontends back then). I don't like using locking too much in a multi-user environment because it gives a terrible UX, so I would have to constantly check if nothing had changed.

In this day and age you will also have to deal with a lot of web API calls that can happen asynchronously. Locking the main thread is really not an option. Remember that VB6 even locked the User Interface when it was doing something, even the visuals didn't have their own thread. Making for a very choppy experience.

Like I said peppering DoEvents everywhere helped mitigate this a bit, but sometimes you had to call stuff in external DLLs and while the call was away the whole UI would be hanging.


Electron seems successful regardless of lack of multithreading on the language level?

I don't buy this one.


Correct, nobody cared about "true" VB multithreading. Besides VB supported multi-processing very well, much better than the JS world does today. You could call objects between threads no problem. Behind the scenes it was using DCOM, so if you passed an object from one thread to another, the other thread would get a proxy that'd do RPCs to the first thread. So there was no true shared memory multithreading, but for VB users what they had instead was in some way even better, it was basically web workers but more transparent. Specifically, it meant that object calls couldn't run in parallel to UI updates or other logic so there was no need to think about locking.


But the whole thing of the UI being on the same thread was a really big problem. You could get around it by calling the Win32 Threads API but that would quickly lead to a crashfest due to the no shared memory thing. Electron doesn't have this problem because the UI is handled by the renderer, not the JS engine. So in that sense the UI is in a separate thread. This wasn't the case for VB6.

And events in VB6 were not great. They were good for the time, sure. Because they had to be. If you'd write an app in it today with lots of external API calls it'd be a mess.

VB6 was serviceable at the time but without multithreading support it didn't have a future in an ever more API-driven environment.


I don't quite understand what you mean by UI being in a separate thread. You could have background threads in VB from what I recall (it's been a while...). The only difference is that Electron/JS forces you to do your own IPC messages whereas Windows would abstract that out.


What I mean was that if you ran a large function that would take a few seconds, any UI redraw would be blocked completely for that time. So resizing a window would not cause a redraw of the UI until it came out of the function, pressing a button would not visually reflect the button status, basically it would seem like the application was hanging.

You could avoid this by peppering DoEvents in your loop. However, this was not always possible like if you were calling an external DLL function. I had an application that would talk to a Kodak digital camera by using their DLL and that would take considerable time.

It's really what separates a serious programming language from a toy, or at most a prototyping tool. Like Fisher Price, you can make something quick but it's not capable of actual use.

I think people have this rose-colored view because back in those days UX standards sucked and many apps had a lot of quirkiness. But times were changing and even a few years later this was unacceptable.

There were no official background threads, you could use the Win32 Threads API but it would cause instability due to not having memory protection.

But this "hanging" behaviour was really not suitable for a general purpose application. Electron doesn't have this issue because the renderer is independent from the javascript code.


I thought there were JS style worker threads:

https://learn.microsoft.com/en-us/previous-versions/visualst...

but from looking it seems like people were doing it by writing VB that ran in a separate EXE and then indeed, COM would let you do RPCs between the different processes. So multi-processing rather than multi-threading.


Javascript is better at asynchronism than VB was, and in Electron the user interface does run in a separate process. Unlike Visual Basic 6, where the UI would completely hang when you were busy with some external function call.


As someone who loved coding in VB6: (I actually dreamt about it the other night, thought I woke up some 20 yrs ago!)

- very cool that you got to interview the VB team, your article is high on my reading list :) - to OP’s point, I recently started doing some things in Swift with XCode and found sim having just as much fun. I’m using SwiftUI. So maybe not the same experience for everyone but I wanted to share here.


I did a shitload of programming in VBA, specifically Word macros. Word 6 was the peak of that product. I wrote entire text-processing applications in it, with dialog boxes and everything. Started my career at a Big-6 firm with one, actually.

Now I’m learning SwiftUI as well, and like it so far. I’m an experienced iOS dev, but SwiftUI is new to me. But I like it (and QML in Qt) more than I expected. Good luck!


Thanks! Good luck to you too!

I don’t have experience with iOS - I am actually doing a bit of macOS development with that SwiftUI because, well, desktop apps kind of take me to my teen years building VB programmes (no one called them apps, at least I didn’t).


VB and the Web: The VB model for rendering Web pages was Active Server Pages and Server side rendering. Very similar to Java Server Pages. Which was still better than PHP but the IDE did not have a community version and php was easier to get started and was being taught in college curriculum.

IE having so much browser market also killed anything MS because they always tried to create their own standards which nobody wanted to follow. The client side was so difficult to script with having to test which browser and accomodate quirks mode. Another unforced error. Corporate adopters are still trying sunset critical apps which only run in IE or Edge with IE mode turned on.


As someone that started in vb6 and then php in 2001, this.


My understanding is that the target audience for VB.net was happy enough with C# instead, so it was a product without much of a user base.


I do not think the problem with VB was the language. I think it was the graphic / UI expressive power, a simple way to add and create custom components.

At the same time that both VB and Delphi reached peak usage, the web started to show how easy it is to express graphically and UI using CSS. When you have to write tons of lines of code in VB to get to the same as 3 lines of CSS...


This doesn't match my experience, if anything the other way around.

CSS back then was a lot harder than it is now. There's still memes around this, but even something as common as centering an item with CSS was not trivial at all. Now we have flex and it's easy, but back then it was very much not.

VB didn't work on the same paradigm - it was a more WYSIWYG environment. You drew a button on the form, set some properties in the sidepanel, and that's that. Notably there are zero lines of code involved in this, so the whole "you have to write tons of lines of code in VB" is simply not true. Possibly you're thinking of its successor, XAML, for which this is true.


Having worked for 10 years on both Delphi and VS, I understand the experience you are talking about. Having the ability to draw UI is amazing, and super productive. For business applications, it is amazing.

However, I still remember at around 2002 that we where asked to build specific custom user experiences, I think it was around reports, and using VB or Delphi was a lot of programming using draw commands... while using HTML and CSS it was fairly easy, even with the browser differences of CSS.

Any custom component in VS or Delphi (I am talking atomic components, not composite) requires using basic draw commands, and a lot of them.

The end result was that both platforms are not as expressive in terms of UI as the web, you cannot compare basic draw commands to structured CSS.


Reports, yes, that was a pain in the arse. Anything where you had to generate controls on the fly based on data was painful. Crystal Reports was both a nightmare and a lifesaver at the same time. I always thought that someone should do a better job of it, but I did not want to go there ;) By comparison producing a report (or anything data-generated for that matter) in HTML was easy.


These tools were built for GUIs, not typography where they were very weak. They outsourced document production to other tools like Crystal.


can vouch on this, since originally I really prefer WYSIWYG UI (VB, C# winforms, wpf) over web early. However security-wise it's hard to enforce when using them, since they don't really operating using client-server by default, having your backend logic prone to be reverse engineered.

This doesn't happen in web apps, since backend logic stays on the server. Whipping a html UI over the already server-client architecture is easier. In addition with ease of deployment of application making web apps very favorable.


VB and Delphi reference architecture was 2 tier - client and database. With this reference architecture, you are right about the security and distribution problems. You just reminded me of the shareware market and the hacked shareware markets...

However, early on, around 1998, people started talking on 3 tier architecture of client - server - database on both platforms. There where even attempts to build web pages using both platforms (and later on .Net), which failed because of a lot of reasons, one big reason was not understanding the advantages of CSS.


Yes and nowadays there's nodejs with react, where there's javascript on both client and server, with addition of html and css making desktop app that's not multi platform, almost obsolete.

Which is why lately companies are trying to use electron or react native to replace them.


I opened VS and looked at WPF again the other week. It was a surprisingly pleasant experience. Though my C# is sooooo rusty now (and not in a crab-like way).

I wonder if there's a market for "WPF for Golang"? ;)


Visual Basic (both of them) still exist, but their use has dropped dramatically through some big changes:

* "Visual .NET" (aka "Visual Fred" http://catb.org/jargon/html/V/Visual-Fred.html ) was released by Microsoft. This was an incompatible language confusingly also called Visual Basic. I don't think Microsoft realized how angry this made developers and businesses, who were being asked to spend hundreds of billions of dollars (USD) to rewrite code just to keep the same functionality. Before that time, many thought that Visual Basic's wide use gave it a kind of "herd immunity". I don't have numbers with me, but I remember that years later that a study found that some were sticking to the original Visual Basic (even though it was no longer supported), a few had moved to Visual .NET, and many other had abandoned Visual Basic entirely (some to C#, others beyond). In short, the Visual Basic community was split into multiple communities, and anyone using Visual Basic would have to worry about either lack of support or yet another harmful change.

* The rise of the web and of platforms other than Windows (including Android, iOS, MacOS, Linux). Visual Basic is fine when you send files via sneakernet to another Windows user. Now people want to access through their web browser, smartphone, etc. If you have a website, anything can access it (as long as they have the permissions), and you don't have to worry about synchronizing data changes the way you do if people make changes on their local device. Most of the simple "fill in a form" kinds of applications that Visual Basic was used for are more sensibly web applications (server side or client side).

Visual Basic is still used. And yes, I think there could be better tools for developing software. But as best as I recall, that's how we ended up here.


As someone who was writing Visual Basic.NET back when it came out, there was no upside to it over writing in C#. VB's original sweet spot was for writing small scripts and apps in Windows, and it was the only language available. When the .NET line came out, you could do the same things in whichever language you wanted. When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.


> When new tasks came in, I started defaulting to C# for that reason. I don't think anyone actually prefers VB syntax. C# has a pretty robust community around it now.

Which was your experience because you knew C. VB appealed to people who were not programmers (or not very good ones like me). Microsoft effectively tossed an easy to learn procedural language in the trash and said "go learn all these advanced CS concepts or stop writing stuff" to which most hardcore VB users chose the latter.


While maybe that's true, that doesn't map to my experience very well. After QBasic, I wrote a lot of Visual Basic 5 and 6. I had poked at C, but would not say I knew it, and had never done anything useful in the language. But I did exactly one thing in VB.NET before trying C# and realizing that it really did encapsulate and present a better way to think about code. It's not perfect, but it's much, much better--and in that era, .NET 2 or so, it was significantly more ergonomic and had better tooling than Java or PHP, the other two languages I learned about contemporaneously with C#.

Maybe there's a mass cohort of people who were simply not going to learn something new, but in the light of most of twenty years hence, I think that they made the right call.


I've worked with a ton (too many) VB programmers by virtue of the work that I do (UI automation).

My experience all suggests that pure-VB (even .NET) is a treacherous dead-end, because it doesn't scale in terms of complexity and project size, and the point at which is stops scaling is often unrealized by its developers.

- VB(.NET) is amazing for small, simple gadgets.

- VB(.NET) is terrible for large or complex systems.

The problem is that VB is likely to be the only programming language that developer knows (moreso than developers in other languages).

Consequently, when they reach the end of the reasonable VB road... they will NOT say "Oh, I should learn C#."

They will say "How can I make this work in VB?"

And that's when you start to get business-ending unsupportable messes of spaghetti code that just barely work, on a good day.

Give a person only a hammer, and they'll find a way to make the entire world a nail.


> VB(.NET) is terrible for large or complex systems.

This doesn't make sense to me. I worked in a 50/50 VB.NET/C# codebase for years and while I don't love the VB syntax, the two languages were 99% interchangeable. Nearly anything you can do in C# you can do in VB.NET, and vice versa.


Lol, it doesn't scale because of the quality of the programmer, not because of the language. There may be some self-selection there but it isn't because of the language or tooling. Any "too easy" language brings these comments. People complain about MATLAB too when in fact there is nothing wrong with it or VB. Of course you can abuse both for purposes they are not meant for.


> VB(.NET) is terrible for large or complex systems.

C# and VB.net are semantically 100% identical. Only difference is surface syntax, like begin end instead of curly braces. It scales exactly as well as C#.


> - VB(.NET) is terrible for large or complex systems.

I can't say I agree with this. My experience has been that developers who write things in VB tend to be self-taught and don't know how to scale up small gadgets into large systems.


> VB(.NET) is terrible for large or complex systems.

Compared to what? It got support for multiple files and even luxuries like namespaces.


I prefer VB syntax :) I'm not a fan of semicolons and curly braces.


> As someone who was writing Visual Basic.NET back when it came out, there was no upside to it over writing in C#

Sure there was: C# didn't exist yet. It didn't exist for many years to come. It simply wasn't an option. C/C++ was, however.


You may be confusing Visual Basic .NET with Visual Basic 6 and its predecessors. C# actually predates VB.NET by about a year.

VB.NET may be syntactically similar to VB6, but under the hood they were so different that migrating projects to VB.NET essentially meant a complete rewrite.


Visual Studio had a built-in migration utility which could get you 80-90% there. However if the original VB6 was spaghetti code written without Option Strict and Option Explicit enabled you had much bigger problems.

The biggest breaking change was the removal of the global Printer Object so any printing code needed a complete rewrite.


My recollection is that the migration tool was really just a tool that would fill your VB6 code with comments telling you that you had to rewrite stuff. Trouble spots were largely related to error handling On Error Goto and error handling blocks had to be refactored into proper Try...Catch blocks, which affected a lot of code, and another trouble spot was all File I/O had to be rewritten/redone, same with any drawing code; Resource files had to be recreated, etc; I don't even think it could load the FRX files but I might be misremembering. I felt it simply wasn't worth even bothering to try to directly convert to VB.NET, and since those programs I wanted to move forward I had to pretty much rewrite anyway, I decided to use C# instead and just make new versions.


The migrated VB6 code I saw back in the era when VS2003 came out was a thin glue layer over some compiled DLLs. So the result of using the converter was a thin VB.NET wrapper around very outdated, vulnerable, unsupported third-party code.

Maybe other shops had a lot of pure VB6 code, though.


VB.NET and C# were released concurrently, weren't they?


Yes. I thought he wrote VB, not VB.NET.


Visual Basic is one of the best arguments for open source and community ownership in the history of computing, IMO. Microsoft's decision to tank it was hugely painful for companies that had made major investments in it -- no company should make that kind of investment in a proprietary platform that can be killed off by a single company and not forked and maintained by others.


I totally agree with you, but unfortunately the lesson was not learned. Now in the back office you see "standard" software with their own scripting language, e.g., APAX in Salesforce, or ABAP in SAP. Which is seen as a step forward, which it is architecturally, but not the point that you rightfully mentioned. On the other hand, all code is cyclical, if someone were to make it in Python, that would have to be rewritten, too. At least if you go the Free Software way, you're free to choose when.


Lol, my first programming gig as a teenager was performing a VB6 -> VB.NET "upgrade" of a 200K sloc legacy desktop application, which obviously ended up being a total rewrite. Everything in my career since then has seemed easy in comparison.


If this was mine, I'm so sorry :) Just kidding, I actually know my VB6 code is still running in prod.

VB6 did let me learn to program very valuable utilities from scratch, with practically no programming experience. I probably owe my entire career to it and VBA. I took a C++ course once and it nearly turned me off of coding completely. VB6 saved me.


I learnt VB6 when I'm still 10 years old and all seems so simple and magical. Then I encounter "Visual Basic" again in high school and it's almost unrecognizable with all the C# nonsenses. I still don't enjoy programming GUI like I was in VB6.


I was a hobby VB developer at this time and I abandoned it shortly after VB.net without really realizing why. I also abandoned Windows completely shortly thereafter.

The main thing that killed me was the size of the files that you had to distribute when you used VB.net. No one had the .net runtime early on and it was absolutely massive. I was paying for outgoing data by the gigabyte back then and our connections were much slower.


If Microsoft had simply ported Visual Basic in a compatible way to .NET history would have been very different. What's the point of the common language runtime when all the common languages are just reskinned C#?

This was a major missed opportunity for Microsoft -- if they had brought Visual Basic proper in .NET it would have given hundreds of thousands of applications a smooth upgrade path into modern development. It also would have given the entire Office suite an upgrade path from VBA to .NET -- something they've still not managed.

To this day, our office still has one critical commercial 3rd party application written in Visual Basic. It's replacement is, of course, a web app written in .NET.


> It also would have given the entire Office suite an upgrade path from VBA to .NET -- something they've still not managed.

> To this day, our office still has one critical commercial 3rd party application written in Visual Basic. It's replacement is, of course, a web app written in .NET.

seems like they did, they just didnt care if it remained in office, and it seems the author didnt care that they got screwed over by microsoft :)


Yeah, as someone who worked somewhere that had a VB6 project: VB.net was only at all useful as a stop gap between VB and C# and a barely useful one at that.

The language as it stands is fine and interop with .NET means it is a decent choice to use, outside of C# just having a bigger user base from a "how easy can I hire devs" standpoint.


I wrote Dts package scripts in Vbs but had primarily used C# for application development. When Ssis came out with Sql Server 2015, they only released Vb.Net for scripting components. It wasn't a natural transition from Vbs -> Vb.Net so we ended up writing libraries in C# and using those in Vb.Net. Brutal.


ASP & ASP.NET

You forget to mention those two, which are important to the history of events.


I was using Visual Basic 6 for throwing GUI's together. I loved how it loaded and iterated in one second on a 400MHz P3. Then, we got Visual Basic .NET. It took forever to start up. Then, it wasn't really Visual Basic. Then, iterations were slower.

It was going to be a rough trip. I figured I might as well learn something different so the headaches have more of a payoff. I stayed on Visual Basic 6 for a while before quitting it. I'm using Python now and it still doesn't feel as easy as VB6 did.


Great points. And in a tongue in cheek way, having reactive components you can attach handlers to fetch / redraw you UI .. is still there, it's just labelled vue or react ;)


The reason is even bigger than just VB.

MS at the time just decide to fully kill the "enthusiast" developer and the "single/truly small" team developer. This is mostly covered under the "RAD" umbrella.

It kills VB, FoxPro, and now more evidently, Access (more like let it slowly die).

.NET + Visual Studio + Sql Server are not a substitute in this market. Them are for "professional developer"/"a small cog in a big machine". The worst part is that this move somehow kill the other tools in this space (because somehow others follow suit or whatever) and without somebody leading the charge to see how adapt this tool for the web. MS not getting the Web, Borland doing Hara-kiri and others getting annihilated by "free" open source and all that not helps.

Ironically, this market have rebound in the myriad of tools like "low code, notebooks, etc" that fill (badly!) the gap.


Serious question: what is a good alternative to Access (edit: to build a GUI frontend to a database)? The database design tools and basic forms were incredibly easy to use, and there were very good tutorials for everything else. LibreOffice Base is different and not even close in comprehensiveness, and there seems to be nothing replacing it that isn't a super expensive SaaS.


LibreOffice Base is... okay. It's not great but I was able to do most of the things I used to use Access for (simple small CRUD database tools that let you quickly build forms, simple table relationships, enter/review data, generate reports). Basically, it's better than nothing and nothing is what we've got now. Base can get pretty confusing at points and has given me a lot of head-scratchers at some times.

Even with otherwise seemingly easy-to-use web-based improvements to Excel that my employer has like smartsheet... these don't seem to let you do any sort of super basic many-to-one relationships (maybe with some expensive ad on package? dunno... and smartsheet has plastered their site with a bunch of 101 intro to databases SEO spam that explain what different types of relationships are rather than how to fucking build them with smartsheet)


> what is a good alternative to Access (or Fox, I add)

Nothing.

Access is(was) in fact a worse alternative to Fox:

- Much worse DB engine, and that is saying a lot (FoxPro db can and get corrupted. A typical functionality that was added to any fox codebase was a utility to fix it)

- MUCH MUCH worse programming language (VB) that is neither good as-is, much less as a data-programing language.

Fox/dbase is the only data-oriented language that was relatively popular and fit for the use-case.

This is by a mile the main point: Is a desert looking for languages that are made for business app/data oriented programing (and much harder looking for something not weird).

The main options: Fox/dBase/Informix(? not remember), kdb+, Cobol, SQL(when extended as store procedure lang with loops and that)

--

This point is big. Having a good form builder (that is already rare) is not enough to be a real contender for this space. You need a language where making queries is truly nice.

In short, you need a language that is `LINQ/Relational` as first-class end-to-end.

- If this lang needs an ORM: FAIL.

- If this lang needs to compose strings to make a query: FAIL.

- If exist "impedance mismatch" between data manipulation/queries and the rest of the lang: FAIL.

- It should also support super-advanced types like date, decimal, currency and ideally dimensional units. Ideally algebraic types as today.

- It should have a version of Rust `serde, Into/From` traits, for easy conversion between data + formats.

- It should look "normal" like python/swift with `LINQ` queries.

This is the lang I trying to build: https://tablam.org


As someone who loves LINQ, this is really cool, best of luck with your language! There is certainly a void that is waiting to be filled by such a language.

Although as other said on this thread, the real killer feature would be a form builder as in foxpro etc. It can be somewhat primitive, as long as it's easy to build and extend. Ideally the forms should be web based.


Sure, the UI side is pretty important!

But I try to get a good companion for it, so it get good synergy.


Looks alot like Lua!

and thats not a bad thing per se


SQLite. It's not close in terms of ease-of-use of the GUI administration and forms, but as a single-server database solution to embed into a line-of-business app it's fantastic.


The GUI and forms is what made Access, though. Back in the day I actually made a system with Access that connected to a SQL Server database on the backend rather than Access's file-based engine.

It's a real shame Access died, now there's no path from a spreadsheet to something more sensible.


> It's a real shame Access died, now there's no path from a spreadsheet to something more sensible.

Although it has certainly died in terms of mindshare, it's officially still supported for PC (not Mac):

https://www.microsoft.com/en-us/microsoft-365/access

I actually have it installed right now, because it comes with Microsoft 365 Family, which I have on the Windows PC on which I'm typing this comment. I haven't used the modern version of it, though.


...it's fantastic if you are able to live within its limitations, primarily being a single writer.

If your application grows into the need for concurrent writes, then it will be time for another database.


You may be surprised at how far you need to grow to truly need concurrent writes. Blazing fast sequential writes is good enough for the vast majority of applications


I know how to write a Django app with a SQLite backend, but that's not what Access does.

There are basic SQLite GUIs, but they have no reporting functionality and no customizable forms.


This is so true.

A cross platform Access-like front-end that used sqlite as the data storage engine would conqueror large parts the territory.


Budibase looks really impressive, basically a GUI frontend builder for postgres and its open source. Haven't actually deployed it, but played with the GUI builder and its nice.

There's a few other similar ones out there too like Baserow [2], Appsmith [3] and nocodb [4].

Finally, if you wanted a step up, then I guess supabase [5] would be the next one up but its more like "I just want to write front end and have auth, database, API and storage taken care of for me"

But none of these really give you that all-in-one database and front-end via files like Access did and its a damn shame. Yeah I know Access lead to some god-awful applications, but honestly the people complaining about shadow IT don't realize that its inevitable if IT isn't fixing people's problems. You just need to be clear that if the business unit goes down that path, they're on their own. So if the guy who built your crazy Excel VBA app is gone, don't expect that to be picked up by others just because its super important. But, if it is in fact that important, then its probably a prime candidate for actual development work, so the duct-taped together things do end up being sort of testbeds for whats actually important.

The whole lowcode-nocode shtick is a bit oversold, but one good aspect of it is that if you allow for an easy onboarding sandbox for the type of person who would otherwise make an Excel VBA app, at least some of these platforms have sandboxes with guardrails and other compliance stuff you can apply.

[1] https://budibase.com/ [2] https://baserow.io/ [3] https://www.appsmith.com/ [4] https://github.com/nocodb/nocodb [5] https://supabase.com/


At least Access has a sound model underneath. Excel is nothing but a damn grid, while Access has tables, keys and constraints _and_ a visual GUI builder on top of those. The development environment was an only slightly pared-down Visual Basic but it was fully integrated in the rest of the GUI, while VBA always felt like it was tacked on the rest of the application.


Equally serious question: what is the use case for Access?

It's been installed on every corp workstation I've had and it's never been useful. In my experience either Excel can do it or you need a real programming language/database.


Access allowed maintained "relations" between tables, so you didn't need any code to have a master/detail relationship between tables, it just handled it all. This carried over to forms, queries, reports, etc. You could have a system with data entry, master/detail records, queries and reports built in a day, all without ever doing any SQL.

Through ODBC, you could connect to pretty much any database around. I think Office 2000 Professional was one of the best products Microsoft ever produced, it's all downhill since then.


Past tense? For PC users (not Mac), it's still supported and included with Microsoft 365.


I don't have Office 365 any more... so I wasn't sure... Microsoft seems to slowly be killing functionality in everything, so I couldn't be sure.

Also, things went downhill when they got rid of full menus and introduced the accursed "ribbon".


I know of small companies and charities that would use Access as their homegrown CRM back in the 2000's. It worked really well, you just needed one guy who'd be willing to set it up and they'd be good to go with the basic forms for a couple of years usually.

It's definetely not great by todays standards when it comes to backups and what not, but it was really fantastic at the time.


Access had a very low barrier to entry and sanitized inputs. Excel doesn’t cater to minimally skilled people who want to hand off forms to someone else for data entry.

Why is this zip code a phone number? It’s not the users fault, your using the wrong tool.


Access was an app you had installed on your workstation but never opened because in the backend every late 90s early 2000s desktop app was using it as its data backend.

Between Excel (with no functional API to use for storage) and a "real database" (your users now need to ask IT to deploy SQLServer) was a use case of app just needs to store persistent data for a single user.


I remember there was at least one video game (some turn-based tactics game, don't recall the name) that had Access as a savegame format. It was very convenient to edit the save file.


So basically the SQLite of its day?


Acess allowed you yo build small forms/apps fast.

Those business apps made "by that one person" that allowed few other to input data concurrently (back then no google sheets / shared Excel... which are horrible and have no user defined GUI) and then to make reports.

Also data manipulation when it didnt fit Excel (I know access has 2gb limit, but it was a lot).


SQLite with a somewhat usable GUI ...


Prototyping - occasionally when starting out on a big in-house development project, we'd task one or two guys to build a prototype in access to understand the challenges, functionality, data issues and get user feedback on what worked and what didn't. Invest 3-4 weeks of effort that saved us months of effort from the project overall and de-risked the project substantially. One time it back-fired a bit when the users liked the access proto-type more than the final system (pushed the envelope a bit too much and the performance was very poor), but typically got plenty of value out of it.


I used it to create a detailed opinion of cost with recursive summing, so that item costs were summed per section, section costs summed into summary costs, summary costs summed into project cost.

No other document designer that I'm aware of allows for runtime integration of variables into the layout/presentation.


Seen a lot of screw-up by someone taking a databse export (csv or whatever) into excel to work on it, sorting but only sorting one column leading to disaster.

This is just unbelievably /common/.


Airtable is the closest I have found for ease of use - users that don’t know SQL can put together basic queries and views quickly.


1000 records per table on the free tier is ridiculously low, it basically makes many to many relations impossible. It also doesn't have reporting, and I have no need for attachments.


PowerApps probably, and with the transition to the cloud Microsoft will probably not invest too much into stuff that can't run well in a web browser and mobile app.


A monthly subscription is a non starter for charities and also it needs a work or school account.


Last I interacted with Microsoft they were quite generous here. They have special pricing for non-profits and they definitely have a whole different structural thing for schools


The parents point is that there is no alternative, because everyone left the market chasing Microsoft.


For a long time I would have said FileMaker, but considering the strategic moves of Claris in the last few years probably not anymore


maybe SqlServer Express ? It has limits on memory and DB size, but if your project is small it might suffice, in conjunction with Management Studio Express.

I've never used Access so apologies if you're looking for more than a GUI-driven interface to the DB.


SQL Server Express is just a (fairly generous, last I looked!) limited version of the full SQL Server.

So, it's a substitute in terms of affordability. But absolutely not in terms of "rapid GUI application development" for the non-programmer.


It is not. Access was easy to build the app on top of a reasonable database seamlessly, integrated, visually. SQL Express is just the database part and there is nothing that integrates so well on it like Access does internally. Access is not powerful enough for larger databases, but boy it was easy to use for small ones.


Maybe:

a) https://www.nubuilder.com

b) https://gambas.sourceforge.net/en/main.html


Also:

c) https://github.com/twinbasic/twinbasic

Once it gets out of beta.


Check Filemaker. A friend of mine is a 100% Filemaker freelance. Apparently it can also generate web sites over the data in its db.


There is no good alternative, really.


Filemaker?


Jesus Christ, not FoxPro.

I briefly worked for a company whose main product had been a FoxPro application that they rewrote piece by piece in C#, reimplementing various FoxPro idioms as they went. It was a nightmare and no one knew what any of it did. One "senior" developer tearfully argued with me during a code review that even fixing comments could have dire consequences.

I suspect that someone higher up liked it that way, because I was fired shortly after mathematically proving that something was really wrong in some of the accounting code.


Well, no programing language is good for data applications as is FoxPro (certainly not C#), and is terrible to writer LANG-a in LANG-b.

So sorry for you to get the worst of both worlds!

P.D: I do a port from a Fox app using idiomatic C#, like 10-30x the size of it, but well it was idiomatic!


All the consumer products were killed, like Encarta, games, Microsoft home stuff. MS went full enterprise.


Vscode supports many enthusiast development stories.


Does VBA for Excel count? Because if it does then VBA for Excel has reached the"nuclear resistant cockroach" level in finance.

You wouldn't believe what sort of processes in very big banks/financial institutions are built using 10 year old VBA macros. In fact, VBA consulting for finance is a very juicy cottage industry at least in Europe to this very day.


Excel is literally 2D programming. Us mortal developers who can only put lines below one another are incapable of comprehending it, so we only get to ask the wise finance people how their enigma works.

On a serious note, I dread excel. If your PC is set to german, excel will translate the VBA keywords to german. But if you want to type them, you have to do that in english and then have excel translate them.

I don't want to accept that crap like this is the standard.


I have grown a respect for Excel in the last decade or so. It's slow, it's clunky, and it's far from perfect, but I think it's among the most approachable language out there.

A lot of people using Excel, even some of the more advanced stuff like if statements and logic, don't even realize that they're writing programs, and I think that's genuinely awesome: people are able to utilize the power of programming by accident.

I still use spreadsheets all the time for small number crunchy things, just due to how it's "reactive by default". I find it's actually really useful to immediately see everything update after changing a value. Admittedly, I mostly use Google Sheets nowadays simply because it's "good enough" and much easier to share with friends. Could I write a program to do all that number crunching that performs better? Obviously yes, I could start a new Julia project and mop the floor with Excel or Google Sheets in regards to saving cycles, but that would take me 20x longer and I'd lose all the nice features of a spreadsheet.

Granted, this is coming from a strictly Anglo-American perspective; I cannot speak to Excel's ability to use other languages.


Gnumeric is actually a good excel. The stats routines are shared with R so if ever someone demonstrates a bug, it is fixed!

Free, fast, accurate. Pick any three!

http://gnumeric.org


> I cannot speak to Excel's ability to use other languages.

I find it's an overblown issue. Those of us that prefer functions in English can just set Excel to use it. When someone sends you a file it displays in your chosen language. And having the default being localized makes it usable for the majority of people who don't speak English.


I find a spreadsheet (Google Sheets will do) is a great thinking tool. Any thinking will involve probably some maths and some tables. Excel is built for both.


> Us mortal developers who can only put lines below one another

At least my spaghetti code goes into one direction only...


Yes, but I bet your code cannot reveal its own spaghetti:-)

Excel has long had an option to display 'precedent' and 'dependent' cells.

You can actually see the spaghetti right there.

https://support.microsoft.com/en-au/office/display-the-relat...


Now do that for the VBA!


Excel is a quite powerful mix of declarative programming (formulas in cells), and imperative programming (VBA procedures, event triggers, etc). If you're not ready for it, it'll break your brain.

The main danger in Excel is that any area of a sheet can be treated as a pseudo table.... except it really isn't, and you can inadvertently sort some fields, while leaving the others alone, effectively scrambling your data.


With side-effect free functions: https://youtu.be/0yKf8TrLUOw


The 2D aspect is the part of Excel I don't understand. Why does it have to be a grid?

It's great for laying out things meant to print, and making invoices and stuff... But why didn't we have code files and proper fixed layout DB-style tables as "pages" that can go in a workbook?

Maybe keeping everything as 2D as possible is a necessary compromise for the spatial thinkers out there, and they just wouldn't want it if it was full of boring linear stuff.

I love the reactivity and the concept that anywhere you put a value, you can put an =expression. But the 2D stuff seems like it's for the people who always have a sense of where things are in space.

They've done a good job of convincing people that it's not programming and they can do it, I can't really complain, because if Excel didn't exist we might all still have to use paper on a regular basis, or completely unstructured text files.


This is why I'm fanatical about using proper Tables in Excel wherever possible. Any db-like kind of data is first turned into a table, then I work with it using whatever formulas, code, or tools I need to. Half the time this means dropping into PowerQuery to do more transformations on the entire set, then finally using Excel formulas or pivots as needed.

But I really like Excel for allowing me to just plop stuff down wherever when I'm brainstorming something, or just want to do a one-off calculation before I quit-without-saving.


> Why does it have to be a grid?

Because we have been doing it that way for almost 4,000 years!

https://en.wikipedia.org/wiki/Spreadsheet#History

Humans have organized data into tables, that is, grids of columns and rows, since ancient times. The Babylonians used clay tablets to store data as far back as 1800 BCE.[16] Other examples can be found in book-keeping ledgers and astronomical records.[17]

Since at least 1906 the term "spread sheet" has been used in accounting to mean a grid of columns and rows


It’s because Excel sheets are often used like forms to fill some fields in, with labels, and dedicated formulas in the background. And sometimes part of that form is a table, but also graphical charts etc. on the side. Excel sheets can be designed almost like in a layout program, also to be suitable for printout. People like that freeform spatial-thinking flexibility about Excel.


It's amazing as a layout program for sure, as long as you're not going to interact with it much on mobile.

Then it's pretty bad but still better than writing some custom software like people would probably do without it.


When doing calculations on paper, you can write your interim results anywhere. That's what excel copies. It's also why text in excel files will gladly overflow into adjacent cells.


The overflowing text isn't actually stored in the adjacent cells, it's just displayed on top of them. The difference is important.


That kind of thing seems very natural if you've done any calculations on paper recently(Which most business people have) but seems strange to programmers who haven't.

You would think the ideal would be to allow everything Excel currently does, but also have some other model with more separation of code, data, and visuals, like node-based programming and separate cloud-synced pure tables.

Excel can almost cover a lot of "real programming" use cases, but not quite. The upgrade path seems to be Excel to Access to Custom app, rather than Excel to Excel but with more of the advanced features.


Everybody who replies to you, I think, has gotten it wrong. What you're asking is not why any grid, but why an infinite un-malleable grid.

What you want is the paradigm of Numbers from Apple. Their office suite is good, and it has the benefit of being opinionated. They're not trying to ape Microsoft, like all the open-source projects.


"2D programming" is normally called array programming, and it's common in scientific computing, ML, and finance. It does require a different mindset, kind of similar to SQL but not exactly. See APL, K, q, NumPy, matlab, Julia, and friends for languages that embrace this paradigm


I don't think you're talking about the same thing? The parent poster is talking about Excel's ability to spread computational steps across rows and columns (i.e. the structure of the code itself), while array programming traditionally refers to writing computations over arrays (i.e. the structure of the data)


> But if you want to type them, you have to do that in english and then have excel translate them.

Huh? At least in the versions I've used I've always needed to type the commands in German.

There's even an online German - English Excel dictionary...


I wittnessed this very fuckery with my own eyes just two weeks ago:

It was an excel file created in pandas that threw an error on english commands but worked if the code included german ones.

I don't know how or why that happens, I just know I need to get away from it.


I can't understand why so many finance people won't just learn SQL.


SQL is not a replacement for Excel.


Not a replacement, but it should be used for sharing data and reviewing your logic. Table joining is just plain easier in SQL.


I know of a restaurant franchisee with 170+ locations that uses a home grown ERP system built in VBA on top of Access by an accountant about 20 years ago.

I once had to update it to optimize (minimize) front-line staff working hours so the company didn't have to pay health insurance for those employees. A real nightmare of a task in more ways than one!


My first programming job in the 90s while I was still in college was building systems exactly like you describe (and they were as poorly built as you think hah). I worked for a small IT programming/consulting shop. We did small jobs like this in town in addition to installing networks, IVRs, etc... while working on larger software to sell (which is an entirely different/crazy story that involved burning CD demos and using a hand 'stomper' to label and then mail them out).


In high school I got a gig rebuilding a pre 2000 Access DB + VBA front end in office 2003ish due to some kind of incompatibility that was preventing them from upgrading their PC's.

It was a chemical safety database. It was used to identify chemical risks and track the storage of the chemicals.

I pray near daily that someone else came along years later and rebuilt it in a modern language.


Ah yes, where testing just means "I hit save on the live database file and didn't received an angry call from accounting 2 minutes later"


One of our clients runs everything on access; from the office security, factory automation, ERP, crm, hrm, cms and more. We are moving them to a cloud platform that will allow them to not change one thing but save them a fortune not having to deal with the many issues access has.


This post has more information than you realize.


What do you mean? Are you suggesting you can figure out who the company is?


I have a guess, but don’t want to offend the big cheese there so I’ll just see how this plays out.


Healthcare and insurance too! I transform into some glorious magical elf when I volunteer to do the VBA tasks nobody else understands or can lower themselves to do.

You can make Excel do some real wacky stuff. I have a spreadsheet that actually calls out to exec() to run a curl POST on commandline and consume REST API endpoints, parse the results, and update the spreadsheet -- why on earth?? because the API was ready but the web app was delayed. I was the fix. :D


Pretty sure you can access a REST API from VBA without resorting to exec()


It only works with toy examples and then stops working. For reasons unknown, as it should work.


Never had issues with the standard VBA HTTP Interfaces


We support both mac and pc excel -- the mac VBA is seriously gimped.


Pre-face: I write a lot of VBA

VBA is kind of the result of people only - ONLY - wanting to use Excel for everything. I work with those people. They have mastered excel, but have little to zero interest in learning anything else, and would rather see the world be built around excel.

So you (like me) get tasked with building applications and forms in VBA.

I was STOKED when MS announced Python for excel, but alas, turned out to not be what I (and many other) wanted.

What's the medicine? Dunno, hire analysts that are more open to using other tools . Don't get me wrong, I love using excel for many tasks - but damnit, it's not the only tool.


The company I worked for in college was in the "VBA for everything" world. It was like the Renaissance when they started experimenting with Power Query for some use cases. (Which, honestly, was still a terrible language. But slightly more maintainable than VBA.)


VB is not VBA, VBA was a relatively small subset.

I might be mistaken but wasn't VBA brought into Excel as a familiar element from the VB world?

It is true though that some of the more purer or more initial concepts of VB likely live on in the VBA subsets of Excel.

And Access.


VBA works fine if you want to create macros and automate various things for your spreadsheets, but the problem is that the end user want / demand full-blown applications layered over their spreadsheets. The last thing I worked on was a CRUD -interface where the user could read and write data from their spreadsheet, to a azure DB.

It wasn't difficult, but at its core, I had to do it because the end users didn't feel like using some other interface - they really didn't want to leave their excel spreadsheet.


There is a book called: Professional Excel Development. If you want to get into it. You could probably use that book to build an OS in Excel. I'm not joking.


This sounds like it would be right up my alley. I'm not a professional developer of any kind but have done hobby coding on/off for years, and I'm better at excel than the average user.

Currently working for a consulting company with a whole region's health system as the client. They use excel for lots, but it's all very basic stuff. I had one of my team members spend an hour whipping up an excel form for them that auto generates letters to different departments with all the necessary information. Even some basic standard work forms, let alone any sort of automation, would help them a lot as they rely on people to send certain information that gets missed every time. They described our excel sheet as a game changer for them.

Almost no-one has access to their ERP system which is safeguarded by a certain department which is ridiculous. I'm working on a spreadsheet for their HR team to calculate bonuses for certain employees based on a bunch of variables, then auto-generating letters to review and distribute. The data from their ERP software is such a mess, but I'm making up for it by cleaning up their reports in excel. I plan to get access to their ERP system to look at what kind of reporting I can do as HR only gets a report from the system once a month. I want to help them track real time stats for hiring, etc. And curious if I'm able to connect some spreadsheets to their ERP with an API or something (haven't done anything like that before).

Anyways, that professional development for excel book looks interesting. I see the second version is from 2009 and may not even be up to date with 2007 excel. I'm sure most of the concepts would stay the same though, so I'll definitely have to check it out.

I realize excel wouldn't be considered the most professional or robust way to build applications, but since microsoft 365 seems so standard and everyone uses excel, it makes sense to me why so many organizations use it. There seems to be a lot of potential to apply some excel automation in a lot of industries, especially ones that already rely on it as others have mentioned in this thread. I use it as a means to an end when helping clients, but I also see dollar signs as I find ways to build things that can be applied to so many industries.


Make sure you build subs (functions/methods) for everything....I mean everything. Break all of your code into the smallest subs possible with clear names. Otherwise you will not be able to make heads or tails of your own code in a few months. I built a fairly sophisticated VBA project and left it for a few months, came back and was pulling my hair out. I had to refactor before I could move on, and it was very painful. After the refactor I could make changes and modify it without issue. You have to be, what seems like, over-granular. Its just "clean code" principles: the name of the sub should describe exactly what it does. If the name is too big...break stuff out into different subs.

Excel is perfect for building proof-of-concept apps and Microsoft has a cloud offering called PowerApps that use a somewhat similar "Excel concept." I have built a significant app in PowerApps...not recommended. If you don't have a development team Excel is good. Same for PowerApps. Very painful if they get big. Keep things simple.


It's no more crazy than trying to build an OS out of a web browser.


I keep saying this to all the depressed new and old programmers who believe you cannot make money anymore and it’s all over; there are billions of lines of legacy shite running the biggest companies in the world. Not only Cobol and Fortran, but excel/vba, access, fox pro, and, indeed, old php. Companies have to choose, every year, to rewrite or maintain. I do many projects focusing on maintain; example; my last client had a quite to rewrite his systems in some modern crap (next/react) for a little over 8 million usd (that’s the estimate; not a fixed price and of course no guarantees by the consultancy corp quoting it) or, we will keep their ancient php and Java running for 25-50k/mo (few hours work per year to do that with Docker). I have a very low tolerance for rewrites so we go in hard against companies offering them: we make far far more profit than any of them; we run well over 50% with far less risk. Once I discovered containers (chroots in the late 90s and now docker etc), I knew rewriting things is never needed.


>I have a very low tolerance for rewrites so we go in hard against companies offering them: we make far far more profit than any of them; we run well over 50% with far less risk. Once I discovered containers (chroots in the late 90s and now docker etc), I knew rewriting things is never needed.

Vernor Vinge figured this out 25 years ago. A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://garethrees.org/2013/06/12/archaeology/>

(Heck, just today I migrated a VM to its third hypervisor. It has been a VM for 15 years, and began as a physical machine more than two decades ago.)


My brother is a mechanical engineer and apparently, there's lots of Excel VBA in traditional industries as well.


I can confirm this: I know several mechanical engineers that do mission critical-type systems (think "power plants"), and they routinely use Excel VBA for calculations.


And it's often the best tool for the job


Other than the known calculation bugs in excel that MS refused to fix for at least a decade and probably still 20 years later.

http://www.pages.drexel.edu/~bdm25/gnumeric.pdf

http://www.phusewiki.org/docs/2009%20PAPERS/SP06.pdf

http://www.tandfonline.com/doi/abs/10.1198/tas.2011.09076


It is funny how you talk tjat Excel is bad and the examples just dont work.

Also lack of accuracy in calculating some complicated statistics that "nobody" uses is not really a calculation bug.

Also most of those come from the fact that Excel has a precision of 15 digits.


My fav was when ms announced they'd paid an academic to fix =rand(), ignoring all the others.

Let's see it. Fill the visible part of a sheet with it, conditional format the cells, red for negative etc.

hit f9 to recalc and see a big bunches of cells turn red. Fixed random function to return a random number between 0 and 1.

I haven't worked on gnumeric for a long time - examples came from gnumeric.org

Excel was really bad for everything beyond basic arithmetic, way beyond the important issues with floating poiny listed here https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

Anyone seen anything about ms actually fixing the bugs? I haven't.


> My fav was when ms announced they'd paid an academic to fix =rand(), ignoring all the others.

I am not sure what that means.

Excel keeps all the bugs for backwards compatibility. So the sheets made years ago still provide same results. In few cases the depreciated some functions -> the old ones still work, but are relatively hidden and the users are encouraged to use the new ones.

They probably should do the same with the statistical functions that supposedly have problems due to rounding. But that cannot be fixed - precision is up to 15 digits.

Also if you wanted an article that talks on Excel precision, you can start with the wikipedia page:

https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft...

Excel has many problems, but you linking to few website that supposedly prove that "Excel bad" - but at the same time - those exiles simply dont work, is somehow very funny.


it's the web. links die. There's enough there to find the papers if you care. Which you clearly don't.

>Excel keeps all the bugs for backwards compatibility

They /fixed/ rand(). Announcements. Fanfare. The fixed version returned numbers less than zero.

yet again excel's calculating issues go way beyond double precision floating point truncation.


First rule of Excel development: Don't use sheet formulas, stick to VBA and apply normal dev practices


what proportion of excel use does this? 0.000000001% or not as much as that in your view?


Don't know, but the majority of sheets I've been in contact with (trading desks)


Only last link works


My dad works in Aerospace (though admittedly more on the managerial side, but he still tries to stay technical), and he does all of his initial programming in Excel first, and then will port it over to Matlab if he needs something more code-like.

I've been trying to get him to use Julia for that second step since I absolutely hate Matlab, but I honestly don't fault him for using Excel in the initial phase.


I used it as a coding layman in 15-buck-an-hour "admin" (clerk/secretary) roles to automate some processes that my predecessors had done by hand. Mostly just copying entries from a spreadsheet to company Excel/Powerpoint templates and printing them without killing myself copy/pasting or going into the save/print dialog 50 times. It did its work as something any old schmuck could harness to save themselves from carpal tunnel.

To that point, I imagine that there are a LOT of admin jobs (or, at least, a lot of tasks) that could be almost completely automated away. It's probably not even a capability issue, but one of job security on the employee side and a lack of *waves hands vaguely* on the employer side.


Before VBA for Excel, I wrote numerous macros, including ATAN2(x,y) before there was an ATAN2.

Afterwards, forget it. Maybe one.


So true!!! :D :D :D

If Excel stops working, financial institutions around the world would collapse.


Python was just added to Excel so there's not much chance of that


Really?? Oh, wow: https://techcommunity.microsoft.com/t5/excel-blog/announcing...

Actually that's really awesome, I think.

My goal is basically to never touch Excel again. But, I have to admit - that 2D mixture of data and code called "a spreadsheet" is honestly a pretty cool programming paradigm for a lot of tasks. It can be horribly abused... but so can everything.


And not just old school financial institutions. Jane Street used to run out of an excel sheet. Many hedge funds still do.


I can't imagine Excel without VBA. I tried Google Spreadsheets with js and it sucked big time.


10 year old you say.... office 97.


The productivity wasn't really that good. Rose tinted glasses. All the VB apps I've seen (and still get paid to maintain/rewrite to this day in the finance world) are an order of magnitude simpler than even a simple modern website. They often only have a few users, no devops automation, no deployment automation, terrible logging, terrible instrumentation, no tests, unacceptable access control, tons of failure edge cases, and poor performance.

Most don't even have central databases, they just sit on Access and get copy pasted around like spreadsheets.

While the UI part of Visual Basic was fast and easy, so is writing a React frontend that just stores data in browser LocalStorage, has no authentication, no logging, no monitoring, no tests, and deployment is emailing an updated js file to customers.

The complexity of modern development enables 10-100x better productivity across all aspects of: safety, security, monitoring, error handling, maintenance, and new feature development.

I can whip together a modern website that ticks all these boxes. To achieve the same in VB+Access would be monumental.


I was with you until "... so is writing a React frontend".

No. No it's not. Making a functional UI in visual basic is childs play compared to the absolute cesspit of NIH and feature treadmill that frontend web development has become.

You are gatekeeping with strawmen.


I was trying to compare like for like on features. Slapping together a few fields and a button in react and posting the results to an unauthorized endpoint doesn't feel any more difficult to me than the same in VB.

However, it's certainly an order of magnitude more complex to use react with all the features expected of modern development with design systems, auth/z, logging, monitoring, etc.


I'm deploying react to a CDN for a living, and I would have no idea how to instruct someone to "slap together a few fields and a button" and put it somewhere meaningful. As a kid, I remember making full blown D&D character sheets based on an easy Access backend. You could even print them out.

I want to, but I just can't back any claim that things have gotten easier for pretty much anything. With a ton of extra power on the compute side, parts of the machine have gotten attainable. But nothing about the process is easier along the way.


    I want to, but I just can't back any claim that 
    things have gotten easier for pretty much anything.
I think it's easier for a seasoned developer to spin up and deploy a "real" Djanjo/Rails/whatever app with decent table-stakes features like secure auth.

But everything else is harder.

I have zero idea how to tell a new developer to get started in the hobby/industry these days.

The real problem IMO is the absolute churning shitstorm that is front-end development. I don't know how it got so bad, so quickly, and stayed that way for so long. We as an industry are not going to be happy until it takes at least 50 toolchain steps to produce a simple "hello world."


Getting a rails app up and running used to be somewhat easy. You did have to ssh into a machine, but that wasn't that complicated, all told. Comparable to standing up a BBS way back in the day. Restated, if you could have a machine that was dedicated to the serving of something, it wasn't that hard back in the day.

To that end, I suspect telling people to just stand up a node server is where to start hobbyists off? Still very complicated with the division between front and backend that is difficult to see for new folks.

And I fully agree on the ridiculous churn. Having zero stability in documentation and how to do things has been terrible for our industry. What we have gained in better ways seems to mostly be lost in all of the previous ways that used to work.


A-fucking-men!


And where would you meaningfully deploy a VB form other than your personal computer? Likewise, you don't need to deploy react at all if you are running it locally, just npm start. You can even print to PDF from the browser. You can use LocalStorage for persistence. Feature for feature, it approaches a local VB and Access project for about the same effort. I've taught many beginner students with this technique.

My point was not that modern deployment is easy. Nor that modern react with all the trimmings is easy. My point was that the nostalgic view of VB is reductive and skips all the things we now consider essentials. And for the effort involved, we get much more done now than ever before, albeit at a much greater complexity cost and steeper learning curve.


I'm mostly with you on this, in that running `npm run start` or whatever feels close. However, it doesn't give you the state management in near the same way. Nor does it have anything close to the form builders that you could use back when. Things can feel similar, if you ignore all of the other tooling that we had back then.

Dreamweaver was surprisingly close for building a form or similar. We tossed a lot out the window when we decided to focus on the HTML side of that equation. I swear it is like a lot of the older assembly versus C that existed years ago. Only, we decided that we did, in fact, care about the assembly.


On the other hand, I never understood how to build anything with Access despite having a book on it as a teen.

Web tech, even in its early forms, was much more obvious to me and I could run code in the browser's web console. I could find JS snippets online, paste them into index.html, and open the page. I found VB/Access far more confusing than that.

These days I help beginners pick up web dev and I think HNers overestimate (if not circlejerk over) how hard it is just because create-react-app does a lot of things. Client development always had a bunch of specific knowledge you had to learn, and the fat stack of supporting software you generally use (IDEs, Xcode, node_modules, SDK APIs, browser APIs, etc) was always a behemoth.


Access was the hard part of those things. Using a form builder to get a basic form up and build some interactions, though, was trivial back in the day.

Were there complications? Of course there were. Would I recommend some of those practices to build something? Not necessarily. But I can't get behind any claims that we made any progress on making things easier for hobby programs.

Closest we have to that, would be the scratch programs my kids have been making.

Hilariously, the best thing for making games and similar ideas that my kids would have, is going to be Mario Maker. By a long shot.


I wonder how doable it would be to make a drag drop interface for building react complete with double click to add click handler and focus on that new code kinda stuff.


> You are gatekeeping with strawmen.

Love the image. "Hey you! No visual aids go into this town! One more step, and my strawmen will React!" But the accountant with the abacus continued towards the east gate. He squeezed between two strawmen, who didn't React as much as the gatekeeper was implying.


A better comparison is with VB’a spiritual successor: Power Apps.

Not sure, but I think VB is still responsible for most of MS’s security threats even now. It makes sense for MS to try to EOL


I saw a talk on Power Apps at ATL DEV CON this weekend and was blown away. The only downside is it can only be used internally, with AD M365 logins. It won't work with B2Clogin, and it won't work without authentication.

But, that's the only way I used VB6 - for internal software.


What does NIH stand for?


Don't forget that most of those VB apps you've seen were hacked together by amateurs, engineers, business and finance people, not professional programmers. It was great for their productivity. They automated their work, and they couldn't have done it in C.

BASIC = Beginners' All-purpose Symbolic Instruction Code


You should think about what the alternative was at the time: Mostly C/C++

VB6 you would have connected to the db by the end of the day. C/C++ you're still trying to handle WM_ERASEBKGND


Borland was the alternative. You could throw together a C++ database application in a day. And if you used Delphi you even could not justify a coffee break by the long compile time.


Well you'd probably be using MFC which handled most of the windows messages.

Or wasting time figuring out whether you should switch to ATL


Exactly! The little Visual Basic I saw was always and entangled, manually tested, spaghetti code mess. Devs were productive only at the start of the project and slowed down to a crawl as things got more complex.


I make a good living turning VB+Access messes into something modern and stable. After a point it's such a huge mess that it's either rewrite or leave it untouched forever. Sometimes it's important enough to pay someone to untangle the whole snarl of cables and turn it into a modern project that can be handed off to a dev team. Thankfully it's usually pretty straightforward to get all the data out into a modern SQL database and whip up a bunch of CRUD forms in react. The hard part is what to do with all the bad data that is inevitably in the Access database. That often takes the most time, just getting them to clean up all the bad data.


    Devs were productive only at the start of the 
    project and slowed down to a crawl as things got 
    more complex.
...and as your productivity declined, your manager thought you were a dolt or perhaps had some kind of drug problem that was interfering with your work.

Because he saw how easy productivity was at the start ("look! you just draw a button with your mouse!") and couldn't understand why it quickly became a nightmare.


My favorite VB6 moment was as an intern. I opened a project that lived on a shared drive that wasn't in source control. Visual Studio popped up a dialog warning that I didn't have the proper license on my PC for the parts of the app that interfaced with Excel. Then it cheerfully deleted the offending project files and sections of code and saved it. On the shared drive.


Big oof right there. Thankfully, I've never had that happen on the job. The lack of meaningful version control in most VB projects is dangerous. It's like trying to operate a chainsaw without a handle. Whenever I get a new VB project to rewrite I always have to stop and remember "don't touch _anything!_". Then I sneak around like Indiana Jones in a lost temple filled with traps.


Maybe not all apps need the complexity but portability.


Most of those were built by non programmers for "free" (no extra pay).


I think for a lot of purposes, the internet kind of took over.

VB was great if you needed to do something limited to a single machine.

These days, we want data to be available across machines which requires using a network, and the default network is the internet.

If I'm going to be using the internet anyway, I can knock up something in HTML + JS + firebase/whatever data store, and have an application that works on any platform, and is accessible from anywhere in the world. You might need slightly more technical knowledge, but not so much that you can't have a simple CRUD app running in a day or so of work.


I can write HTML/CSS/JS and a few back-end languages like PHP in my sleep but there's no way I could hand-code a web app as fast as I could a desktop app in 1997 using VB.

I would LOVE it if I could, though.


Have you tried https://anvil.works? (I'm a founder!)

It's quite explicitly VB-esque (only using Python), and having a single paradigm rather than stitching together several different programs speeds things up even for those who can write HTML/JS/CSS in their sleep. (And of course, you can drop out to JS/CSS/HTML if you want.) Overall I think the development speed is comparable to VB6.


I started with Delphi 5 and completely share the sentiment of OP, development experience (mainly when building GUIs) was way better back then. For anyone who feels similarly I can only recommend you to look into Anvil. It is a fantastic tool, under active development and with a helpful and supporting community. It allowed me to build web apps by myself that I previously thought about hiring someone for. Very enjoyable experience and of course the fact that I am building web apps instead of desktop apps is a big plus in many scenarios today.

Great to see you here, Merdedydd! I was thinking about sending this thread to you. I discovered Anvil in a similar thread years ago and am very happy I did.


Reminds me... maybe I can finally build that app I couldn't be bothered to build before...


I tried it out and followed the entire tutorial, but the compulsory 'anvil' branding on every free published app kinda killed it for me.

VB never had that.


But VB also didn't host web apps for you including databases, user accounts, email etc. I think self hosting is an option with Anvil by now, in which case you may be able to remove the branding.


It looks significantly better since the last time I checked it - well done!


meredydd, can I host my own instance of an anvil app?


Same. I’m very good at cranking out Tailwind + React UIs, but nothing touches the productivity I had with VB6 or even early C# and Winforms.


Be careful what you wish for: https://www.wix.com/


I've never written VB, but I can bang out a React UI in jsxstyle like nobody's business.

You've piqued my curiosity.


Development in VB6 was basically dragging and dropping controls onto a window or dialog box, setting properties on them, and then filling in snippets of code to tie things together.

And "control" here means anything from simple labels and buttons up to database connections and embedded COM objects.

Literally anybody could bang out a simple Windows .exe like nobody's business.

It would have been really cool if Microsoft included it in the OS like they used to do with QBasic.


Check out Lazarus and FreePascal


You might need slightly more technical knowledge, but not so much that you can't have a simple CRUD app running in a day or so of work.

Well that’s quite a professional bubble you live in. Web dev is truly a frog in a boiling water.

If my VB/Delphi/Access/PIC buddy who made various apps and hardware back in the day asked me for a platform and I advised him to use what HN praises as “simple”, then pretty sure he’ll never contact me with it again.

I mean, yeah, CRUD is not hard to do by tutorial. But he will laugh at my CRUD explanation, because he never ever thought about implementing input <> data channels. It’s akin to positioning heads above a cylinder to fetch a database record.


I said the app was simple, not the stack.

Along with the rise of complexity in tooling, the data has risen in complexity and quantity, as well as the importance of getting it right.

Back then, a dentist, lets say, could get by with a cobbled together VB program for patient scheduling and CRM. Now patients and doctors expect a system that manages digital records in a HIPAA compliant way, can text message reminders to the patients, allows self service on the web, and automatically submits billing details to insurance. Plus, it should be pretty, with all sorts of cute animations!


I’d like to learn how the rising complexity of tooling allows for text messaging, compliance, self-service or mailing(?). Right now this idea doesn’t sound particularly reasonable to me.


You can run a web server for self service, use a job queue on that same server to schedule actions sent to api providers for sms (Twilio) and letter mail (postgrid), integrate with insurers that provide an api if you don’t want to send papermail. All on a single machine, or virtual machine running JS, and serving JS and HTML.

Compliance is a matter of ensuring that you are following correct practices, and possible audits.

In exchange you get a program that can run on any of billions of devices in seconds without having to worry about local deployment.

If all you want is something like VB, you can opt for some of the low-code/no-code options mentioned elsewhere that are built on top of web technology.

I’m not saying that for what VB was used for, it isn’t a better solution. I’m saying that we ask our computers to do a lot more than we did 25 years ago, and tools like VB can’t do as much as the easier to write languages that have emerged in that time.


Yep, this is the right answer. I was there, 23 years ago programming VB6, making apps that were wrapped up in InstallShield, burnt to a CD, and then mailed to our customers. We did do some web things with Apache and some C++ apps interfaced via CGI. But it seemed that overnight Java and Servlets came about and made CGI-bin obsolete and slow as molasses. Add in JSPs and Struts and you had fully functional web apps that were fast and scalable.


> VB was great if you needed to do something limited to a single machine.

VB6 used to work with oracle across network.


Same here, we did a VB6 project that allowed the customer to chat with their remote mortgage advisor using a webcam, around '98.

The client was supposed to go to a local branch of the bank and then connect to the banks HQ.

I have also wondered why the software industry with the arrival of Internet went away from all these excellent tools. Not just VB6, but remember all the 4GL and model driven development tools. All gone and never really replaced.


It was all about the difficulty of actually installing software on all those desktops. The web eliminated all of that.

And it was so easy for ODBC and other configs to get trampled on by users and installers running amok over existing settings.

Everyone was root on their PC in those days. The opportunity for users to screw things up accidentally was everywhere.


My mid-1990's employer had a solution for the installer dilema.

All of our VB programs, com objects and assets were loaded into a MS SQL database table. When our generic launcher program started it would query the database, figure out what app the customer had purchased and downloaded the necessary objects (if the cache was stale). If we accidentally uploaded a bad version, a rollback to a previous version only took a few administrative clicks.

A good part of my job was to make sure that the companies domain structure and network settings were sensible.

No disagreement about how the web is still easier/cheaper to administer from a centralized point.


Well, that, and all those wonderful apps were inherently client-server architectures, with the business logic on the client. Nobody ever built a properly factored, with stateless layering, and high-end scalability on such an architecture. Just trying to keep 1000 clients in sync, so your business logic remained consistent could drive you to distraction; in a truly distributed product with tens or hundreds of thousands of clients, it was impossible.


Nothing about two-tier architecture prevents you from keeping clients in sync, scaling up or implementing business logic.

Consider that scaling your database has to be done anyway. Your web app will bottleneck on the DB too. The only difference is number of connections assuming you keep them open (but there are multiplexers for that, and many business apps don't need them anyway, RAM is cheap enough).

With stored procedures you can implement whatever logic is needed for maintaining your data.


Of course, if you want to twist VB, or Delphi, or any of the client-server construction sets into pretzels, you could build a well-factored system. And yes, your data has to scale to your system size, regardless of the architecture. But if you use any of those tools (the article was about VB, after all) as designed, you cannot escape the problems I outlined. Your business logic will be either entirely on-client, or split between the client and the database, and it won't be stateless. You will have database connections and transactions spanning thousands of client processes directly to the database, with all the scaling and contention problems that introduces. And you will have an update problem, because updating business logic requires you to push changes to thousands of client machines, which may or may not be available and updatable when you go to deploy your new version.

Can you still build a system, and operate it? Sure. A lot of us did. For small to medium scale systems, it was manageable. But there is a reason we abandond 2-tier client server 20 years ago. While it made building CRUDy business applications vastly easier for the developer, it was a systems nightmare.

(It also led to crappy user experience for any application that wasn't itself inherently a CRUD record keeping job, because it inhibited application designers from thinking of the application as anything other than CRUD. But that's a different argument for a different day).


If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continuing (unless it's marked as a soft update, i.e. not worth interrupting the user for). The versioning issues aren't much different to the ones you face once you decide to have multiple web servers and rolling upgrades.


I'm happy for you if that's working out in your enterprise. It was not our experience in the time frame we're talking about (VB was sunset over 20 years ago), and frankly it was not our experience 5 years ago - when we were running skads of applications on Citrix servers so we could have absolute control over the "client" runtime environment, and have the actual on-the-glass experience be thin client.


IIRC back in the day, Windows could not replace a file if the file was open by any process. So an application could not update itself, without doing something like launching a separate "updater" and then exiting.

Another thing people tried was putting the VB app on a network share so it wasn't installed on each machine, but I think all the ODBC and other config still had to be local on each client.

Powerbuilder apps were similar.


Yes, back then it was definitely a huge problem and one of the big reasons for the web's success.


Yes, the common 3 tier app at the time with ODBC to connect to your databases.


More common, in my experience, was the 2 tier app where a (very) fat client directly talked to the db, and all the businesses and data access logic was intermixed with UI event handlers and some stored procedures.


There was a parallel universe where VB was going to be a web scripting language.

That idea got hamstrung by two things:

1) It turns out cross-platform web compatibility was way more important than anything else, so nobody wanted to write web pages using vbscript if that meant Netscape Navigator / Firefox couldn't read them. MS wasn't willing to either let the language go into the public or subsidize developing the engine for other browsers, so the web dev space just kinda... Didn't care

2) It may have hung on as a scripting language for IE-only stacks, but the Microsoft antitrust lawsuit (and subsequent appearance of Chrome on the scene as a better enterprise browser, with its stability improvements and process sandboxing) ended that era.


Does no-one remember VBScript and Active Server Pages (ASP). It was Visual basic as a server-side language, positioned to challenge PHP.

VB made it to the web :-)


I doubt MS was even aware of PHP 1.x when they released ASP back in 1996. Hardly anyone else was aware of PHP before 3.x either.

By the time I found it, PHP 3.x/4.x was such an improvement over classic ASP / VBScript, that I think MS would've done a better job if it was positioned to challenge PHP :)


Oh yes. And VBscript in the browser as well (as long as it was IE). One of their attempts at browser "lock-in"


If you installed ActivePerl or ActivePython (remember those?), IE would also let you use them in the browser too with Active Scripting. It was an ActiveX thing, so only for IE.


HTML, CSS and JS are not the best pieces of technology, otherwise there would not have been a whole industry of tools that allowed you not to touch them with a ten-foot pole. But we are stuck with them at least for a while.


Don't forget that VB.NET was a thing. I worked on a web-based client management system that used VB.NET on the back-end.


It still is a thing. VB.net is a CLR language just like C#. You can use a tool to translate from one to the other and back.


None of the VBA apps I ever saw needed the internet. They were mostly internal apps that connected to a corporate database over the internal LAN for stuff like "keeping a register of who has checked out which van".


Yup, that was also my take. I used to write 'on box' and you communicated between components using Com+, and when you switched to http, there was no reason to stick with just VB6.


I used VB all the way from 1.0 to 6.0.

And when VB.NET came out came out in 2002, that was exactly when all the types of GUI-database projects VB6 was used for professionally, started being built in PHP/MySQL/HTML/CSS instead. The switch would have happened anyways, but the fact that VB.NET wasn't backwards-compatible made it really easy to switch since you were going to have to learn/build something new anyway -- otherwise there probably would have been a somewhat longer transition period. Microsoft really shot themselves in the foot (but the web benefited).

And then on the hobbyist/personal side, that's also basically when casual developers switched from building fun Windows apps to building fun websites.

So I'd mark it up entirely to web programming replacing it on both sides.

As for what a replacement might look like, Google had created App Maker (2016-2020) that got replaced by AppSheet (2020-present), which is the closest I've found for the drag-and-drop GUI/database aspect of VB6. But those have been very much geared towards business development, not kids learning programming. Maybe some parents here can chime in on what their kids are learning to program in?

[1] https://en.wikipedia.org/wiki/Google_App_Maker

[2] https://en.wikipedia.org/wiki/AppSheet


Good explanation. Hobbiest switched. Because IIS and Asp.net run very well with VB.NET. but who could afford that compared to PHP.


The bigger pain point, from memory, was having an ODBC-compliant driver so the OS could actually talk to your DB. That basically meant MSSQL if you wanted to co-exist happily with early dotnet.


Databases access was a mess then in general. But yeah, completely agree with your sentiment. PHP was just so much easier with common databases.


I think the answer is: because Microsoft let it. I'm a big fan of modern .NET, but my biggest complaint is that Microsoft views, and always has, the CLR as the C# Language Runtime and not the Common Language Runtime.

For example, see the relationship between F# and C#. The CLR is constantly getting features that are only to support features in C#, leaving F# in a position where they either don't get the feature, can't add the feature, or begrudgingly add the feature to keep up compatibility with C#, which is something it does take seriously. But this has the effect of "dirtying up" the F# language by either adding features that don't really belong in the language or keeping features out.

The other thing is that C# consistently adds features to itself that are inspired by F#, since F# already implements these features on the CLR, thus showing their viability. So what happens is that C# continually approaches a more bloated language with a subset of it being a poor copy of F#. But then F# gets dragged along towards having a small subset of C# in it for compatibility purposes. So it's simultaneously making both languages worse.

Even the iron languages project that lead to IronPython, IronRuby, etc. was a bit of a Trojan horse to test out and exercise the CLR and .NET with no intention of ever providing long-term support for those projects. The DLR, which was implemented to support those, appears to be just maintained by a skeleton crew of people invested in it, probably by those interested in keeping IronPython up and running.

I do not understand why Microsoft takes this approach. It is myopic, shows a misunderstanding of their own technology in the CLR, and ultimately turns C# into another C++, leave dead languages and projects in the wake.


The F# situation is not comparable to VB.NET.

VB.NET was just C# semantics with a VB like syntax. From the beginning it didn't serve any purpose except to make VB Fans feel slightly more at home.


I think it's comparable in the sense of what I was pointing out: Microsoft only truly cares about C# and only keeps F# and VB.NET going just enough.


>The other thing is that C# consistently adds features to itself that are inspired by F#, since F# already implements these features on the CLR, thus showing their viability. So what happens is that C# continually approaches a more bloated language with a subset of it being a poor copy of F#

C# and F# sometimes remind me another pair of languages: Java and Scala.


F# started out as integrating much better and being very selective of features, whereas Scala has been happy to add all sorts of features, to my understanding. F# has been feature complete for a while, mainly getting quality of life improvements and updating to maintain C# compatibility.


Interestingly enough there are a small handful of things VB.NET and C++/CLI can do which C# can't, which enable the former languages to have better interoperability with COM interfaces.

That was with .NET Framework and I'm not sure what the story is today with .NET Core aka .NET 5+.


They eventually added optional names parameters which made the interop problem much better for C# compared to VB.

C# wasn't as good still but you no longer had to put earlier params at their default value (which is what made it unusable).

C++/CLI will probably remain king of interop though being a Frankenstein combination of the .NET runtime and C++.


The other headache was indexed properties, but I don't think that's changed.

C++/CLI is no man's land and I tried my best to avoid it; and so far, I've managed; sometimes after-the-fact.


To be fair VB.net originally had dynamic capabilities that C# lacked so at least it possessed features that made its existence justifiable.

However the extreme changes required to go from VB6 -> VB.net made it all kind of moot, might as well rewrite.


Yet I can't help wondering what problems it had that caused them to abandon it?

Tech comes and goes, there’s nothing to vb specifically. As a language it’s pretty limited, tedious and quirky.

Moreover, why hasn't someone come out with a solid replacement?

Because webdev at its core is a community of stubborn smart guys who love the complexity and hate dull business code. They will present absurd arguments like I can do this and that, as if it couldn’t be packed into a vb component and drag-dropped onto a form from a palette without accompanying 1kloc boilerplate and pages of configuration documentation with no sane defaults. VB GUI model may be obsolete, gray and non-responsive, but no one prevents from building responsive interfaces wysiwyg way. My peer web designer does it without bothering with html/css much and it works for her for decades. All the tech is there, it’s just nobody’s collective interest to combine it into a business RAD instead of an intermediate haskell-level mindfuck starter kit. You can’t burn hundreds of millions doing actual work on a platform that everyone could start using solo in just a few days and deliver a working solution next week, even if raw and clumsy as it usually goes with non-pros.

I’d like to get a better and less bitter explanation, but there is none.


Not just VB, but also things like Borland Delphi.

25 years ago, you could visually compose a UI using standardized components, including advanced concepts like a layout manager. You could do data-binding visually by navigating a linked database. You can write logic/events just by double-clicking a button and the event is created. Here you'd write your code which would typically be pretty easy because all contextual objects are readily available.

Sure enough, I understand that the above development model also has its limitations and doesn't serve all common modern needs. But still, it's pretty pathetic what we ended up with. Our tool chains are much more complicated and we program at a lower abstraction level whilst requiring a laundry list of skills.


Having used both early in my career, Delphi absolutely shat on VB. But I'd be really interested to see the code I wrote in the 90s and see how it stands up in terms of reliability, maintainability, testability etc.

The closest thing I've found in the modern age is https://anvil.works - basically works like Delphi/VB, but web based, and in Python. For both frontend and backend.


> The closest thing I've found in the modern age is https://anvil.works - basically works like Delphi/VB, but web based, and in Python

You haven't used Lazarus (https://www.lazarus-ide.org/)?


And everything looked like the same unusable mess with 25 nested tab groups and tree views


I'd take a Delphi/Lazarus UI over most Electron apps. They started fast, took little RAM or disk space, used very little CPU, had fast response times, supported standard UI conventions.

Today, we have endless options. But most are not as comprehensive as what Delphi is/was. I'd rather write a UI in Delphi/Lazarus (LCL/VCL/FireMonkey) than any other UI framework even today. The trouble is, I don't want to use it for anything else other than the UI.

UI design and data binding should be a simple mouse driven activity. That's adequate for most designs. Why do we need code? It's like expecting everyone to use LaTeX than RTF. Sure, it's more flexible, but an overkill.

I wish there are more integrations with modern languages than 20 types of grids with overlapping functionality. I'd write my code in a language appropriate for the task and just use Lazarus for the UI. Currently, Python (Python4Delphi) seems to be the only one with components for that, but even that needs more polish (and largely stagnant for over 20 years). Most I can do is do shared libraries and call in.


Do you have an example screenshots of what you are talking about?


https://imgur.com/T9VnXi8

Why did this stuff happen?

Creating custom controls was difficult and considered to be for advanced programmers only. If you did create one, you'd get little to no help from the OS. You got lines and rectangles basically. You lost all layout support, there was no good typography features, etc. Coordinates would all be computed by hand. A real PITA. So everyone used the pre-made widgets even when they weren't really appropriate.

There were no icon packs and very few icons that were widely recognized by users anyway. So, everything was very text heavy.

There was a strong convention back then that you did not use scrolling to reveal controls. In other words, if you had more controls than fitted on the screen, you were expected to use button-like things to switch between pages of them, not expect the user to scroll down. The UI toolkits didn't support scrolling of widgets all that well as a consequence. This bias goes back very far and is partly due to the lack of compositing and pervasive optimizations for slow redraw speeds - it was more efficient to do a single redraw from old to new set of widgets than the constant rapid redraws required for animation.

All the UI code is being written in relatively bad languages like VB or C that aren't designed with refactoring in mind. The word "refactoring" doesn't even exist in this era, IIRC. Certainly, IDEs that help you do it don't exist.

Layout in this time is mostly absolute, or scaled to font sizes at best. Layout managers barely exist, so windows that aren't resizable are standard. As a consequence if you run out of space in a window, it can be disastrous - adding a new button or feature can become a tedious nightmare of relaying out everything by hand. So once code is written and app architecture is set early on, it's never changed. Features get added but redesigning the UI is so painful people just don't do it, and so if they run out of space you get ever more tabs, dialogs, buttons that open more dialogs that have more tabs, in an endless maze.


Microsoft accidentally killed it moving to .NET and the increasingly stupid GUI libraries they offered up. Silverlight, 32 bit native, winforms etc and etc.

Web development meanwhile went bonkers and VB was a poor cousin to C# very suddenly.

Its a shame, VB was not for purists but it was very productive.


Do not say WinForms is stupid. The rest I am more than okay with.


I don't think they did. They said increasingly so. They're just getting at Microsoft continually re-inventing the wheel and then abandoning that wheel when it comes to their GUI libraries. There's WinForms -> WPF -> UDP -> WinUI, Xamarin Forms -> .NET MAUI, and then the evolution of Avalonia and Uno as third-parties trying to step in. And all of those options still exist! You literally have a minimum of 8 GUI options, at least on Windows. There are of course more by external parties.


ASP .Net Core comes with it's own host of options:

https://learn.microsoft.com/en-us/aspnet/core/tutorials/choo...

If I am doing desktop development, you can bet I am still using WinForms, which are relatively easy to debug (if not as pretty) as WPF. I am usually building internal tooling, without paying customers, and sometimes for a user base of just me.


Agreed, .NET (well, C# specifically) was my go to for anything with a GUI until they tried moving on from Winforms/WPF and the way forward seemed to become a large undefined mess.


It wasn't accidental.


Related but off-topic: Nothing I see today compares to the productivity that I saw with Lotus Notes, Dbase 3 and 4, Paradox, Microsoft Access, Foxpro, and a few other things from that era. There are some really good SAAS offerings that target this space (e.g. Airtable), but none of them seem as dominant as I would expect. There was a time that if you wanted a simple application that could be covered with 3-4 tables and 5-6 views, any of the things I mentioned above could handle it. You could explain the business problem and hand a developer a book on any of the above technologies and expect to have a working product a month later. Today, this isn't really true. It does seem we've gone backwards a bit...


Microsoft effectively killed VB because they decided everyone should be using .NET. While they created VB .NET in an attempt to make the transition palatable to VB programmers, this was a second-class citizen to the CLR, and more importantly too different from VB, more akin to an inferior C# with VB-like syntax than actual VB. It was widely decried by VB developers [0], and nick-named "Visual Fred" due to really being a different language than VB. Microsoft ignored that, and also didn't bring a VB-like experience to .NET. It didn't help that mainstream software development started drifting to the web, and later also to mobile apps.

[0] https://classicvb.net/vfred/breaks.asp


Visual Basic died because of the Web.

VS, and Delphi, are the masters of creating desktop applications. However, both failed to port to the web, and them to mobile.

There are a lot of reasons why they failed -

* missing graphical expression capabilities for customer facing websites

* using languages that are not native JS, preventing them from utilizing the JS eco-system

* Vendors (Google, Apple) who for their own reasons kept mobile development native on their language and tools. And many more reasons.

Last, both have paved the way for low code application builders for enterprises, which are mostly aimed at internal systems (not customer facing).

Worth noting that we, at Wix, have built the Wix dev platform learning from VB and Delphi, creating a website builder platform with similar concepts (I am the creator of Velo by Wix, the Wix dev platform, and having 10 years experience programming VB and Delphi).


Visual Basic 6 was very productive - yes. But it was considered by many to be a toy language (it didn't support class inheritance for one).

VB.NET - at least initial versions - was about productive as C#, thus there was no incentive to use VB.

The thing that made VB6 super productive was it's form designer. The .NET successor - WinForms designer - wasn't nearly as fast and capable (to this day, really).


For anyone looking for a modern alternative to Visual Basic, you might want to take a look at Xojo.

Xojo's a rapid application development platform (both a language and an IDE) that you can use to develop desktop apps (for macOS, Windows, Linux), Web apps, mobile apps (for iOS and Android), as well as console apps. It's been around for more than 20 years, and some of you might remember it from back when it was called REALbasic.

I'm a solo custom software developer that specializes in NetSuite, and I'm using Xojo to develop all kinds of apps that integrate with NetSuite - from desktop apps to mobile apps to Web APIs.

There's a blog post on Xojo's site that provides a good summary of how Xojo is both similar to and different from VB. It's an older post (from 2013), and Xojo's come a long way since then.

https://xojo.com

http://blog.xojo.com/2013/06/19/a-modern-alternative-to-visu...


Talking of alternatives, I'm also aware of Gambas, though I've never tried it: http://gambas.sourceforge.net/


Xojo is much better but costs $$$. I don't write software all day so I pay for a license every few years if there's new features I want.


Pascal is still around as well with a great IDE Lazarus. https://www.lazarus-ide.org/


VB died because of .NET and VB.NET. The syntaxes were similar, but VB.NET was much closer to a "real programming language" in feeling and complexity than VB was, and that's not what anyone who used VB actually wanted.

Microsoft was more interested in developing .NET and C# to battle Java, and less interested in developing and promoting VB, their own successful and original product.


I recently wondered:

Why is there no VB-Like tool for building Electron - Apps using eg. React-Widgets & Javascript as the scripting - language?

I'm not married to Electron vs. another similar, possibly more modern / less ressource hungry alternative; or another Frontend Framework.

But it seems to be it should be possible to do a VB-Style thing using these kinds of tools, Drag+Drop, and Javascript, most of the components should be available already...

And it could be a fun environment for prototyping, having fun, creating really bad games & greeting card apps again like in the 90s/2000s etc etc.

It could be a fun learning environment for newbies while a powerful GUI builder for multiple platforms for experts..

Why isn't there such a thing? Would somebody please build this? :D


DotNet is meant to be the replacement. The big problem though is that MS keeps failing to make a GUI framework that is quick-and-easy as VB forms were. Winforms still exists, and it's only a bit clumsier than VB forms, but it's very old and not modern. The more modern .NET gui-frameworks are much less user-friendly.

Linguistically, I think the successor to VB is Powershell. It's the same mashup of inconsistent flags that let you swap between "this is a serious language" and "I'm smashing crap together" with tons of unexpected weird behavior, but instead of being a quick-and-dirty GUI app maker, it's a Shell. Hardcore focus on being easy and productive but unforgivably warty.

As for VB itself, VB.Net just didn't offer much value distinct from C#, so most people who were coding in VB switched to C#.

So if you're an old longbearded MS LOB programmer who started before .NET, and you're still working in Microsoft LOB shops, you're probably doing similar stuff but with C#. But realistically, you've probably also switched to Web.

And the lack of the VB-level ease-of-use in web technologies is a whole other story. All the hoary mess of using a document-engine for a cross-platform application server makes it pretty untameable.


For a while there we had WebForms, which was used much like WinForms, but generated the controls in HTML, CSS, and JS. That technology was very much not fun to work with, for the few projects I used it on. I built a full website using Sitecore CMS back when it was fully WebForms, and having come from PHP for web development, it was painful. It tried to paste over the way the web worked, which would have been fine had I never touched web development. Once ASP.NET MVC was introduced, things got much better for .NET developers.

I actually learned VB6 alongside Java in school, so migrating to VB.NET was fairly easy for me, but once I saw C# I jumped ship immediately. I turned my existing VB.NET code into DLL files and called them from C# from that point forward.


The FOSS community could do SO much better if they wanted to, with reactive web tech, typescript instead of basic, a project file format that's easy to work with in Git, Android support, etc.

Despite all this talk about no-code, it seems like all we have now is like, a CMS that lets you embed Google maps, but if you want to do anything more you have to use code.

Maybe it's just that end users usually don't need to build anything anymore, there's almost always an professionally made app for everything.

I've tried many times to "Build the app you want to see in the world" and almost every time the result is I decide that living with and working around the imperfections of what's out there is more practical than building and maintaining anything by myself in hopes of the the very small chance people notice and it becomes A Thing.

Perhaps better dev tools like VB aimed at one off software like that could change the equation, and if the tools existed we'd all find uses for them?


> with reactive web tech, typescript

I very much doubt. Actually reactive frameworks such as react and languages that transpile in other languages such as trypescript are the reason they couldn't. These overcomplicated, seemingly well architected, tools are in fact just a fractal of poor design.


I've never seen anything else that even comes close to working that well for making a responsive GUI. With everything else you spend half your time manually adding and removing things from list view controls and such.

There are some pretty big architecture issues. Like the fact JS and TS are still separate things(Google tried to fix that with native Dart in the browser, looking back it would have been amazing) and the fact that there are dozens of reactive frameworks that come and go.

Most of that wouldn't exist/would be papered over so nobody noticed, in an end to end, "We plan to not break this for the next 25 years" tool like VB or Excel.

But everthing new comes with a move fast and break things expectation, people are less interested in creating new 30-year standards now, and that doesn't seem to be how stuff is done. Complex stuff is considered disposable these days.


I started my career with VB/VBA/Access, but got burned by one of their non-backward compatible upgrades (I don't remember which versions) that derailed an important project. This was around the time that Java was what the cool kids were using, and I was very amenable to trying open source after that experience, and I never looked back.

It was a great experience though, especially for a self-taught beginner long before code academies and YouTube.


>nothing I have found compares to that development experience today. I would go so far as to say we've gone backwards in a big way.

I did Visual Basic 3.0 through VB 6.0 corporate development for a few years back in the 1990s. The closest equivalent today for desktop apps that still has Microsoft's focus on future innovation is C# with Windows Forms. (I downplay the "obvious" comparison of VB.NET to VB 6.0 because Microsoft already said they will "stop evolving" Visual Basic .NET -- so that's a technology dead end and will fall further and further behind the latest C# as the years go by.)

I personally don't experience that C#/Winforms has gone backwards from VB 6.0. Workflow feels much the same as VB6: Drag some GUI components like text boxes and buttons onto a form, code the controls' event handlers, build the exe.


I've only done a small amount of VB programming, but from what I remember of it, WinForms + C# is lightyears ahead of VB.


Are you talking about VB the language, or Visual Studio the IDE with its awesome GUI builder for WinForms (and not so awesome ones for the subsequent Windows GUI layers, forget what they're called).

VB is still around but desktop apps in general (and thus VS's GUI builder) largely gave way to web technologies invented outside Microsoft. The dev experience is definitely worse though. Visual Studio was sooooo nice and integrated.

I don't think this is really VB or NET's fault, Microsoft just kinda missed (or failed the fight against) the web transition. They were busy trying to make it coexist with Windows with seamless downloads like ClickOnce but ultimately simple web pages won out for their reach and ease of use, then mobile app stores came along, and now desktop apps are petty much dead except for niches.


I remember, in some sense, Google (and also a group of anti Microsoft developers) encouraged web development as a strategy to break the Windows software monopoly.

So it's not that Microsoft missed it, it is that a big shift happened and it was specifically targeted against them. There's nothing they could have done, except to embrace it, and they did. Visual Basic Script existed and was very popular for a while. IE4 ruled the web.

The shift to web based technologies is a Google and an open source win. And it is also an inferior experience. That was the price we paid =)


Even in the IE4 days, Microsoft was still very much "we'll only do as much web as necessary, but we can't lose our Windows fort... how can we sabotage this effort?". They were in full-on EEE mode[1] then and wanted to subvert, not join, the web. JScript, ActiveX, ClickOnce, IE's idiosyncracies, etc. were all Microsoft's own efforts to get around the webification of everything. They lost, not just because of Google but also Netscape, Mozilla/Phoenix, eBay, Craigslist, Amazon, Match, MapQuest, etc. Nobody wanted to build desktop apps anymore once they could effortlessly reach everyone via the web without having to be a Microsoft vassal.

Even ASP and IIS etc. insisted on having its own stack -- superior in some ways, but way less compatible and more expensive. Again their own doing. Free/cheap won out, I guess :)

[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

(edit: how the heck do you actually properly make hyperlinks on HN? I always struggle with this)


> web pages won out for their reach and ease of use,

Your definition of "ease of use" is amazing. /s


Heh, point taken. But I'd say overall it's easier for grandma to go to Gmail to check her email than have to figure out what this "Netscrape Communicator" is, install it, set up her "pop three" from her "eyesp" and then deal with a million viruses.

Yeah, the web ain't perfect, but it did win... ads got worse, though =/


Visual Basic was mostly used for LOB applications. That stuff mostly migrated to the web. When businesses decided to move those applications to the web, they had a choice between C# and VB.NET (if they stuck to the MS stack). C# ultimately won. Most of the old VB developers that are still around have converted over to being C# developers now.

When everything was a desktop app then the choice was C++ or VB and there were a lot of situations where VB "won". Today C# does everything VB used to do but better on the desktop and non-performance sensitive applications are increasingly using Electron anyway.

Performance sensitive desktop app = C++ Windows focused non-performace sensitive desktop app = C# Cross platform non-performace sensitive desktop app = JS/TS in Electron Web app = anything but VB


From my perspective, Microsoft killed it. It did not die on its own. The upgrade path from VB6 to VB.NET was basically unusable. You either stayed on VB6 or you rewrote the application.


On Linux, Gambas is a great replacement.

https://en.wikipedia.org/wiki/Gambas

https://gambas.sourceforge.net


My go to language / ide for when i just need a gui to get something done in a few clicks on linux.


The web happened. VB was great for builing stand alone desktop applications, possibly with database integration. But they never managed to deliver a similar slick and self-contained solution for building web-based solutions. It didn’t help that the migration from vb6 to vb.net was too painful, but the root cause was the demand for business desktop apps disappeared.

The infamous WebForms API was supposed to bring the same gui builder paradigm to the web, but the developer experience was not as great.


People want more these days. With VB you could write a CRUD application that saved data to a database and ran some reports. But now people want the database to pull in multiple feeds from other businesses via API, people want it to be available on the web, it needs to have a self service component so the customer can also log in, at the back end the database is connected to several other systems with daily feeds coming in and out. Shit is just much more complicated these days.


VB6 could do all these things and more, in the 90's I built just the right small parts in C++ to glue things together, and we could do multi-processing, resilient multi-server setups, and much much more. Serving HTTP for some always-limiting browser was an obvious easy sidenote, ie. what your mantra "available on the web" wraps in silver, but leveraging the full power of the desktop and OS was what power users actually wanted, and would still want now if the apps were there. I think some people at Microsoft realized VB had the potential to canibalize a lot of what they wanted as their proprietary backyard, and they killed the baby before it would grow into more of a mass movement. Now they succeeded, many that would have been educated into owning their computers now mindlessly click on "Yes" and are lost in the adds panopticon, but then MS had to non-compete some of the pie off to Google and co...


Right, you could do all that with VB but most people didn't.

Exception handling was crap in VB (no call stack) so we wrote a Visual Studio Macro that would go and edit every single method to add "On Error Goto" with a block at the end of the method to automatically add the method name to a homemade exception object so that when there was an error we could actually tell where it was coming from. So you _can_ do that too in VB but it wasn't pretty.


>> I have yet to find a tool that can allow me to be as productive in so short a time as Visual Basic.

For me: Delphi or Lazarus


A few thoughts - loved VB and made my first money as a high schooler by programming in it.

As far as I can recall it was the only programming language that let you begin by laying out the UI and then wire up the code later. Like your project started up with a blank Windows window. You drag a button or a text area and you hit Run and your app right away has a window, a button and a text area.

To write code for the button click, you click the button in the editor and write it.

A few years later jBuilder (I think) allowed you to do something like with Java, that though not as simply. I am not aware of any dev tooling that offers that today.

I suspect a few things happened that made VB go away. I think VB was aimed at one-man dev, not sure how it would work with revision control and team development (eg when u think of your project as a window you drag stuff onto, how do you deal with merge diffs etc.) I also think the world migrated to more client server / web stuff around this time, while VB was very married to a standalone windows app. And then on the flip side, probably coding became stronger in excel so some of the stuff moved there.

VB was amazing, such a pleasure to create in.


Related. Others?

Something Pretty Right: The History and Legacy of Visual Basic - https://news.ycombinator.com/item?id=35192913 - March 2023 (259 comments)

RAD Basic – Compatible with Visual Basic 6 projects - https://news.ycombinator.com/item?id=31282195 - May 2022 (208 comments)

Ask HN: Modern, easy-to-start with alternatives to Visual Basic - https://news.ycombinator.com/item?id=30606244 - March 2022 (11 comments)

Microsoft plots the end of Visual Basic - https://news.ycombinator.com/item?id=22570684 - March 2020 (280 comments)

Ask HN: What is the modern equivalent of Visual Basic? - https://news.ycombinator.com/item?id=20548849 - July 2019 (10 comments)

The Rise and Fall of Visual Basic - https://news.ycombinator.com/item?id=20255140 - June 2019 (149 comments)

Visual Basic Turns 25 - https://news.ycombinator.com/item?id=11755041 - May 2016 (145 comments)

Why I am called "the Father of Visual Basic" (1996) - https://news.ycombinator.com/item?id=9229434 - March 2015 (80 comments)

The Birth of Visual Basic (2006) - https://news.ycombinator.com/item?id=8438845 - Oct 2014 (59 comments)

Linus Torvalds, Visual Basic Fan (2006) - https://news.ycombinator.com/item?id=6005587 - July 2013 (48 comments)

The Silent Majority: Why Visual Basic 6 Still Thrives - https://news.ycombinator.com/item?id=4085372 - June 2012 (91 comments)


"why hasn't someone come out with a solid replacement?"

There are some companies/people keeping the torch burning but they're not as widely known, one such is Mercury which targets a whole host of platforms and is actually quite good - https://www.remobjects.com/elements/mercury/

The problem is it feels a bit of a niche language now because MS basically forced people on to C# by not actively maintaining VB.NET which was the first hop for people coming from VB. Early in my career I did various conversion projects for corps from VB to VB.NET then eventually as that atrophied to C#.


I wonder the same thing about Apple's HyperCard. I used HyperCard a ton at school and side-projects. Visual Basic was a firmer and better step-up from that imho, less so as VBScript when it came to browsers.

As per other comments VBA is alive and well and I did many consulting gigs using that in Ireland in the late 1990s. I hope, in the name of all that is holy, that code isn't running still.


A bit of an unrelated topic, but if you liked HyperCard you might be interested in https://hyperscript.org/ and their related project https://htmx.org/


I wonder about HyperCard as well. I never used it but, from everything I've ever heard about it, it was also an amazing developer experience.


Why not give Decker a spin? It's similar to HyperCard, but open source, runs nearly everywhere, and it's under active development: http://beyondloom.com/decker/


Speaking of nostalgia and Microsoft deprecating great low-code development tools…

I miss Access Data Projects.

These had the Access front end and VB rapid app development experience, but were backed (only) by SQL Server. This mode wasn’t the classic ODBC external table connector. If you added a table in Access, it would create a table in SQL. If you created columns, foreign keys, or views, the changes would be made directly to the database schema.

This also eliminated the data corruption issues that plagued file-based databases.

It truly was one of the fastest and best ways to write an internal-use business app.

So of course, Microsoft took it out to the back and quietly drowned it in a tub.


It’s simple: Corporate internal app development (mostly CRUD stuff, as you’d expect) was the bread-and-butter of VB, and it moved wholesale to HTML & JavaScript.


Just partly on topic: the code name for the first version of Visual Basic (or its predecessor) was Ruby, IIRC, as recounted by Alan Cooper (the "Father of Visual Basic) in an article I read some years ago.


That is also mentioned in the History section at:

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


We had plenty of amazing paradigms/development environments/holistic experiences which we've regressed from:

- LISP environments

- Smalltalk environments

- Symbolics genera

- Mesa and Cedar

- Apple's Newton

Besides things like Oberon...


I was working in C++ on OS/2 at the time when a resource editor was hard to find and that chasm from the command line to the GUI was what made the jump to commercial software development feel like the Khumbu Icefall.

I worked in a small software development sub at a big bank and they needed a rolodex. I agreed to do it in my spare time if they'd buy me a legal copy of VB 1.0. I did the prototype in what feels like a glacial week today, but they followed through with lunch and a shrink wrap copy.

If there's a death of GUI or IDE development tools it's the same for all of them with the possible exception of the outer edge of Jet Brains and VSCode. Put simply, they don't scale like command line tools since you're dragging a 200 ton freight train of GUI bloat behind you where it doesn't deliver the impact gravity that the train does.

HCI or GUI should scale like APIs do, but they don't, particularly now that resource editors are everywhere, and we're about to replace highly paid drag and drop mouse typists with nearly autonomous agents.

Humans benefit from visual affordances like VB because VB lowers the bar, or the barrier to entry. GUI development would still be stuck in the late 80's if Cooper hadn't made it possible for the inmates to overtake the asylum with their drag and drop tools.


There's still no better GUI toolkit out there than VB6 that I have used. It was amazing.

Problem is a lot of apps that would have been traditional LOB apps written in VB/C# have moved to the web so demand isn't there's clear advantages to C# as a language over VB.


Netbeans Java Swing GUI builder is far better. That's without factoring in the enormous third party component landscape that is available.


Oh man, I remember building GUI apps with it in college. My professor only let me use it on the condition that I could fully explain what every component was doing. I could. I took the generated swing code and added a massive amount of comments, but even having to do that I was still an order of magnitude faster than every other CS student without. A lot of my peers were super jealous that I had so much free time, but they weren't willing to invest time in their tools (gdb, perl, regex, sql, etc). It was quite the force multiplier.


I just recently wanted to spin up a simple CRUD UI over a simple DB schema and also thought of Visual Basic for the first time in a long time. It seems so well suited to something like building operational tooling for the endless parade of internal APIs.


VB was a godsend for me. Despite being a very capable DOS and embedded/RTOS developer, the learning curve for the ugly tools and API's for Win3.1 development was more than I wanted to handle.

It was magical how easy it was to build little tools and line-of-business apps in VB. And after eventually learning MSVC and MFC/ATL, I was even more impressed with how easy VB was compared to that.

But .Net killed VB because C# was enough for both noobs and for real programmers.


I am actually trying to make an open source successor, but using Javascript instead of Basic, at https://github.com/yazz/yazz and a demo at yazz.com


To be clear, Visual Basic isn’t dead. I work in the govtech space. I can assure you that there are VB6 applications still running into production in this space, even places you would not expect. VB6 doesn’t support threading, but I’ve seen Computer Aided Dispatch applications that use C++ to multi-thread VB6 server code for emergency 911 dispatch.

VB6 still runs on Windows, and will even work just fine in AWS.


I've seen very established finance firms using DOS software from 90s. Still in 2023. Hard to imagine but it is what it is.


From a security angle...

.net webapps written in asp.net behave similar to PHP in that any file with a .aspx extension that is within the web root will execute by default. This means that asp (and php) webservers are particularly vulnerable to RCE attacks because the default configuration of the server turns an "arbitrary file upload" into a remote code execution instead.

Where an asp.net server would handle front-end and api and they would be tightly coupled, we've moved on to where the most common configuration is a separate API and frontend. I believe you lose a lot of the benefit of using asp.net to try and decouple them.

On a totally personal note, as a penetration tester I've proxied requests from a LOT of different APIs on a lot of different technologies and asp.net is hands down one of the worst to test, the way it handles requests under the hood is unruly and ugly. Some might say that's a positive in terms of security, but IMO it makes it harder to identify vulnerabilities in your system.


We built some pretty big applications with VB6 (heavily optimized by using WinAPI-Calls and C++-libs where necessary). Nothing what came later matched development speed (although some langs using REPLs may come close). Whoever designed VB.NET didn‘t know anything about the things VB6-developers like my loved. So VB died because what came next simply wasn‘t VB.


vb didn't die, it evolved into vb.net, but the market place has shifted to C# for the most part.

What has died, is the maturity of microsofts tool set, they keep changing their concept/design/platform.

silverlight/wpf/uwp/winui2|3/etc..

vb was around for nearly 2 decades and had a very mature tool set, everything since then hasn't gotten nearly that sort of life span or dedication to tool sets.

Developing in visual studio now, is more like web dev in the 2000s, I can't tell you how often you have to go to the xaml and make correction or adjustments that the UI just can't get right, or just goes bonkers and can't render the UI at all until something is fixed.

It is really sad, because the power of those old drag and drop builders that just worked meant that prototyping and mocking up applications was much much faster.

now standing up a UI based project takes ages, I'll usually do a console application now, and are dumping results to a API or console.


People always worry that Microsoft is silverlighting (that is a verb now) MAUI. I think that would be the end of VisualStudio. The word Visual had a meaning. When they would give up MAUI in favor of React Native (like Office) or Blazor (like the popular opinion), why the hack someone would buy a VS license. And when the think they could again commercialize .NET itself, then .NET would be dead. Modern Java, Flutter and TypeScript would easily swallow their market shares. MAUI, Blazor and .NET are an awesome set of products if they would just put some more concentration in MAUI.


VB didn't die. It got reborn as VB.NET. Still supported, still used.

https://learn.microsoft.com/en-us/dotnet/visual-basic/gettin...

The classic VB you probably remember got end-of-lifed in 2008, but MS still supports classic VB apps.


I think that’s the sense in which it died in that if you were going to switch to .NET you would probably also switch to C#. The original VB had A GUI builder better than almost anything (even today!) but the UI builders in today’s visual studio support C# as well if not better than VB.


You bring up a good point, which is that I remember most the GUI builder. Basic isn't really that great a language, all things considered. But being able to quickly design and deploy GUI apps with VB was better than anything I've encountered since.

There are things like WebFlow and FlutterFlow but those tools feel clunky by comparison.


Hmmm...I'm wondering if you have ever used Netbeans. There is a GUI builder for Java Swing. Top notch.


Netbeans java gui builder is the only builder I’ve seen come close to the vb gui builder. In fact I was a little disappointed moving from net beans to a “real Java ide” since their gui builders don’t exist or aren’t as good. But vb as a language is a lot better than Java for getting to a productive state for a novice.


The best IMO was in Delphi. Lazarus captures that spirit well today but is mostly unknown.

Netbeans GUI builder was more powerful than VB's in some ways but just made simple things complicated.


And everything in that IDE was fast and super responsive. Today's IDE are more complex than ever and yet they lack in functionality that was present in VB6.0


Yes, but look how good the dark grey text blends into the black background. /s


I once had a job offer from a big company that developed exclusively in VB.NET, after transitioning away from VB6. Both for desktop and web. So it's still out there.


After they re-implemented the compiler in VB.NET and ported it to .NET 5, the language won't get any new features / has stopped development [0]. They basically deprecated it.

[0]: https://mspoweruser.com/microsoft-starts-deprecating-visual-...


Is VB.net the same as VB ? Or it is like C# compared to C ?


Well Basic evolved a lot. Comparing 80s Basic on whatever hardware you imagine (think goto + Line Numbers) to 90s Microsoft VisualBasic (think event Händlers for UIs) is a similar jump than VisualBasic to VisualBasic.NET (writing OO code).

VB.NET is the same but so much more evolved. Also the runtime below was switched (surely for the better).

However, like outlined in other comments: VB.NET is a OOP language which handles procedural/functional code as a subset while VB of the 90s was purely procedural.


I used VB 3.0 thru VB 6.0 and I echo the sentiment: those were fun and productive times. Really solid integrated development environment centered around the desktop UI / form design / UI controls like buttons, textboxes, combo boxes, etc.

I also agree that the web changed everything and that is the major reason for the shift away.


IMO, it didn't really make a smooth transition to the web. Webforms was the attempt but it was a leaky abstraction (iirc, it kept state for UI components but not variables so things got... weird) and kind of worked against the paradigms at the time (everything was a POST).


Yeah exactly, VB dying is sort of the CONVERSE of programmers adopting platforms, not languages - https://old.reddit.com/r/ProgrammingLanguages/comments/sk6w1...

- Why is JS popular? Not because it's the best language, but because it's attached to the browser, and people want to deploy apps to browsers (Figma, etc.)

- Why is shell the 8th most popular language on Github, and the 6th fastest growing? [1] Not because it's the best language, but because it's attached to the Unix kernel (specifically Linux, which has a ton of features). Software in containers and virtual machines must talk to kernels.

So then the converse is

- Why is VB no longer popular? Not because it's a worse language than it used to be (though maybe that's true), but the platform that it supported isn't as popular.

Like others said, it's probably popular for Excel and app automation, etc. But today more apps are targeting web and mobile, not Windows desktop.

- Same answer with Objective C and Swift -- people are using them to write apps for a platform. And Kotlin/Android, etc.

[1] https://octoverse.github.com/2022/top-programming-languages


This is fascinating to me. I am a software developer of many years and a novelist in more recent years. (See https://ronanodriscoll.com/work)

My latest book is a novel about the life of a software developer starting with BASIC on the Commodore 64 in the Eighties up to today. One of the main ideas is how (unlike previous professions), a programmer who only writes Basic can hardly last one generation. The novel is tentatively titled "BASIC Instinct: A Coding Novel". The book is to be published by Moose House press next year and I am looking to generate interest among the developer community.

I hope people who comment on this thread find this interesting. Please don't hesitate to contact me if you do, or have ideas of other online communities to share with. Thank you.


I was a VB6 developer in the 1990s, and I actually wrote a pretty well known product with it (I bet most people didn't know it was VB6 underneath!).

When I got my first job in software engineering, it was when .Net was in beta. Since I only knew VB, I chose to go with VB.Net and Windows Forms.

Well, that was quite a jarring introduction to actual object oriented programming!

This is the point when a lot of people surrendered. The change was too much, there was no path forward for VB, and Microsoft wanted everyone on .Net.

I eventually switched to C# and we had a hybrid application for a while before it was all ported to C#. It actually went on to become industry leading software in its space.

20+ years later, that doesn't seem to have been a bad choice. Windows Forms is very simple, with a powerful drag-and-drop designer, double-click to hook up events, it's all very similar. Yes, you have to understand object oriented programming much more than you would have under VB, but that's as close as you are going to get from Microsoft on the desktop. They try to hide it as best they can.

I still use Windows Forms if I need to put together something that "just works" on Windows as a desktop app quickly. It's unmatched for that.

There are newer technologies, such as WPF, WinUI3, Avalonia and others for .Net but they come with a complexity that would be above your typical use-case for VB6 back in the day. The VB6 user who just wanted to get stuff done probably doesn't want to have to understand how to implement the MVVM pattern just to get a UI.


I do wonder if there’s an alternate universe where MS did a better job of modernising VB (VB.NET hardly counts), and where Borland was less doggedly intent on murdering their golden Delphi goose, and where frontend development is now quite easy.


First of all, desktop software just isn't as popular as it used to be. Everyone wants to develop a webapp or a packaged app.

Second, Microsoft consolidated all of their languages into .NET right around the time you're describing, and they all get translated into the same middle language before being compiled. Maybe except C++? Not sure. Either way there's really no reason to choose VB when you can have C# and they all get converted to the same thing.

Lastly, Basic was always seen a "hobby" language, a reputation which was carried over to Visual Basic. So once again, serious programmers will look at the Visual Studio suite and go with C# or C++.


VB was mostly for IT departments to create small custom apps without having the full software engineering skill set. This was the time when software development started to be outsourced to the 3rd world. Most of the low level apps that were maintained in a companies IT department would have been outsourced easily. But the companies taking on these projects in the 3rd world would have used more complex development tools just to look and feel like they are doing complex work.

I do not mean to suggest there are no complex software coming out from the 3rd world. But most of the outsourced projects are simple CRUD applications


What made VB6 super-productive and quick to get up and running also made it terrible for long-term maintenance, because it hid too much of the details.

Then there were language warts like set versus let (strong vs weak pointers), for example, which was way above the paygrade of the average VB6 coders; and having to rely on the Win32 API anyway in order to start doing actual work and work around all of its limitaitons.

One thing VB6 did do right was forcing interface-based inheritance: Composition over class inheritance was seen as a weakness back then but it was proven as the right concept.

This is just my opinion!


The DAO and OLE Automation was a paradigm that saturated the market with similar applications, and the move to mobile/cloud platforms essentially made the computational overhead a liability. Yet in a way Microsoft VB helped standardize the look of event driven GUI workflows (also why windows 11 design sucks).

VB "made simple things easy, and difficult things impossible" in a developer environment. Its funny that the ecosystem of OCX still haunts many projects.

It could be Python took over the role of an introductory language. =)


You're probably speaking to VB plus Visual Studio RAD (Rapid Application Development aka "drag and drop" GUI programming) and you more or less still have that today with VB.NET and Windows Forms, with minor differences.

What killed the older VB6 and it's APIs, whose name I can't recall even though I developed for it in the 1990s, was .net coming along.

Be warned, it might just be easier to learn C# as it's more well-supported/documented, and VB.net seems like effectively a language dialect of C#.


I learned Visual Basic (6) a few months before I learned C#.

Hands-down, C# was a much better language. Visual Basic (the language) always left me feeling dirty compared to C#. Both languages have similar learning curves for a novice; but C# includes industrial strength features that allow code written by a novice to be refactored instead of rewritten when the need comes along.

Both languages have a similar way for designing a Windows Forms UI, and the API for working with the UI from code was generally similar. Once C# came around, there really wasn't a reason for using Visual Basic 6 for a quick-and-dirty UI because you could do the same thing in C# in the same amount of time. (So why waste your time with Visual Basic at that point?)

I personally think the "VB.Net" situation is what really killed Visual Basic. There really was no reason to force everyone to rewrite their projects, because VB.Net didn't "add" anything. Instead, VB.Net turned into a smell that someone wasn't savvy enough to use "real" C#.

I personally don't know when I'd pick Visual Basic 6 over C# for a Windows application; but I have a pretty serious development background. I also noticed that novice developers tended to come up to speed with C# rather quickly, so I'm not sure if the more casual nature of Visual Basic 6 really helped anyone.


The casual nature is what made it so popular. You could write some fairly disciplined code with VB6, but once you turned Option Explicit off and added some On Error Resume Nexts and embraced variants, you had something you could write with without knowing much about programming. I’m a big fan of C#, but I’m a professional developer and I know how types and exceptions work (for example). I knew plenty of have-a-go managers who would have balked at C# but produced reams of…interesting…VB6 code.


A few thoughts as I was a VBA developer at the time .net was released. 1. VB was deliberatly killed off by M$ in order to get .net going and the resulting vb.net was horrible to use. 2. C# was the new kid on the block and acted enough like C++ to not totally alienate C developers even though the library was terrible. 3. Security was becoming an issue as applications moved to the internet. Since VB and all the classic ASP tools used com they were deprecated in favor of .net runtimes.

Meanwhile VBA was running many business solutions and supporting multi user applications, reporting applications. I developed many apps in Access and Excel that were business critical and are still in use today. IT management wanted these to be re written in .net and found it nearly impossible from a budget standpoint and those that were converted we slow and clunky since the Office interface from .net is slow. Last thought... VB was always the poor step child to fully compiled languages like C and C++. And VB developers were looked at poorly as undisciplined which many were. Looking at the online apps today where Java script is used with undeclared variables tells me that no one's cares about that anymore.


Nothing compared then or since to VB 6's ease of layout and GUI-centered approach. It was a language that was easy to use and WAY less complicated than C#. To me, complicated is a huge drawback. Give me just enough tools to make something that works. VB6 was absolutely fantastic for prototyping. I have absolutely no need for 200 methods for every expression that I have to go lookup every time (this is why IntelliSense even exists), having to think about bullshit like "syntactic sugar", aka "the only way to do something because it's otherwise too hard to remember", which to be fair started with javascript frameworks, but applies equally well to .NET.

The whole dot paradigm took a group of people who were very comfortable with a language and tried to turn their brains inside out. Ex: x.ToString doesn't have the same intuitive recognition as Str(x), nor can Str(x) be as easily muddled together with 3 other methods. Call it simple and meaningless, but .NET is profuse with these turnarounds, and they required people to re-learn everything, even the simple stuff. .NET adds layers of complexity by enabling super-spiffy compact writing of multiple operations with complex operators all on the same line that is far too easy to get lost in and that frankly, is unnecessary. I'm talking about things like delegates, lambda expressions, extension methods, and async/await. These are cute if you're super nerdy, but for most of the rest of the world they take something that was easy to use and contort it into an unrecognizable mess.

VB6 was just complex enough and graphics-centered and they moved it to a hugely overly complex and language-centered model. It made no sense to me. Of course, everyone who thought "real" programming should be harder embraced C# like it was manna from God, and this by and large is the thinking that killed VB6. It was a complete paradigm shift in the wrong direction for visual thinkers.


I've mentioned here in other occasions, but worth doing it again: GAMBAS (https://gambas.sourceforge.net/en/main.html) is a cool, modern and powerful alternative to the old good VB RAPID stuff. I haven't personally used it in ages but I recommend to give it a shot.


The language died because of Microsoft tried to woo java developers into using the .net ecosystem. So whenever the CLR got more features, C# (rather than VB) started supporting them more readily. Experience wise, it looked more elegant in c# than in vb.

VB originally wasn't thought of as an OOP language. But through vb.net when that paradigm was "imported", the language lost its charm.

Further more, web development took flight. No one was interested to build desktop applications anymore.

Also I wouldn't say the influx of java developers into the .net ecosystem was that considerable. (Or for that matter other platform developers like python, delphi). It was definitely slow during the 2002s. Because the java ecosystem had achieved code-once-and-run-any-where paradigm. You could write desktop applications developed on windows, on, linux machines. From a business POV why would application developers "want" a different ecosystem to achieve this?

All this sort of eventually killed classic VB.

PS: you should also ask bing ai this question. :)


Despite being dead, I suspect there are a large number of very high value Excel workbooks with significant lines of VB(A) in them.

I've experienced 9 digit ventures which fully depended on large (hundreds of MB) Excel workbooks which talked to dbs, remote APIs, and network files to make complex calculations. It's invisible to most of the world, but it's definitely there and alive.


Thankfully VB's "Unix philosophy" counterpart -- Tcl/Tk -- lives on. I have always found it faster to go from zero to GUI by laying it out declaratively in Tcl/Tk than by rat wrestling in VB -- and the results look better. With the Snit object system (part of the popular Tcllib), building components out of the basic widgets becomes a breeze.

The problem with VB and with other "business languages" going back to COBOL is that the skill ceiling is low. Not as low as this decade's no-code craze, but tools like that make the easy bits easier and the hard bits asymptotically approach impossible -- and as projects mature, hard bits dominate the lifecycle. Tcl has an absurdly high skill ceiling but it has problems of its own. You can do crazy Lisp-style metaprogramming, but the semantics are as if designed by a Lovecraftian madman who'd been exposed to dread Cthulhu.

So nothing is perfect but there are ways to feel as productive as VB, even today.


VB6 morphed into VB.Net but then the web took over and anything that could be accomplished as a desktop app was replaced by a web page.


I remember it as the push to C#. Microsoft had basically shat themselves about Java, and were pushing C# as its rival. VB.Net was a bit broken, there was lots of "you'll have to use the C# interface for that because the VB one isn't ready yet". Generally as developers we were pushed to C# and the writing was clearly on the wall that VB wasn't going to continue as is. The whole Microsoft stack was converging on C# and moving away from VB.

And the replacement of COM with .Net has an impact. We had a whole ecosystem of COM (and DCOM) objects that worked well. .Net broke all of that, and didn't replace them for years.

I don't think it was the move to OOP. VB4 introduced classes way back in '96 (iirc), and by VB6 everything was objects. It was a little more complicated for newbies (I remember training junior devs in OOP in the early '00s), but once they got the hang of classes and instances it was plain sailing.


There's still Visual Basic .NET, is it much different productivity wise? I assume the language has changed enough from classic VB.


While it is vastly different from VB6, I found that knowing VB6 at least gave me a leg up on understanding what they were going for. Once I was familiar with Visual Basic .NET, I realized how much less syntax was involved with C#, while still being able to use the same libraries. I never looked back, except for my first professional job where my "lead" didn't know C# very well, but knew VB.NET. He made me code in VB.NET, but eventually I took over the project, then immediately extracted the VB.NET code into DLL files that I called from C#, and wrote the remaining application in C# until I could refactor everything into C#.


I honestly haven't used it because I thought they had retired it altogether. The last time I did use it was about 20 years ago and found that they had changed it enough that I wasn't nearly as productive with it as, say, VB6.


The Wikipedia article suggests it's still around and that it's being focused more towards rapid development.

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


Microsoft stopped supporting it. VB 6 was the last "true" Visual Basic. The .Net Visual Basic was not backwards compatible with the very large code base projects everyone had created over the years and ones on forums and websites like planet-source-code (before GitHub existed) and the many, many beginner-friendly books.

They had a conversion wizard to migrate VB 6 projects to VB.Net but it was very half hearted and never worked on anything except the very trivial code bases. Anything that used OCX and you were out of luck, except OCXs were very very common in classic VB development.

People kept writing VB6 as long as it was practical (Windows 7) and then either moved on to greener pastures or left coding altogether as it was becoming impossible to use modern libraries anymore and the overall learning paradigm have shifted from books/forums into video tutorials and "modern" languages.


Not sure how accurate this is, but: https://www.youtube.com/watch?v=YqxeLodyyqA

Visual Basic's popularity peaks in late 2001. Exactly when VB .NET was launched. Then it drops like a rock. In my memory, .NET overcomplicated VB and yet still felt like a kids toy.


Microsoft killed VB for one very simple reason:

They were terrified of Java and the JVM that went along with it, as it would make their cash cow - Windows possibly redundant. They basically switched everything to .Net and the CLR.

Also, you are looking at VB through rose tinted glasses. VB was a terrible system to build products on: - Poor language. BASIC is not, as implemented by VB, a production level language. I am sure folks will argue that point, but I will stand by it. - The component model was terrible - you had to drop in to C and use OLE/DCOM to create components for it. A VB dev couldn't create components directly in VB. - DLL HELL. Shipping VB code was a nightmare.

Delphi was an answer to all of this - but Microsoft killed that too by stealing Anders Hejlsberg, whow went on to create the .Net frameworks, implementing many of the Delphi innovations in a Microsoft ecosystem.


The broader question is, why did "Visual Programming" die, or rather, why is it always rather niche.

Visual type coding / low tech coding, drag and drop of computing blocks and other GUI based programming approaches is a perennial promise and brilliant examples light the sky every once in while like fireworks (Scratch, Web "Mashups" [1] come to mind as other examples).

The outline of the answer must be that the capabilities enabled with such GUI oriented programming styles don't hit a sweet spot with large numbers of less technical knowledge workers. Compare e.g., with the spreadsheet paradigm that is a resounding success despite Microsoft. But why that is is not clear.

[1] https://en.wikipedia.org/wiki/Mashup_(web_application_hybrid...


I'm only half way thru one good post after another. But I don't see many posts about: can VB be extended, expanded, developed? Truly, I am far behind most, and currently I am working on an app, in Excel, that helps the voiceless (like me), speak. I worked w/ Access VB for a short while, but, it, at the very least, needs Sql Server. Also, there are issues with threading, but is that the end of it? Since VB is a high level environment, speed is an issue. I have not yet heard that Excel is really headed toward .net or any other framework, but I keep checking. If anyone at MS wants to appologize for the Ribbon, don't bother. I will never accept! But can VB, in some way, be fixed or rehabilitated or improved, or whatever? I do hope so, but I can be persuaded otherwise.


C# with winforms in visual studio using the gui builder is basically the same experience as vb6 but better in every way. I'm honestly not sure why complaints about legacy vb6 being killed tend to overlook this, but I think it's because there are lots of people who have fond memories of vb6 but have simply never tried c# with winforms. If you want that experience, you can literally get it right now as long as you're ok making desktop apps that will only run on windows and don't mind that it may look somewhat out of place among more recent windows apps using WPF and its successors.

The real question then isn't why microsoft "abandoned" visual basic (they replaced it with something that is strictly better), but why people aren't using winforms or something similar in 2023. I think that's because 1) it isn't cross platform and 2) people have lots of other requirements that are difficult in winforms.

Aside from being cross-platform, I guess the winforms api requires you to manage a lot of stuff like data bindings by hand that people are used to having work automatically. People also want good support for various monitor sizes, although .net winforms is actually much better about that than vb6 because it has pretty decent layout controls so you don't have to write code to handle resizes to the same extent.

The fact is, the vb6 gui builder worked best if you just ignored resizing and only had to worry about one screen resolution, and even though .net winforms is better about that, it's still fairly complicated to use the layout controls to handle resizing properly

I think there was actually a project that was attempting to make a winforms-style api for Avalonia which would actually fix some of the problems including cross-platform support (including mobile; avalonia is pretty slick and it's unfortunate that microsoft hasn't just hired the people making it rather than focusing on stuff like winui and maui), but I think it stalled because among people making desktop windows applications there simply isn't that much interest in using a winforms style api in 2023.


Back in the WinForms era of .Net, I got the impression that anything you could write in VB you could write in nearly-identical-line-for-line C# (minus the language syntax differences).

Once it became just a subset of C# with different syntax, I suppose it had little reason to exist because nothing made it special anymore.


I started my career with FoxPro for DOS, dabbled a bit with Visual FoxPro and then I found Visual Basic. Spent a lot of fun years with it before moving to ASP and web development in general. Not exactly sure what was the reason for its demise. I guess .NET killed it.


> I would go so far as to say we've gone backwards in a big way.

I would say you probably just don't remember how bad VB was. As a language its extremely simple and misses most of the modern niceties we take for granted, no iterators, no maps, no anonymous functions, no multidimensional arrays, no objects, the list goes on.

I remember when I moved from Basic to VB the single most impressive thing was that it AUTOMATICALLY KNEW THE LINE NUMBERS! YOU DON'T EVEN HAVE TO WRITE THEM ON EVERY LINE! If you made a mistake IT COULD JUST TELL YOU THE ERROR, no more looking up codes on a table in the back of a book.

Basic was never supposed to be good to use it was only ever supposed to be easy to learn.


With VB.NET, VB basically turned into C# with different syntax. I think a lot of people in that space might as well have been writing C#, so a lot of them switched. Then separately, perhaps almost simultaneously, the Microsoft ecosystem lost relevance.


You really couldn’t beat that GUI creation system. I don’t know if we’ve ever come close.


Delphi or if you prefer the free version, Lazarus might have a word to say about that.


Another fun story:

A strip club was asking for a camera system and pos system in 2006. I already had a nice PCI based capture solution for the CCTV system but the POS software was still an unknown.

When I learned that the average cost per terminal was going to run me $700/ea., I decided to write my own POS in VB6 (Along with Receipt printer stuff, USB Card Swipe Stuff, Authorize.net Etc). This was completed in about 1 month while still living in my moms basement.

We had a lot of fun sitting in the security room popping the cash drawers as a prank and having the girls complain over the radio about them being possessed. Long live VB6!


It's similar to Microsoft Access. Not for everyone, but still did some things few other tools do out of the box.

VB was a form of relatively low code, relatively speaking to other ways of building applications.

There was a swing from the desktop to the web, but it wouldn't be unrealistic to say building web apps that render the same html/js/css became at least a few orders of magnitude more complex during that time too.

There remain personalities, belief systems and practices that believe things should be difficult and not easy to become a beginner in for it to have value for a few instead of the many.


VB6 allowed me to write apps "On Site". I'm talking crazy stuff like a customer asked for a personal phone call when the apartment building maintenance room door was opened:

1 Google VB6 LPT READ (Run a wire from alarm panel to LPT port pins) 2 Google VB6 Modem Dial (Hardcode customers cell phone and add exe to startup folder) 3 Bill the customer for 30 minutes of "software development".

I've never been more productive than with VB6 and sample code of the web. I do not write software for a living and the lack of tools like it are a real bummer.


>"nothing I have found compares to that development experience today. I would go so far as to say we've gone backwards in a big way"

>"I have yet to find a tool that can allow me to be as productive in so short a time as Visual Basic"

I have and do program in many languages. From my perspective - for type the of applications usually done in VB Delphi / Lazarus would run circles around it. Both productivity and performance wise. It is also possible to do things one simply can not accomplish in VB.


Take a look at this article and chonkthread from a few months ago

https://news.ycombinator.com/item?id=35192913


VB lives on as Visual Basic for Applications, but you have to have MS Office to get that.

What is lacking is a compiler to make a stand-alone file. MS Access has the most robust Application object, in my experience.

Basic as such has, e.g. https://www.freebasic.net/

> What problems it had that caused them to abandon it?

My understanding is that the ActiveX goodness that makes VBA quite handy for your stand-alone needs is also a security nightmare.


Popularity of a language is like a popularity of a soda - it's never about the inherent quality or features, but always about the company that stands behind it.


You might want to check out Lazarus if you can stomach Pascal


> despite all the advances in technology since then, nothing I have found compares to that development experience today

You are going to have to qualify this a lot more, because it is absolutely not true. Coding VB was...fine. Language features were primitive, even compared to what was available in the mainstream back then. The tooling was fully proprietary and expensive. Languages and IDEs today are 1000x better in every way.


It's the Python of yesteryear. Nothing about the language was great but the ecosystem was amazing.

CRUD app creation was almost completely point and click, VBA was easy and you could take data straight from a document and process it in complex ways, the database integrations were great and easy to use.


The development paradigm was great. I wish three were something similar for Python, having to switch to TCL/TK for UI stuff is extremely annoying.


Because you could only use it if you paid for it. If they had released it for free, as in beer, lots of people would have made wi does apps with it.


It was killed by VB .NET, a different language that looks similar to VB6/VBA on the surface but has nothing at all to do with it.


The web is cross-platform and easier to deploy. The (non-?)existence of RAD tools for it vs VB pales in comparison to that advantage.


My two cents: the web. It's not that VB died, it's that we stopped targeting the desktop for intranet line of business apps. It all went to the web. Deployment and support of web apps is an order of magnitude easier than thick clients, maybe two orders of magnitude easier. As an industry we never looked back.


"On Error Resume Next"

I like a lot about the language, but let's not let nostalgia run away with some of the bad points. And that's not even getting into COM/OLE registry mess, or difficulty of handling c type/vb type mappings when interacting with the api. A lot of what I liked, I now like about powershell or python.


I'm curious if I should have been more kind to Visual Basic because I went with C# and I'm still in love with Ruby. There doesn't need to be a barrier to more powerful and efficient coding, as far as I can see. Even when the technology allows expression, the human element is usually the barrier.


Unpopular opinion: VB.NET was superior to C#, especially in code-readability.

I've coded in dozens of languages, including a long spell as a video game developer writing x86 and C++. VB.NET was my favourite development language and I wrote some insanely complicated code in it.


I totally agree. VB 1-6 was an interesting ride. Abolishing VB6 was a travesty. Once upon a time we had true RAD code, it was VB6. I do not code seriously much anymore, but when I do I miss the simplicity of fixing problems and not worrying about the code as much.


Honestly it's because Microsoft sucked at marketing. There were so many confusing name choices and unclear development guidelines that people simply stopped using it. Even now developing for windows is a pain and that's because there is like 5 different ways to build an app there.


It didn't die, it was murdered.


I'm the co-founder of Budibase and we've spent the last 5 years building what we believe is a better, faster, open source replacement for VB.

Check it out:

[1] https://budibase.com


This seems like an asshole move when there already is Librivox for decades.

Many of the readers of Librivox are not great, but I'd rather have the worst of them over AI.

Even a future better AI that knows more about when to pause and how to pronounce things the right way from context, will still be lifeless because it can't actually understand the full context, only the surrounding words. The actual full context of a given word or phrase requires not only pattern-matching the surrounding words, but having a sense of self and inserting that self into the described situation, and applying that selfs response to that, which will be not only more lifelike and realistic and meaningful, but also be a bit different for every different human reader. Good readers aren't simply doing it more correctly, their own unavoidable interpretation of the text is in their reading, even if they are trying to be a robotic neutral newscaster.

Sometimes I'm actually annoyed by how a reader reads a given sentence differently than I would have. Like they failed to realize what the thrust of the thing was and focussed on some other part. But even those are better than an AI that will either always apply the same algorithm, or worse, maybe varies it but only randomly, not as a result of having a personality that colors everything.

I guess at some point they will be able to make AI's that can fake the quasi-random-consistency of a personality. If someone can describe the problem like I just did, then someone else can code up a response to it. And then it will be good enough to essentially fool most not-very-perceptive people, and that will suck because it means we won't have a choice to avoid that crap any more. Much content will simply only be produced this way, because it will be cheaper to make and good enough for most people, and so will sell. Once it's good enough to sell, that's it, that's what happens almost exclusively after that. Like bluetooth headphones.


My company was using VB for developing test suites for some hardware in the 200Xs. It died for me when I've discovered Python and suggested to my management to switch existing test suites to Python.


I don't know how to tie this in. Gambas is a Visual Basic dialect for Linux Linux and FreeBSD/BSD. It gives me the same vibes as my early VB experiences and I think I deserves more love.


VB is just C# with a syntax that would extremely unfamiliar to most programmers. Basic itself is no longer commonly used to teach coding so I can see why there would be little demand for such a language.


VB (and BASIC in general) has a legacy of being a procedural language. In the late 90’s and early 2000’s, there was a massive push to leverage object oriented programming and design. The births of Java in the 90’s and then C# in the 2000’s were clear catalysts to abandon procedural programming.

Of course in .NET VB has nearly all of the OO capabilities that C# has, but I think most developers just decided to go “all-in” on object oriented programming and learn C# and graduate from their procedural past.

A lot of colleges taught Java and moving to it or C# in the workplace was a much more natural process.

There are BASIC alternatives and they are fairly strong offerings, but I think OO and functional programming are the standard today.

That means python, Rust, Golang, Ruby, C#, and Java are the mainstream languages.


Honestly, I was never a fan of Basic but I still don't understand why there isn't a GUI app builder as productive as the VB6-era tools were for any language.


You can still build WinForms apps using C# or VB.NET, and they will even run on the latest .NET (v7). I built a little WinForms GUI utility that takes a CSV file with mappings from old URLs to new URLs, and generates a rewrite map for use in IIS, when rebuilding a website. I just place all my logic in a separate project so I could replace the UI in the future with a web interface or WPF, etc.


Devs don’t design user interfaces anymore. There are separate disciplines for user experience, graphic design, front-end development, API development, and data storage choices.

There’s no reason to have a drag and drop UI builder anymore.


not everything is a team effort, and the desire espoused all over this thread for an equivalency clearly demonstrates that there is a 'market' there.

when some small developer is making a silly one-off app for a mom&pop local store to facilitate a one-off kind of task they aren't interested in handing off work and splitting meager profits. not every company has the whole "front-end/back-end/devops/ux/design/management" paradigm going on.

the reality is that microsoft , a fairly litigious group of people, abandoned a concept for their own reasons; and the rest of the market doesn't exactly know where they can step in that minefield of offering equivalent features to a piece of software that is still on life support by a very very large/valuable/litigious company.


There was a time when shareware ruled the world before the World Wide Web. VB was king. Even corporate America was all in on VB, Powerbuilder, and Delphi.

But once the Internet truly arrived and building complex, distributed, highly interconnected systems became normal, the tools were only going to get more sophisticated.


You should tell my employer, state Government, this.


I’ve seen an upswing in state government software engineering sophistication. Mayhaps it hasn’t reached you yet.


I was typing "visual programming fails because of collaboration", as in testing, code reviewing etc, but then graphic designers can collaborate on projects so I don't exactly know.


My personal reason, which is probably unique:

VB 1.0 was extremely buggy, making it unusable for my use cases.

VB 1.1, which fixed the bugs I was encountering, was a paid upgrade.

I switched to Linux and never looked back.


VB 5 and 6 were where things worked. They both had native compilers.


as a VB replacement https://www.lazarus-ide.org/ seems quite solid


While I was never a big fan of VB, I agree that the developer experience has been getting worse for most languages since the early 1990s.

Do you have a top 3 list of things you miss?


I got the feeling that a lot of the corp/small business apps that used to be developed in VB and deployed to PCs have been replaced by Web-based apps.


Steve Ballmer is the answer you are looking for I think.


No fault of its own. We simply stopped building windows apps and started building for the web instead. The best web apps still pale in comparison.


New version of VB was VB.net.

People still used VB.net primarily as they were familiar with VB.

But the new projects gradually took over C#.net, as it sounded more cool.

VB.net died after a while.


How about some love for Quick BASIC? That was my big Christmas present once upon a time when the dinosaurs still roamed the earth.


Oh you spoiled little children with your integrated development environment and in place editing. Real programmers used GW-Basic with consecutive line numbers.


Maybe it didn't. What I mean is, maybe the purpose for VB died and thus the language just kinda went away.


It's not only related to Visual Basic. It's an ecosystem. Some animals die, some animals born.


I learned VB when I was 8 and built a few games with it. I wish I kept coding :'(


I think the path from VB.Net to C# was too easy and C# offered too many advantages.


if you need to fill a RAD niche in your workflow. Pascal is still around with a nice IDE https://www.lazarus-ide.org/


I feel as if I remember using a VB compiler back in the late 80s. Am a hallucinating?


VB was first released in 1991. If you're certain that you remember it from the late 80's, then you may be thinking of QBASIC. I first learned to write code in QBASIC running on MS-DOS.


I had a computer graphics class that used QBASIC around 1994. It was probably already outdated, but switching graphics modes and making sprites animate was actually easier then than what you find now. I'm certain it's because there is so much more you can do now, but that feeling was exciting! I actually had my first computer graphics class on an Apple IIe in 1993, and that was definitely outdated at that time. I built a fish bowl with waving seaweed and a fish that would swim to the right and reappear on the left.


C#/WinForms is the spiritual successor to VB. Even better than VB6.


IMO the OOP trend of the 90s (Java, C++, Objective-C) made VB look bad.


in one word - CSS.

CSS has killed VB.

How? when you need to build any application with custom graphics or UX, in VB you are gonna writes tons of lines of code, while using CSS you just write 2-3 declarations.


VB died because Microsoft killed it off (through other products).


Because C# as a contender to Java had to succeed (and the CLR)


Easy answer: the index of arrays doesn't start at 0


Visual Basic died for the same reason that Win 7 & Win 8.1 died.

..


Windows 7 only died because Microsoft said so, and then others listened. Fearmongering about security updates, I don't get. Let's say you get a virus, then you nuke + reinstall, while keeping user data/installers on separate drive. That is good enough "security" for me.

The second part about "others listening" is more problematic. I'm talking about version numbers for node, docker, python, etc. So you're then forced to use something modern, so linux in a VM.

Typically I will approach development with a boycott on technologies that require new oses. So Python 3.10 it is. Also node/npm to me just sucks. I like older stuff, because it was better, like js/html/css. The document is the document, not running through lots of build tools to finally become the document. Or stuff that simply still works. To me it's easier to use a game engine -> HTML5 then node + react for web dev. Yes it's bad for accessibility. But it's not based on brittle building. When I'm targeting "old works" it has the advantage that the software AND dev environment still works later (assuming win 7). I wish less languages/frameworks/etc on would stop deprecating it.

It's still the best os to actually use. You get git bash so normal commands work. Win 7 feels like linux without randomly nuking your os for your terrible mistake of enabling automatic logon or something. How dare a user change a setting, I guess you're nuking your os now. In a VM linux is good because snapshots mostly alleviate the random breakage.

Typically you only have to re-install every several years. And honestly linux is like way better than windows obviously, EXCEPT the random breakage and badly coded interactions and environment fragmentation.

Win 7 just boringly works well. No injected ads. Low resource usage. Os doesn't hari-kiri randomly

</directionless misguided rant>


As the 90s commercial goes, Why Ask Why?

Celebrate good times


Windows only desktop applications died.


Same reason as Borland Pascal.


I guess you never heard about Free pascal/Lazarus then.


Python is the new VB


Not if you are trying to create a GUI.


I've enjoyed several Python programs over the years that had a nice Windows GUI interface

https://wiki.python.org/moin/GuiProgramming


Me too. But it just was never enjoyable creating those UIs. I have tried almost all of them. The closest Python had to VB was Boa Constructor. It never really took off.

https://boa-constructor.sourceforge.net/Screenshots/

Python is light years ahead of VB6 in productivity in scripting, except when it comes to putting together a quick database frontend or just any other GUI app. My favorite was Delphi over VB. Nothing ever came close in Python in GUI building, even 25 years later.


they did linq badly after linq2xml and linq2sql


On Error Resume Next

It never dies


No stickers.


[flagged]


If Microsoft had put more effort into Internet Explorer and VBScript (https://en.wikipedia.org/wiki/VBScript), today's web could look very different, and in some ways better.


I can see where you are going with this train of thought, but Microsoft really blew it when it came to providing too much functionality to the web before having a fully formed plan. The amount of security issues was a precursor for basically every web based plugin technology that came after it (ActiveX, Java Applets, Flash/Macromedia Director, Silverlight, etc.). I'm not sure on Silverlight vulnerabilities, because I had been forced to learn ActionScript 3 with Flash, and it left a bad taste in my mouth. It's very possible that Silverlight wasn't full of security issues, and was a good technology that was just killed along with general plugin technology when Apple stopped supporting Flash.


How many incompatible languages called VB-something did Microsoft create? There's at least the classic Visual Basic, VBA, VBScript, and VB.NET.

Although to be fair, the distinction between the language and libraries has never been very clear in BASIC variants.


Although not starting with VB, there's also QBASIC, as well as another BASIC dialect I believe Microsoft bought in their early days. QBASIC isn't a drastically different language than Visual Basic, VB just added graphical components.




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

Search: