I use VB6 all the time. Need to quickly get some custom serial port thingy written? VB6. Want to make a quick window that hosts 4 embedded VLC COM instances to watch RTSP camera streams? VB6. My craziest use case out in the field was: Wall mounting a spare mouse and soldering two wires to the left button inside, running a wire back to the office with the computer playing pandora and then writing a quick app to turn down the wave out and un mute Mic In so the restaurant owner make announcements over the loudspeakers. The code was already out there for the mixer, I just had to add a line for monitoring the parallel port and adjust the sliders in someone elses code.
I got this approved at a previous employer when I was writing some VBA/Jira automation. It's.. OK. I found it slowed down my environment quite a bit and was unstable. I stopped using it eventually.
I've had the same experience with RubberDuck. MZ-tools (https://www.mztools.com/) on the other hand is a VBA tool I couldn't work without. Doesn't slow the IDE down and stable as a rock.
Anyone that inherits any sort of legacy MS Office workflow almost always needs to interact with VBA. Access, Excel, and Word workflows use it excessively as it's the only language you can use for manipulating things "inside" the file. Sure, you can use something like DAO/ADO/ODBC to perform CRUD type operations on the file from some other program. But if you want to, say, attach some code to an event in an Access form, you're stuck with VBA. So a tool like Rubberduck is useful to people developing for legacy Office related code, especially since VBE by default isn't super great. Access seems to be dying out but Excel is still flourishing.
VBA scripting engine is built in into windows and can be called from C,C++ and more (there is also built-in old JS engine but probably less popular). Its like python 2 for linux. If you want to give scripting capabilities on windows it the #1 choice.
I think VB is still a fine compiled language and you can find a lot of use cases. On the other hand, VBA is used mostly by people who have to maintain old Office applications and basically live in MS Office. VBA is still the first choice to automate MS Office.
That's the reason I want to stay away from MS Office lol.
I had to actually google "Visual Basic Editor" to find out why it was a thing people are still using in this century, and found out that it's the editor for VBA macros in MS-Office applications. So "Visual Basic Editor" is a bit of a misnomer...
It's a bit reductive to call it "the editor for VBA macros", it's like calling Visual Studio a "template editor" because you get a set of template files when you create a new project.
The purpose of VBE is to build applications, it's an IDE.
Add-ins like Rubberduck are actually very useful in extending the capabilities of VBE and there are still millions of people using VBA every day to solve business problems.
Most people associate Visual Basic with, well, Visual Basic (as in VB6 or VB.net), not with VBA. Even the top voted comment refers to VB6. "VBA editor" instead of "VB editor" would solve the confusion I guess.
I can confirm, I am one of them. My current project is ~13k LOC and ~50 classes. It's the only way to get solutions built quickly without a mammoth of bureaucracy involved.
Thanks, I was thinking VB6, which I thought was relatively fine as an IDE for its time, although could probably benefit from some ReSharper-style improvements.
Add Javascript to VBA and allow users to use WebStorm or VS and we'd have something great. I gave Rubberduck a go a few years ago and was rather underwhelmed when compared to a real IDE (which is understandable, as Rubberducks creators don't have $$$ behind them)
