Live data from Hacker News

Why do people still use VBA?

sancarn.github.io

351–360 of 421 posts

Re: Why do people still use VBA?

#351

Earlier quoted context omitted.

Or just make it known that if you want support, here are the languages our IT staff know and can help you with. Otherwise, you're on your own.

That's a great way to go, but unfortunately the reality is often the folks go off and write stuff in the non-supported way. The business gets dependent on it, and then years later -- because IT is there to support the company overall -- IT gets stuck supporting it even if long ago they said they wouldn't. Sure, you can have an internal political fight, but it only goes so far when everyone there is supposed to be wor…

True, but that's kind of like Twitter having to go back and rewrite their Ruby services in Scala down the line.

Getting a viable Minimum Viable Product is all important. If a non-developer can hack that together in Excel + VBA, more power to them.

Going back and rewriting it in a Proper Programming Language after the fact is an acceptable cost, once you have something solving an actual business need.

Re: Why do people still use VBA?

#352

Corps have a dev environment sitting right in Excel that doesn't need special (management, management's management, adding to a registrar of projects, budgeting or project manager assigned, etc) approval for non-stock software. The stack's Excel, plus Sharepoint if you're really looking for a networked data store that also has a web interface. From that end-user direction, solutions emerge. And they're in VBA.

> that doesn't need special (management, management's management, adding to a registrar of projects, budgeting or project manager assigned, etc)

Not entirely correct

https://www.encomputers.com/2018/05/disable-macros-in-micros...

Re: Why do people still use VBA?

#353

Earlier quoted context omitted.

> Do you have a customer focus? Indeed I have a customer focus. My customers are the people and businesses who rely on the fact that the production servers run smoothly. And I serve their legitimate business needs, among other things, by not allowing some gung-ho hacked-together unvetted magic spreadsheet to kill runtime performance by performing a blocking query with deep joins that forces the DB server into running…

The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve? is there another way we can help you solve for it? Maybe a cheap replica would work for you?" And look, i have nothing to go off but the justifications and choice of words in your replies. But in my experience this attitude of "high priest protecting the gates of production from barbarians(company staff)" is strongly cor…

> The real answer is "ok, that is a bad idea for XYZ reasons, what problem are you trying to solve?

That's the answer that I give immediately after the "No."

Look, I get what you are saying. I am not trying to keep people away from the capabilities they need to improve how the whole show works. The problem is, what people in my business "guard" are often complex, critical systems, which themselves don't always meet the standards that their "guardians" would like to implement (just ask about legacy software :D). We have to say "No." and we have to enforce standards and procedures.

Because there are a lot of really clever people around in tech, and clever people love to tinker. And that's wonderful! That's the entire spirit that got me into this biz! Take a problem, and build a solution.

But things have to work. And they have to work tomorrow, and 2 years from now. And they have to be safe, they have to be compliant with a gazillion regulations, they have to pass audits. They have to be patched, they have to be maintained. And all that still needs to happen even after the guy who built them leaves the company. And they have to work for many many many people who are not tinkerers, who just want to click a button on their phones, and rightfully expect the whole shebang behind that button to "just work".

That's why there have to be people who say "No." from time to time.

If that happens indiscriminately, and without a care about why these clever people tinker up their solutions, then that's not good, I fully agree.

Re: Why do people still use VBA?

#354

Apparently it's so ubiquitous that you don't even need to say what it is, every just knows. I looked it up -- VBA=Visual Basic for Applications. https://en.wikipedia.org/wiki/Visual_Basic_for_Applications

I'd argue that developers beyond a certain age are as guaranteed to have come into contact with VBA as with HTML/JS.

Yep, I did a few VBA+Access apps in the mid-to-late 90s. VBA in Access 7/97 was kind of buggy, too, so there were some truly awful workarounds involved.

And speaking of HTML, there was also VBScript, which for me is inextricably linked to classic ASP.

Re: Why do people still use VBA?

#355

Earlier quoted context omitted.

> they are giving a service for the rest of the company That is very true. And part of that service is to ensure that things run smoothly, securely and according to industry standards. How well would an IT guy provide that service if he were to let some unvetted, undocumented script hacked together by someone who isn't a professional software engineer, run its merry way across the production database?

Don't give access to a DB, the same way you wouldn't give access to any other external system. Instead you ask what is needed and provide a restricted REST API. You come off as condescending and remind me of why I (ex dev who joined our business department) dislike our IT so much and do my best to encourage shadow IT where I can, while keeping sane best practices around CI/CD, security and testing. I'm so fed up seei…

> Instead you ask what is needed and provide a restricted REST API.

