At this point it's not even explicit - it's an implicit decision of most companies, and even OSS projects, because it became part of the "common wisdom" of computing, part of the zeitgeist.

This is where the idea of "a computer as a bicycle for the mind" died.

On the topic of "computers as public transport for the mind"...

A project I work on has some processes that I need to run that can only be initiated through the Azure DevOps Pipeline interface, and these need a "worker agent" on a VM or something, and there is only one worker agent, and some of the jobs take half an hour or more.

So the effective outcome is that despite every member of the team having a full multi-tasking computer on our desk (A multi-tasking computer each! Sometimes more than one each! Plus loads of cloud VMs), we can only run a single task at a time between us and we have to coordinate scheduling manually.

Is this the future?

It is like this because the process involves "secrets" that are meant to be hidden from the team but are accessible to the program when running inside the Pipeline. If it weren't for this secret-hiding, I could just run the process manually on whatever computer I want.

And the secret-hiding doesn't even really work, because I can freely commit code to personal branches on the repository that the Pipeline runs from, and I can run the Pipeline on whatever branch I want, so I could commit a program that prints out the secrets. Ah, but Microsoft has thought of this: if any of the secrets appears in the output, they get replaced with "***".

(Let's skip the part where this accidentally leaks a "secret" username, where I know a particular piece of text that should be output but instead all I see is stars...)

The secret-hiding doesn't work because I can just make the program output base64 of the secret. I don't do this because I don't want to start pasting secrets around in places they shouldn't be available, but it is sometimes tempting.

Anyway, welcome to the future of computing. Thanks for listening to my TED talk.

> And the secret-hiding doesn't even really work, because I can freely commit code to personal branches on the repository that the Pipeline runs from, and I can run the Pipeline on whatever branch I want, so I could commit a program that prints out the secrets. Ah, but Microsoft has thought of this: if any of the secrets appears in the output, they get replaced with "**".

Github Actions at least allows restricting secrets to be exposed only to specific branches, and in Gitlab you can enforce that pipeline steps using critical secrets can only run in protected branches, so you'd need to fool a maintainer with a malware-laden pipeline change in a merge request first.

A physical world analogue wouldn't be far from a renovation company declaring "flathead screwdrivers are against technology strategic vision of the company" and their use is therefore strictly banned. Construction workers would of course use letter openers and butter knives to turn the flathead screws they inevitably encounter in their work, and that would be just fine.

It’s weird to me though that VBA apparently doesn’t count as “high level”.

And rightly so.

Imagine for a moment that someone in accounting built a system in lisp to automate part of his job. As time goes on, he takes on more responsibility, which he writes more lisp for.

One day, he gets hit by a bus.

The lisp program he wrote is now an integral part of the running of the accounting department simply by accumulation and momentum, with tons of business logic baked in. Where do you look to find a replacement?

With VBA, there's a much higher chance of an accountant being familiar with the language, and a much smaller surface area for what they can do.

this already happens with Excel and access. Entire companies rely on a spreadsheet some wizard invented years ago and now no one knows how to change it, and it goes weird if multiple users try to access it at once so make sure you copy it locally first and change the file name so you can track the versions

Yes, it does. The difference is that with a known language (VBA in accounting, for example), you stand a hope in hell of untangling the mess or at least managing it so that the company doesn't fall over.

This is already happening with IT maintained systems though... As specified in the article. So it really isn't an argument imo.

IMO, companies should have a language of choice which is actively encouraged to be used by everyone for all automation needs. Different departments build libraries to automate aspects of their jobs and other departments can use them if needed. I.E. it becomes yet another tool, just like Excel.

At this point you should just leave this dumpster fire of an organization and find a more reasonable place to work. I can't relate to the people who keep inventing atrocious workarounds ignoring the problem that they work in a hostile work environment.

I work in security and can't relate to banning Python & replacing it with Microsoft crap either.