Live data from Hacker News

VBScript deprecation: Timelines and next steps

techcommunity.microsoft.com

51–60 of 75 posts

Re: VBScript deprecation: Timelines and next steps

#51
I wonder if I’m the one who will get stuck porting the large number of 20+ year-old asp pages we have at my day job to something else?

(Which have been working fine all this time, BTW.)

These pages are actually jscript (a variant of javascript), but we probably need to understand this to mean that’s going away as well.

Re: VBScript deprecation: Timelines and next steps

#52
post #24

Earlier quoted context omitted.

Python in Excel could have been amazing, except Microsoft executes it in a cloud environment and require a Cloud Service account to even open spreadsheets with it in. I'd strongly recommend people avoid Python in Excel, it is a Trojan Horse into forcing you to subscribe to access your own spreadsheets.

It’s ironic that Microsoft was founded to provide software for microcomputers where the whole idea was that you own the CPU and don’t need to pay anyone or ask permission for access. And now they’re full circle back to mandating the timeshare computing model even though the local CPU has incredible performance. Maybe they should rename to Centralsoft.

That idea was long gone by the time they were selling Xenix, or years later bought Citrix's work to create RDP foundations.

Re: VBScript deprecation: Timelines and next steps

#53
post #42
post #7

I find PowerShell, the language, verbose and not very ergonomic. This ship has sailed, but I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms. It seems that VBA will continue to exist as the programming front end for MS Office, which is unfortunate. They had announced Python support for Excel…

> I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms. PowerShell is cross-platform and works und Ljnux and MacOS as well. And it's extremely good on itself already, because everything are objects, instead of just strings (bash, etc.). And because it's .NET you can seamlessly write anything yo…

Isn’t PowerShell itself the third party package? At least on Linux and MacOS, I mean.

Re: VBScript deprecation: Timelines and next steps

#54

Probably one of the most maddening things I have ever worked with, and that is saying something. Though a huge part of the blame for that goes to COM and registration, interop stuff, which is more Windows than VBScript and also probably never truly going away.

FYI, it looks like you're hellbanned - I vouched this comment back from [dead]. Might be worth sending an email to the mods. Edit: It's been since at least 2018?

[dead]

Re: VBScript deprecation: Timelines and next steps

#55
post #46
post #38

Earlier quoted context omitted.

IMO, the problem isn't that you can't use it in a terse way, it's that even though it gives you lots of options for terseness (type, cat, and gc are all aliases for get-content, for example) people naturally try to code in the canonical way and they assume that's the long-form cmdlet names. In Unix, "ls" is what you get so it has to be canonical. In PowerShell you can use ls or dir or get-childitem but there's nothin…

Scripts should not use the aliases because they can differ across machines or users. The cmdlet names are stable. That being said, for quick one-off scripts my code looks very much like my command-line usage, which is somewhere between terse and golfed. Idiomatic PowerShell embraces the pipeline, though. The number of scripts I've seen in the wood which were haphazardly ported from VBScript or C# showed, however, tha…

Built-in aliases are guarateed to be present, so you can depend on them. There are other features, like shortened parameter names that might become ambiguous when new parameters are added, that aren't guaranteed backwards compatible, but aliases are stable.

Re: VBScript deprecation: Timelines and next steps

#56

Earlier quoted context omitted.

It may have a separate timeline but it does seem to hint at going out the door in similar order on Office as well. I think the Python in Excel stuff is still in beta but things like lambdas, regex or Office Scripts all actually work (even on the web versions) and start taking big bites out of why you'd want to look at VB. New Outlook dropped VB support even on the desktop and I don't think they plan on maintaining se…

New Outlook is just an embedded web app. I tried it for weeks, old one is still better, and least rooms calendar is updated properly.

That's precisely what I mean, rather than maintain desktop and web apps for the Office suite Microsoft is continually moving towards a single stack of web based apps (chat and email being the first two so far). The web based tools dont have VB as a lot of the VB integrations wouldn't be possible on the web anyways.

Re: VBScript deprecation: Timelines and next steps

#57
post #42

Earlier quoted context omitted.

> I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms. PowerShell is cross-platform and works und Ljnux and MacOS as well. And it's extremely good on itself already, because everything are objects, instead of just strings (bash, etc.). And because it's .NET you can seamlessly write anything yo…

Isn’t PowerShell itself the third party package? At least on Linux and MacOS, I mean.

Yeah, it is. S/he’s missing the point. Good luck finding PowerShell pre-installed on any server or workstation. Is there even a non-MS sponsored distribution that includes it by default?

Re: VBScript deprecation: Timelines and next steps

#58
post #35
post #27

Earlier quoted context omitted.

No worries, they probably haven't updated Excel since you left.

IIRC, MS has not updated VBA since 2007, but they can't get rid of it because of the millions or billions of spreadsheets out there that still require it. They are trying to push excelscript aka typescript aka office scripts but uptake has been very slow.

Yep. Turn off VBA and the world burns.

That's only a slight exaggeration, if it is an exaggeration at all (there are all kinds of splody things that are managed by VBA scripts that some intern wrote back in 1999, or that can only be modified by Bob, who retired back in 2006).

Re: VBScript deprecation: Timelines and next steps

#59
post #42

Earlier quoted context omitted.

> I wish Microsoft had done something to make Windows automation a little closer to other platforms, so that it could benefit from the good software that exists on other platforms. PowerShell is cross-platform and works und Ljnux and MacOS as well. And it's extremely good on itself already, because everything are objects, instead of just strings (bash, etc.). And because it's .NET you can seamlessly write anything yo…

Isn’t PowerShell itself the third party package? At least on Linux and MacOS, I mean.

It is, yes. And how exactly could Microsoft have done Something that ships with Linux?

Re: VBScript deprecation: Timelines and next steps

#60
post #57

Earlier quoted context omitted.

Isn’t PowerShell itself the third party package? At least on Linux and MacOS, I mean.

Yeah, it is. S/he’s missing the point. Good luck finding PowerShell pre-installed on any server or workstation. Is there even a non-MS sponsored distribution that includes it by default?

You're missing the point. Anything Microsoft would have done would have been a 3rd party package to Linux.
Post reply on HN