Ask HN: Why did Visual Basic die? | Hacker News Reader

Ask HN: Why did Visual Basic die?

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

View on HN

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.

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

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?

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

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.

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

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.

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.

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

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.

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/

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.

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.

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.

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.

Maybe:

a) https://www.nubuilder.com

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

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.

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

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

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.

"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

> 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 can't understand why so many finance people won't just learn 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.

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.

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()

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.

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.

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.

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.

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.

> 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

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.

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.

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.

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!

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.

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

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"

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.

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.

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

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

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.

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

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.

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/

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 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 =)

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

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

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

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

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.

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.

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 ?

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.

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.

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.

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.

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.

Reply on news.ycombinator.com