Don't use any Microsoft technology. In the case of scripting there's no real reason for using something like VBA except that "We've always used it". There are several standardized scripting languages out there that run on multiple platforms so always use these and always stick to the standards. Avoid proprietary extensions but if you're really forced to use them isolate them in modules with well defined high level functions.

These are the rules I've lived by. Its difficult in a team environment to convince people of the dangers of pinning your work to one platform, especially one as ubiquitous as Windows, but if nothing else the lessons of recent W10/W11 transitions and changes to licensing models should have emphasized the need to avoid single source lock in at all costs.

Perhaps VBScript predates all those standardised languages. It certainly goes back to the 1990s and I'm fairly sure that "JScript" was a latecomer to the party.

I'm not disputing that anyone writing new code in VBScript in the last 15 (probably 20) years has made a bad decision, but maintaining old code is legitimate, and small improvements to old code are also legitimate, so when do you turn round and tell your paymaster that it is time to take a lot of still-working code and rewrite it in a new language just in case MS move the goalposts?

Aren't MS in the process of moving the goalposts now?

True - which means that it is *way* past time to have had The Talk with management. If you started right now, you *might* find all the places that VBScript has crept, unnoticed, into all the company workflows*, but will you replace every single one before the Final Update** that stops them all working?***

* and don't forget that "workflow" not only covers that document automation system you got 17 contractors in for, back in 1998, and still boast about, but also means the 114 "just a quickie" scripts that were done as favours to PAs, as trivial fixes for the Sales team, as just something HR needed "only for one week as we get used to things", ...

** and company policy is tight, all the machines get all the updates, except for those two that are kept off the network and run the no-longer updated UI for the machine tools (see, we *have* thought it through and allow for special-case exemptions, we won't be caught out)

*** bugger, it was 116 quickies and nobody got paid: all the bank transfers went through without a hitch, but because those dozen lines of code failed to copy the exchange rates over, the multiplier was left at zero...

You can't do anything about legacy code, you have just do your best and suck up any fall out. But this is an argument to avoid making the same mistake in the future, no matter how attractive the language offering seems to be. A typical example is that where I was working started recruiting a new test software team to take over all the ad-hoc firmware testing and New Broom style decided to write (rewrite) everything in Python. Fair enough. Except that they insisted on using a "Windows" version of Python. Not a version of Python that runs on Windows -- they all do that -- but one designed specifically for the platform that included some tweaks that would have made moving to a different platform difficult, if not impossible. That's what I regard as self-immolation -- its the sort of thing that gives you exactly zero benefits but ties you to that platform.

BTW -- Most people don't realize that Visual Basic wasn't originally a Microsoft product, it was developed independently and then sold to MSFT to add to their portfolio.

I'm not aware of a Windows specific Python, but there is Ironpython, which is a Dot Net version of Python - that is Python written in C# and part of the whole Dot Net system. It supposedly also ran on Mono, and so would apparently run on Linux. I don't know where that stands now that Mono is no more.

I think that Microsoft eventually gave up on Ironpython as pointless as it couldn't run the many, many, Python libraries that were written in C, which is what customers actually wanted to be able to do rather than use Dot Net libraries.

The project is still semi-alive on Github, but it is way, way, behind the current version of standard Python.

The main issue with trying to port an Ironpython program to standard Python would be if it used Dot Net libraries. You would need to replace those with something else.

I was amazed about a decade ago of finding a Chinese e-commerce website that still ran on Classic ASP (i.e. VBScript). It was archaic even then.

The last time I used Classic ASP must've been almost 3 decades ago.

This reminds me, is Internet Explorer finally fully removed from Windows? Or does some IE files remain in Windows 10 and or 11?

This is a really wrong move. Maintaining VBS should be part of maintaining legacy situations.

If people are using it rather than say powershell, there's probably a reason for it, like when people build a nice path and people cut across the grass and don't use the path.

From a cursory test I suspect the reason is that -

1. VBS runs without opening a large black console window (powershell seems to open an unsightly large black window with scrawl, very unhelpful for the end user experience)

2. VBS has a tiny footprint (powershell is huge just to popup hello world)

3. VBS runs instantly (powershell is sluggish)

VBScript long predates Powershell, so people were using it because that's what they had. The standard command interpreter was a very weak and limited language, so it was very hard (or impossible) to do the sorts of things with it that people with unix/Linux systems were using bash for. VBScript filled some of the gaps on Windows.

People used VBScript because that's what they had. I used it for something once a few decades ago, and it was just awful. It's not something I would have used if I had anything better.

That doesn't mean I'm a fan of Powershell either, I'm not. The standard scripting language situation on Windows has never been very good.