I love VBA, it’s so easy and powerful. My first job was being a developer/consultant at a big 4 firm, developing a disclosure management software with VB6. It even had a ORM to map objects from SQL queries. It was lightning fast, Office integration so superb. Later it was ported to .NET with a proper client/server architecture, still it never reached the speed and simplicity of the VB6 version.
People are downvoting you but are overlooking the fact that it's not always about making things in the newest tech but more often than not about making things work. Most software will only be seen by industry specific users that don't care that the program is React Native and runs on AWS. A simple VBA script is sometimes completely sufficient to input the data into a spreadsheet. Scott Hanselman called devs doing this "Dark Matter Developers" [1].
32bit VB6 programs are still able to run on modern Windows 10 machines, even on x64. The hours that would've been lost on porting everything to the newest macOS can be spent on new features or customer wishes. With the .NET Framework it's even possible to seamlessly use VB and .NET in the same program which combines old and modern technology. It's officially unsupported but it works and even gets bugfixes sometimes.
That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.
A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world.
We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
The MVC and ORM revolutions are the counter-argument to this.
Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves.
As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know...
JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.
> If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness
I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.
It's 100% true, but only in broad strokes. My personal ladder is
- paper
- text files / spreadsheets
- desktop apps / local db
- SSR web apps / single database
- SPA or mobile app / cloud storage
The only thing that challenges that is the reality that around a decade ago smartphones with tiny screens and no filesystem access eclipsed desktop computer, and we're still reeling over how much more expensive that makes development.
Are SSR/SPA solutions really that much more expensive than local apps to develop?
The start of my ladder looks much the same as yours except I jump from local files straight to single database SSR/SPA. Maybe slightly more complicated than a local app because you need auth, but when prototyping something I just use basic auth to start.
Chuck it up on a $5 DO box and you instantly get:
- Multidevice access, desktop and mobile (write mobile-first css and the tiny screens aren’t a problem)
- a UI that’s trivial to hack on (HTML and css are easy)
- likewise, a technical base that’s easy to extend. Drop in react, build out the api side and use it as a source for other projects, etc
All this assuming you have reasonably reliable network access, and even then you can build it as a clever PWA falling back to local storage if you need to (I think, prototyping that is still on my todo list)
Heck, save yourself $5/month and stick it on a raspberry pi at home.
It’s truly a golden sweet-spot for personal software tools. The only external dependency that irks me is needing a domain name.
All of the constituent parts are easy. It's when you tie it all together that it starts to get complex. There is no doubt there are many more moving parts in a modern web app compared to desktop. I did a few VB projects and I needed know two things, VB6 and a database.
Of course we can't go back, enterprises are rightly presenting their systems directly to the customer, you can't do that with a desktop app. None the less it does feel more complex than it needs to be.
> I did a few VB projects and I needed know two things, VB6 and a database.
Desktop apps are relatively simple if you only need to target one platform. Both windows and macOS have good options accessible from managed languages. But if you want to do cross platform then the complexity rockets.
Yes they are more expensive to develop. With a winforms or wpf gui you can iterate much faster than with a web one while supporting rich interactions, thinner tech stack, faster feedback loop.
My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.
I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done.
Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet.
For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use.
For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.
20 years later it seems I spend months fighting overwrought frameworks like Webpack and React to get the equivalent productivity I could get in one day with VBA.
My frustration with VBA is that it didn’t seem very well documented.
If I could record a macro that was “close” and examine it, the ecosystem was very productive. Once I wanted to go beyond that, it seemed like there was an undocumented chasm to cross.
It wasn’t the VB part of VBA that wasn’t well documented, but rather the “for A” part that was spotty. The application automation model wasn’t as thoroughly documented as most of Microsoft’s stuff. This was well after the Internet was seriously prevalent.
Things like destroying [iff present] and recreating Excel charts from scratch, including generating all the series labels, shapes, etc., updating elements in a word doc from an excel sheet, generating on-slide progress indicators in PowerPoint.
VBA is great for many things but it has its flaws.
The biggest problem with it is really that the tooling around it is decades old so it hurts your productivity. Maintaining VBA code bases is a painful experience, the IDE sucks and the language has enough quirks and shortcomings that it forces you to take long detours to accomplish what would be very simple tasks in more modern languages
The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python
Oh, I almost forgot. VBA classes are absolute misery.
The loving part of VBA is its interoperability across the Office suite, but there's no reason why that couldn't be done in, say, Python
I agree with you, but Python and pretty much every code environment is missing a few things that create a pretty high barrier to entry:
For a whole lot of cases, VBA is not even needed. People put data into cells, operate on it with formulas in other cells that drop output into still other cells which are then used to get output.
Input can be almost anything these days.
Formulas have a well defined, easy to understand syntax that work across a wide variety of operators. Simple copy / paste operations make sense, often with the intended data mapped right in. (given people are a little organized)
Output can be almost anything these days too.
And it's live. Make a change, see it happen.
That's real power! People don't have to know much to make it all work either.
I have been using Excel to transform business data for years, model business and a lot of other things, and as a rapid prototype system. I can write code too. Often I do, but the more specific and or variable the task is, like a one off need to solve yesterday, the more attractive just banging it out in Excel becomes.
Should one get super crazy, have one of those outputs from Excel be a working program. No joke. A script file is one of my favorite outputs. Mash the data up in Excel, and once the plan of attack is clear, execute the script and watch it run on the real system.
It's a perfectly usable, and I would suggest one of the easiest, assemblers I've ever seen! I ran it on my mobile. Crazy.
I just used it to knock out a little routine for a retro-game project I'm working on and was kind of stunned at how lean, accessible, functional this really is.
For Clarity: Replacing VBA with something else costs more than the value add at present, and it's because Excel is the gateway drug into VBA. By the time people reach for VBA, they already are familiar with a lot of it.
VBA is very stupid, and I facepalmed a lot while learning it, but after you get used to it you can write in a very functional, clear, low/no-side effect style, with reasonable polymorphism using interfaces. It's still bad, but it's available. And I can make the UI out of spreadsheets and output still more spreadsheets, so business people aren't scared of it at all.
edit: I'd certainly rather be writing VBA than js, which is what the seem to be replacing that type of automation with, not python.
VBA and VBE being replaced with Python would require so much work... and there is a crazy amount of code out there doing an equally crazy amount of work too.
All the points I put here are why doing that replacement work doesn't really add much value.
I understood you. My reply above was in relation to your:
> For a whole lot of cases, VBA is not even needed. People put data into cells, operate on it with formulas in other cells that drop output into still other cells which are then used to get output.
* > Input can be almost anything these days. *
Nobody is arguing VBA is always needed and inputs being almost anything has no bearing on VBA's shortcomings.
* > Formulas have a well defined, easy to understand syntax that work across a wide variety of operators. Simple copy / paste operations make sense, often with the intended data mapped right in. (given people are a little organized)
Formulas are great, no argument there. Still irrelevant to the "VBA has plenty of shortcomings" discussion.
> Output can be almost anything these days too.
> And it's live. Make a change, see it happen.
> That's real power! People don't have to know much to make it all work either.
You're describing spreadsheets. I love spreadsheets. I should, as I often spend 100 hours in a single week working with them.
> (...)
> For Clarity: Replacing VBA with something else costs more than the value add at present, and it's because Excel is the gateway drug into VBA. By the time people reach for VBA, they already are familiar with a lot of it.
You haven't really proved that point at all. You talked about spreadsheets and then concluded something about VBA, which doesn't follow.
————————————————————
As for your reply above
> VBA and VBE being replaced with Python would require so much work... and there is a crazy amount of code out there doing an equally crazy amount of work too.
The best time to plant a tree was 20 years ago. The second best time is now.
The same was true about Excel 4.0 macros and yet we did it. Python or [insert your favorite language] doesn't need to replace VBA overnight. It can be available alongside it, just like VBA was available alongside Excel 4.0 macros for decades when introduced. Unsurprisingly, XLM felt out of fashion and VBA took over as the superior choice.
> All the points I put here are why doing that replacement work doesn't really add much value.
Sorry, but you really haven't made those points.
> Which is why VBA is still a thing.
VBA is still a thing because Excel has no real competition as an Enterprise spreadsheet app. But its popularity and prevalence don't speak to its quality.
>the language has enough quirks and shortcomings that it forces you to take long detours to accomplish what would be very simple tasks in more modern languages
I've already mentioned VBA classes. If you want to read , just read through Chip Pearsons' great Arrays library. 30 functions just to do what you should be able to do natively in a high-level scripting language such as VBA
Imagine how painful your experience would be writing any decently complex reusable code in VBA without knowing about all of the edge cases covered by Chip in that module
Oh, I was mainly interested in your view to kick off a conversation. I wasn't sure what you meant by long detours. I don't program in VBA, so I was interested. From the outside, it seems like a powerful language for non-programmers to implement business logic.
Sorry, didn't mean to sound rude at all. I guess I was a bit on the defensive given all the pushback I was getting elsethread
It's hard to really pin it down to a couple of things, but after spending some time in it, you quickly feel the ergonomics aren't really great. It's just a lot of typing to get basic things done like inserting an element into a 1-d array.
For such a high-level language and one directed at non-programmers as you mentioned, you'd think that sort of tooling would be available natively
