Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VBScript deprecation: Timelines and next steps

techcommunity.microsoft.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: VBScript deprecation: Timelines and next steps

#31

Post by ravenstine »

bossyTeacher wrote: post #8
chem83 wrote: 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…

PowerShell is terrible. The idea is good, the implementation bad

I always wondered why Microsoft didn't just clone something like Bash as close as possible. Powershell was different enough from UNIX that I couldn't get myself interested in it during my phase when I was using both Windows and Linux.

Re: VBScript deprecation: Timelines and next steps

#32

Post by orthoxerox »

ravenstine wrote: post #30
chem83 wrote: 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…

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had some brief experience with WSL2.

Bash has no access to Windows internals. Some parts of Hyper-V you can configure only through pwsh, there's simply no GUI there to do it.

Re: VBScript deprecation: Timelines and next steps

#33

Post by workingdog »

unnah wrote: post #22

So far I have avoided Powershell in anything distributed to end users, because execution of unsigned scripts is disabled by default in Windows. It has been easier to use VBScript or BAT files to automate basic tasks, since those scripts can be run unsigned... I suppose it is too much to hope for that Microsoft would now reconsider enabling Powershell script execution by default.

Whatever you have that's calling the Powershell script just has to tell the Powershell system that it's ok to run the unsigned script. The default is just to keep people from double-clicking rando Powershell script files and all hell breaking loose.

Re: VBScript deprecation: Timelines and next steps

#34

Post by croes »

endorphine wrote: post #28
croes wrote: post #26

I know lots of software products which use VBScript to realize application scripting

Can you share some?

Seems to be favorite choice for software from german speaking countries.

The first two that came in my mind are

Enaio, a DMS and Serviceware Processes, a Helpdesk solution.

Re: VBScript deprecation: Timelines and next steps

#35

Post by BMc2020 »

kijin wrote: post #27
lasermatts wrote: post #9

Earlier quoted context omitted.

A deep chill ran down my spine as I remember all of those VBA tools I updated/generated during my first internship... some of those are still being used in some semi-industrial applications.....

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.

Re: VBScript deprecation: Timelines and next steps

#36

Post by orthoxerox »

Someone1234 wrote: post #17
bossyTeacher wrote: post #8

Earlier quoted context omitted.

PowerShell is terrible. The idea is good, the implementation bad

Care to go into any detail at all..?

It has a very idiosyncratic syntax. The internals are great, but it's so unlike either sh or C that I, for example, just can't be bothered to remember it.

Re: VBScript deprecation: Timelines and next steps

#37

Post by lowleveldesign »

unnah wrote: post #22

So far I have avoided Powershell in anything distributed to end users, because execution of unsigned scripts is disabled by default in Windows. It has been easier to use VBScript or BAT files to automate basic tasks, since those scripts can be run unsigned... I suppose it is too much to hope for that Microsoft would now reconsider enabling Powershell script execution by default.

I haven't considered the execution policy such a blocker since you may change it on the powershell.exe command line (for example, run "powershell.exe -ExecutionPolicy RemoteSigned -File script.ps1" from a bat file). Also, the default execution policies changed between PowerShell 5.x, shipped with Windows, and modern PowerShell 7.x, which you need to install separately. In 7.x RemoteSigned is the default in the server environment.

Re: VBScript deprecation: Timelines and next steps

#38

Post by 13of40 »

chem83 wrote: 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…

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 nothing to hint which is correct to use in a proper script, so when you see example code it looks like "get-childitem | foreach-object {...}" instead of "dir | %{...}"

Re: VBScript deprecation: Timelines and next steps

#40

Post by sterlind »

ravenstine wrote: post #30
chem83 wrote: 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…

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had some brief experience with WSL2.

PowerShell lets you script Windows itself. You can configure network interfaces, set group policy settings, change registry keys, install programs, gather diagnostics, etc. etc. Linux has systemctl, Windows has Start-Service. Linux has kill, Windows has Stop-Process. Linux has ip, Windows has Set-NetworkInterface. WSL2 is just a VM - one with a ton of slick host integrations, but a VM nonetheless. Its power to do anything to Windows itself is very limited. It's also not installed by default.

Disclaimer: work for MS, not on PowerShell or WSL.

Post reply on HN