[richx]

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.

[foepys]

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.

1: https://www.hanselman.com/blog/dark-matter-developers-the-un...

[bgroat]

I don't want to say "anti-pattern" because that's not what I mean...

But new tech should be the last resort.

If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness

[Retric]

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.

[DaiPlusPlus]

> IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.

That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.

[yen223]

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.

[_0w8t]

React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks.

If one wants stability, then PHP has a way better track record.

[mattmanser]

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.

[pjmlp]

I have not seen people switching to rails in droves over here, it was a fashion wave that came and went.

Apparently they are all now learning Elixir after a short migration wave over to Clojure.

C++, Java and ASP.NET over here for the last 20 years.

[valenterry]

ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.

[nicoburns]

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

[tl]

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.

[rablackburn]

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.

[tonyedgecombe]

HTML and css are easy

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.

[polskibus]

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.

[fuzzfactor]

I see no legitimate way to call a phone with no filesystem access _smart_.

[bgroat]

You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age

In descending order of importance.

When choosing between any technology choose the one that is most stable.

If multiple options are on a stable release, choose the one that is best documented.

If multiple stable releases have excellent documentation, choose whichever is oldest.

I don't think this framework is always (or even often) right. But it works for me

[makapuf]

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.

[josephg]

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.

[smitty1e]

I've never ever tried VBA.Net.

But my private NVBC (NecroVisualBasiCon) repo has some great stylings that I tap into at least once a year.

Nevertheless, when are they going to relase Office with Python bindings included?

[jussij]

One minor correction which is there is no such thing as VBA.Net.

There are basically three VB ecosystems.

Visual Basic which many refer to as VB6 and it represents the last version every released.

VBA which is Visual Basic for Application and lives on to this day as an embedded language for Microsoft products like, Word, Excel, Outlook etc.

VB.Net which is an implementation of the Visual Basic language running on the .Net Framework.

[tonyedgecombe]

There was also VBScript, one of the two active scripting engines shipped with Windows and available from IE and WSH.

[JJMcJ]

Not exactly Python bindings but there is a package called Xlwings that provides a Python<->Excel interface.

Somewhat clunky and slow but it does work.

[dccoolgai]

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.

[sokoloff]

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.

[Pasorrijer]

This has gotten a lot better with the internet.

Almost everything in VBA can be found with a simple Google search, and Microsoft's technical documentation online has gotten very good.

[kgwgk]

In the dark offline ages there were also those things called "books" :-)

https://www.oreilly.com/library/view/vb-vba/1565923588/

[sokoloff]

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.

[kgwgk]

That’s true. But the ability to record macros, as you mentioned, and the object browser alleviate the problem at least in part.

[airstrike]

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.

[ddingus]

This is the part which saves crazy time:

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.

Check this thing out:

https://github.com/tilleul/apple2/tree/master/tools/6502_ass...

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.

[airstrike]

You misunderstand me. I'm not arguing one should replace Excel with Python, I'm merely talking about VBA and the VBE

[pessimizer]

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.

[ddingus]

Perhaps we misunderstand one another.

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.

Which is why VBA is still a thing.

[airstrike]

> Perhaps we misunderstand one another.

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.

[ddingus]

Ok, I see it. For the record, I would love Python as replacement for VBA.

I also agree on quality.

What I do not see is the value added to improve quality.

[passivate]

>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

Any examples that you've come across?

[airstrike]

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

http://www.cpearson.com/Excel/VBAArrays.htm

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

[passivate]

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.

[airstrike]

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

[passivate]

Its all good. I used to be a dev many years ago, so I just try to stay informed as much as possible now.