The difference here is that Linux devs would get rightly chided for building entire applications in shell scripts. The existence a "glue language" isn't a bad thing, rather, it's a good thing. But when you wake up to find that your whole project is made of 100% glue, you might consider that a bit of a mess.
Are entire VBA projects really that ubiquitous? As far as I can see, there are really two category of those: first are the huge proprietary plugins from large B2B companies that serve as a way to deeply integrate their products into Excel Spreadsheets, and the second are more like extremely customized tools built by the enthusiastic tinkerer of a non-technical team to make a complex and repetitive task easier.
"There's this one guy who doesn't really know how to program, but he made some software that benefits the company. This software is now so complex the original creator is in way over his head, but continues to work on the software anyways, and it'a a huge mess" is category 3. I've seen it happen multiple times.
This happened to a friend of mine. He had no programming experience but was tech savvy.
The organisation was using an excel spreadsheet for a bunch of things. The org identied his tech savvy-ness and asked him to add some functionality.
He taught himself VB for this task. I still remember the message he sent me happy he'd discovered functions. I asked him how many lines he had written, he was 3000 lines deep by the time he discovered functions.
He knew this was bad. He kept telling management this was too complex for an excel spreadsheet that is emailed around, and they should hire a developer to build proper solution.
He later left the org for greener pastures and on more than one occasion they contacted him to asking to add additional functionality to the spreadsheet. Each time he'd tell them they should hire a developer to write a real application, with a real database and they weren't interested. So he'd quote some stupid hourly rate hoping they'd go away and each time they agreed to it.
Last I heard, his spaghetti spreadsheet still lives on 10 years later.
the thing is, for the most part this is straight up good.
sure it has bugs and stuff like that, but its solving a real need. Bringing more value to the buisness than almost anything else for its cost
But if you can install matlab or torch you'd do that instead right? Which gets back to the whole restrictive IT thing where you don't have those tools. In fact the only full featured languages on the machine are javascript in the browser and vba. VBA is about 11 times faster than numpy for dense matrix math as it is compiled, and all the support math libraries like nonlinear solvers and whatnot are in dlls that were native coded, but with a lower ffi penalty than python. VBA is really a very underrated mathematical language that is mostly used for horrifically architected mission critical CRUD applications.
A few years ago I ported a UNIX log processing application into Java, that was basically a bunch of Korn shell scripts born in AIX, doing all sorts of data fetching, log processing and uploading of results into other severs, scattered around a couple of scripts and UNIX tools.
It was a bit of a mess indeed, however as the author of the Java port, I would assess the Korn shell scripts were still much better approach, despite the mess.
Reason for the port? Whoever was taking charge of the application wasn't confortable with UNIX and decided having it done in Java was easier for having random external consulting companies develop it further.
Systemd means replacing your at least somewhat standardised shell scripts with an underdocumented, underspecified, opaque scripting language. It's not an improvement.
password-store does have some strong merits stemming from its Bash implementation, but from having followed its newsletter for a few years (and made a few changes in a fork) it also brought its fair share of bugs and weirdness.