Happy to. Problem is, that API has to be built, and tested, and vetted, and maintained, and who's going to do all that work? Because I know a lot of software devs, and none of them lack for tasks.

Re: Why do people still use VBA?

#356

Earlier quoted context omitted.

Yes and yes. But the larger and more fundamental problems are the mixing of the program logic and the state and inability to make the code composable or modular. Problems in version control and deployment/reproducibility almost necessarily follow from these. These are probably not impossible to solve for notebook-style, but there are not many efforts to solve them or they are not even acknowledged as problems. Edit:…

Thanks. Agreed. By "stateless", I'm assuming you mean functional programming paradigms of immutable, idpotent, and no side effects. FWIW, for build pipelines, my quarter-baked notion is to use ZFS snapshots (or equiv). I'll check out Pluto for Julia. As you know, state is a challenge for "serverless" too. I've been reacquainting w/ RDBMS tools. There are a few new strategies (implementions) for change tracking. Back…

In the notebook context the main gripe is that notebooks have the "invisible" memory state that means that one can't deduce from the notebook code what it actually does. Or more concretely the order of execution of the cells affects what the notebook does. This leads to sort of higher level side-effects. With usual side effects you get spaghetti, with notebooks you get moving spaghetti in five dimensional space.

Immutability and idempotencency are good, and related, ideals too, although I think these can get too "unergonomic" if taken too dogmatically (like in Haskell or Redux), they should be used with almost goto-level discretion.

Of course there's the clear (short term) usability benefit of maintaining the memory state in that stuff doesn't have to be recomputed. But we can have that benefit and be stateless with pure functions and memoization. I quite often whip up a buggy and brittle ad-hoc solution to do so. There was also the IncPy project [1] that did this more rigorously, but it hasn't been updated in 13 years.

In general I'm a bit baffled why pure function memoization is so rarely used or proposed. Despite the old adage, cache invalidation is not actually half of the three hard problems in CS. With pure functions it's trivial.

Another baffle is why snapshotting/change tracking (and compressing) file systems haven't caught on. Instead these tend to get implemented badly in any sufficiently complicated application.

[1] https://github.com/pajju/IncPy

Re: Why do people still use VBA?

#357

Corps have a dev environment sitting right in Excel that doesn't need special (management, management's management, adding to a registrar of projects, budgeting or project manager assigned, etc) approval for non-stock software. The stack's Excel, plus Sharepoint if you're really looking for a networked data store that also has a web interface. From that end-user direction, solutions emerge. And they're in VBA.

A lot of systems have python or perl already installed. I feel like perl in particular is probably way more portable and performant than whatever hacks you have to come up with in excel.

Re: Why do people still use VBA?

#358

Earlier quoted context omitted.

If security is non-negotiable, the only solution is to destroy the data so that it can't be ever recovered by anybody. Or even better not having any data in the first place. Securing some data is very important. Some data indeed shouldn't exist in the first place. But for a lot of data it matters very little. Most security breaches have rather mild consequences. Treating all data as megatopsecret and all security bre…

Well, I work for a company that processes Private Health Information, so a breach is a potential existential threat.

Breach to private health information that can be linked to an individual more exactly? Is this kind of information all around the organization's computers?

Re: Why do people still use VBA?

#359
post #129

Earlier quoted context omitted.

I suspect that dystopian environments of locked-down mandatory corporate Windows laptops with no software installation privileges, firewalled networking and even the USB ports disabled are also part of the reason for every function being crammed into the browser to the point that the browser has become an operating system host... Creativity (and catastrophes) happens where there is freedom: local scripting and browse…

>no software install... https://portableapps.com I think there's even a Lazarus IDE available for every company user who wants to create reliable RAD based software bound to corporateware.

Best practice security recommendation for executables these days (in corp env) is to block all execution of all executables outside of protected folders, i.e. Program Files and Windows. Severely limits the initial attack surface (disable that rule or supply chain attack).

As a developer who hates installing programs that might be one offs, I hate the idea of it, but I can't deny the benefits.

Re: Why do people still use VBA?

#360

Earlier quoted context omitted.

And looking at how much work is involved in even just setting up a JavaScript frontend, I’m pretty sure the Excel programmers are yet another order of magnitude more productive than the latter. Which is kinda sad actually.

I agree. I worked as an analyst where due to security policies we only had VBA. There was application which consisted of an Access DB for a "front end" (containing an interface to input data, generate reports in ppt/excel, etc) which connected to another access database as the "back end" and an admin console to pull in data from a SQL database. I had a lot of fun maintaining it.

Yeah I know MS Access & Co. have kind of a bad rap, but if I look at what we were able to actually achieve for the business/users with those tools, it’s really painful to see how little progress we have made in the last 20 years or so.
Post reply on HN