Ask HN: Why did Visual Basic die?
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?
531 comments
[ 42.6 ms ] story [ 343 ms ] threadhttps://en.wikipedia.org/wiki/Visual_Basic_(.NET)
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.
There are things like WebFlow and FlutterFlow but those tools feel clunky by comparison.
Netbeans GUI builder was more powerful than VB's in some ways but just made simple things complicated.
VB.NET is the same but so much more evolved. Also the runtime below was switched (surely for the better).
However, like outlined in other comments: VB.NET is a OOP language which handles procedural/functional code as a subset while VB of the 90s was purely procedural.
[0]: https://mspoweruser.com/microsoft-starts-deprecating-visual-...
- 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
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.
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.
Excel is perfect for building proof-of-concept apps and Microsoft has a cloud offering called PowerApps that use a somewhat similar "Excel concept." I have built a significant app in PowerApps...not recommended. If you don't have a development team Excel is good. Same for PowerApps. Very painful if they get big. Keep things simple.
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.
At least my spaghetti code goes into one direction only...
Excel has long had an option to display 'precedent' and 'dependent' cells.
You can actually see the spaghetti right there.
https://support.microsoft.com/en-au/office/display-the-relat...
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...
It was an excel file created in pandas that threw an error on english commands but worked if the code included german ones.
I don't know how or why that happens, I just know I need to get away from it.
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.
You would think the ideal would be to allow everything Excel currently does, but also have some other model with more separation of code, data, and visuals, like node-based programming and separate cloud-synced pure tables.
Excel can almost cover a lot of "real programming" use cases, but not quite. The upgrade path seems to be Excel to Access to Custom app, rather than Excel to Excel but with more of the advanced features.
But I really like Excel for allowing me to just plop stuff down wherever when I'm brainstorming something, or just want to do a one-off calculation before I quit-without-saving.
Then it's pretty bad but still better than writing some custom software like people would probably do without it.
Because we have been doing it that way for almost 4,000 years!
https://en.wikipedia.org/wiki/Spreadsheet#History
Humans have organized data into tables, that is, grids of columns and rows, since ancient times. The Babylonians used clay tablets to store data as far back as 1800 BCE.[16] Other examples can be found in book-keeping ledgers and astronomical records.[17]
Since at least 1906 the term "spread sheet" has been used in accounting to mean a grid of columns and rows
What you want is the paradigm of Numbers from Apple. Their office suite is good, and it has the benefit of being opinionated. They're not trying to ape Microsoft, like all the open-source projects.
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.
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.
Free, fast, accurate. Pick any three!
http://gnumeric.org
I find it's an overblown issue. Those of us that prefer functions in English can just set Excel to use it. When someone sends you a file it displays in your chosen language. And having the default being localized makes it usable for the majority of people who don't speak English.
I 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!
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.
http://www.pages.drexel.edu/~bdm25/gnumeric.pdf
http://www.phusewiki.org/docs/2009%20PAPERS/SP06.pdf
http://www.tandfonline.com/doi/abs/10.1198/tas.2011.09076
Also lack of accuracy in calculating some complicated statistics that "nobody" uses is not really a calculation bug.
Also most of those come from the fact that Excel has a precision of 15 digits.
Let's see it. Fill the visible part of a sheet with it, conditional format the cells, red for negative etc.
hit f9 to recalc and see a big bunches of cells turn red. Fixed random function to return a random number between 0 and 1.
I haven't worked on gnumeric for a long time - examples came from gnumeric.org
Excel was really bad for everything beyond basic arithmetic, way beyond the important issues with floating poiny listed here https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...
Anyone seen anything about ms actually fixing the bugs? I haven't.
I am not sure what that means.
Excel keeps all the bugs for backwards compatibility. So the sheets made years ago still provide same results. In few cases the depreciated some functions -> the old ones still work, but are relatively hidden and the users are encouraged to use the new ones.
They probably should do the same with the statistical functions that supposedly have problems due to rounding. But that cannot be fixed - precision is up to 15 digits.
Also if you wanted an article that talks on Excel precision, you can start with the wikipedia page:
https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft...
Excel has many problems, but you linking to few website that supposedly prove that "Excel bad" - but at the same time - those exiles simply dont work, is somehow very funny.
>Excel keeps all the bugs for backwards compatibility
They /fixed/ rand(). Announcements. Fanfare. The fixed version returned numbers less than zero.
yet again excel's calculating issues go way beyond double precision floating point truncation.
I've been trying to get him to use Julia for that second step since I absolutely hate Matlab, but I honestly don't fault him for using Excel in the initial phase.
If Excel stops working, financial institutions around the world would collapse.
Actually that's really awesome, I think.
My goal is basically to never touch Excel again. But, I have to admit - that 2D mixture of data and code called "a spreadsheet" is honestly a pretty cool programming paradigm for a lot of tasks. It can be horribly abused... but so can everything.
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
Afterwards, forget it. Maybe one.
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.
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.
It wasn't difficult, but at its core, I had to do it because the end users didn't feel like using some other interface - they really didn't want to leave their excel spreadsheet.
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.
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.)
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.
Your definition of "ease of use" is amazing. /s
Yeah, the web ain't perfect, but it did win... ads got worse, though =/
So it's not that Microsoft missed it, it is that a big shift happened and it was specifically targeted against them. There's nothing they could have done, except to embrace it, and they did. Visual Basic Script existed and was very popular for a while. IE4 ruled the web.
The shift to web based technologies is a Google and an open source win. And it is also an inferior experience. That was the price we paid =)
Even ASP and IIS etc. insisted on having its own stack -- superior in some ways, but way less compatible and more expensive. Again their own doing. Free/cheap won out, I guess :)
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
(edit: how the heck do you actually properly make hyperlinks on HN? I always struggle with this)
For me: Delphi or Lazarus
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.
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.
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.
Although to be fair, the distinction between the language and libraries has never been very clear in BASIC variants.
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).
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.
https://learn.microsoft.com/en-us/aspnet/core/tutorials/choo...
If I am doing desktop development, you can bet I am still using WinForms, which are relatively easy to debug (if not as pretty) as WPF. I am usually building internal tooling, without paying customers, and sometimes for a user base of just me.
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.
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 would LOVE it if I could, though.
You've piqued my curiosity.
And "control" here means anything from simple labels and buttons up to database connections and embedded COM objects.
Literally anybody could bang out a simple Windows .exe like nobody's business.
It would have been really cool if Microsoft included it in the OS like they used to do with QBasic.
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.
VB never had that.
Great to see you here, Merdedydd! I was thinking about sending this thread to you. I discovered Anvil in a similar thread years ago and am very happy I did.
VB6 used to work with oracle across network.
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.
And it was so easy for ODBC and other configs to get trampled on by users and installers running amok over existing settings.
Everyone was root on their PC in those days. The opportunity for users to screw things up accidentally was everywhere.
Consider that scaling your database has to be done anyway. Your web app will bottleneck on the DB too. The only difference is number of connections assuming you keep them open (but there are multiplexers for that, and many business apps don't need them anyway, RAM is cheap enough).
With stored procedures you can implement whatever logic is needed for maintaining your data.
Can you still build a system, and operate it? Sure. A lot of us did. For small to medium scale systems, it was manageable. But there is a reason we abandond 2-tier client server 20 years ago. While it made building CRUDy business applications vastly easier for the developer, it was a systems nightmare.
(It also led to crappy user experience for any application that wasn't itself inherently a CRUD record keeping job, because it inhibited application designers from thinking of the application as anything other than CRUD. But that's a different argument for a different day).
Another thing people tried was putting the VB app on a network share so it wasn't installed on each machine, but I think all the ODBC and other config still had to be local on each client.
Powerbuilder apps were similar.
All of our VB programs, com objects and assets were loaded into a MS SQL database table. When our generic launcher program started it would query the database, figure out what app the customer had purchased and downloaded the necessary objects (if the cache was stale). If we accidentally uploaded a bad version, a rollback to a previous version only took a few administrative clicks.
A good part of my job was to make sure that the companies domain structure and network settings were sensible.
No disagreement about how the web is still easier/cheaper to administer from a centralized point.
VB made it to the web :-)
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 :)
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.
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!
Compliance is a matter of ensuring that you are following correct practices, and possible audits.
In exchange you get a program that can run on any of billions of devices in seconds without having to worry about local deployment.
If all you want is something like VB, you can opt for some of the low-code/no-code options mentioned elsewhere that are built on top of web technology.
I’m not saying that for what VB was used for, it isn’t a better solution. I’m saying that we ask our computers to do a lot more than we did 25 years ago, and tools like VB can’t do as much as the easier to write languages that have emerged in that time.
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.
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
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.
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.
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.
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.
There’s no reason to have a drag and drop UI builder anymore.
when some small developer is making a silly one-off app for a mom&pop local store to facilitate a one-off kind of task they aren't interested in handing off work and splitting meager profits. not every company has the whole "front-end/back-end/devops/ux/design/management" paradigm going on.
the reality is that microsoft , a fairly litigious group of people, abandoned a concept for their own reasons; and the rest of the market doesn't exactly know where they can step in that minefield of offering equivalent features to a piece of software that is still on life support by a very very large/valuable/litigious company.
But once the Internet truly arrived and building complex, distributed, highly interconnected systems became normal, the tools were only going to get more sophisticated.
- LISP environments
- Smalltalk environments
- Symbolics genera
- Mesa and Cedar
- Apple's Newton
Besides things like Oberon...
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.
https://news.ycombinator.com/item?id=35192913