VBScript deprecation: Timelines and next steps • Hacker News Board

Re: VBScript deprecation: Timelines and next steps

#41

Post by jsd1982 » Sun, May 26, 2024, 3:59 PM UTC

Just ran into a Y2038 bug in some classic ASP+VBScript code in production the other day. Someone long ago wrote `Date() + 5000` to set an expiry date far in the future (5000 days). As it turns out, 5000 days from now puts us past 1970-01-01 + 2**31 seconds (2038-01-19ish) and that causes VBScript to raise an error and abort the ASP page request with a 500 error.

I raised the issue that we have about 14 years left of ASP+VBScript literally being able to execute properly and calculate dates (sans any large date additions remaining). Guess it'll be sooner than that based on this post but 14 years is definitely the upper bound if your VBScript code even touches dates.

Re: VBScript deprecation: Timelines and next steps

#42

Post by 7bit » Sun, May 26, 2024, 4:08 PM UTC

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…

> 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 you like including kernel calls, etc. without ever needing something like a 3rd party package like you would with e.g., Python.

Re: VBScript deprecation: Timelines and next steps

#43

Post by 7bit » Sun, May 26, 2024, 4:08 PM UTC

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.

If you love awk and sed, no. If you rather work with objects, yes, absolutely.

Re: VBScript deprecation: Timelines and next steps

#44

Post by chem83 » Sun, May 26, 2024, 4:10 PM UTC

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.

Yes, there is.

If you write bash to execute on WSL2, you’re just orchestrating the Linux VM (that runs on Hyper-V and is cleverly integrated into Windows and makes you feel like you have a native bash shell). If you want to automate Windows using bash, you need some runtime that translate all Linux-like calls to the Windows COM interface.

Re: VBScript deprecation: Timelines and next steps

#45

Post by watersb » Sun, May 26, 2024, 4:10 PM UTC

ksherlock wrote: post #11

yen223 wrote: post #5

Earlier quoted context omitted.

Folks who complain about Javascript don't realise how close we were to having vbscript as the dominant web language

In a slightly different universe, CERN gave Tim Berners-Lee a windows workstation instead of a NeXT Cube and www was built on top of Microsoft Word and VBScript.

> www was built on top of Microsoft Word and VBScript

Ah, that would be Internet Explorer.

Re: VBScript deprecation: Timelines and next steps

#46

Post by ygra » Sun, May 26, 2024, 4:13 PM UTC

13of40 wrote: post #38

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 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, that people don't care about idiomatic.

Re: VBScript deprecation: Timelines and next steps

#47

Post by ygra » Sun, May 26, 2024, 4:17 PM UTC

ravenstine wrote: post #31

bossyTeacher wrote: post #8

Earlier quoted context omitted.

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.

Jeffrey Snover once answered this on Stack Overflow. The answer is that bash and all the other Unix tools wouldn't help you very much on an operating system where things are accessible via an API and not via text files and command-line programs. That's why PowerShell also has "drives" for things like the registry and the certificate store. Even functions, aliases, environment variables and PowerShell variables get their own drive, funnily enough.

Re: VBScript deprecation: Timelines and next steps

#48

Post by bossyTeacher » Sun, May 26, 2024, 4:18 PM UTC

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..?

In most normal languages, a non-void function returns either null or some data. Normally, the type of data is always the same. So your function returning a string will never return an int. Either it returns a string or an int. In PowerShell this is not guaranteed for all the functions in packages supported by Microsoft. A function returning a list of strings, can sometimes return a list of something that are not strings. This is the first big issue I have with PowerShell.

The language is very quirky. Simple stuff like using variables is not as intuitive as it should be.

Another issue is encapsulation of logic, it is not straightforward at all. This is my second big issue.

Trying to temporarily disable script policies to run a script is not straightforward either.

Re: VBScript deprecation: Timelines and next steps

#49

Post by ygra » Sun, May 26, 2024, 4:21 PM UTC

jsd1982 wrote: post #41

Just ran into a Y2038 bug in some classic ASP+VBScript code in production the other day. Someone long ago wrote `Date() + 5000` to set an expiry date far in the future (5000 days). As it turns out, 5000 days from now puts us past 1970-01-01 + 2**31 seconds (2038-01-19ish) and that causes VBScript to raise an error and abort the ASP page request with a 500 error. I raised the issue that we have about 14 years left of…

Interesting that VBScript uses Unix time for timestamps. I would have expected something like FILETIME (NT's 1601 epoch) or OLE DateTime, which uses floating point with the integral part referring to days since 1899 and the fractional part is divided into the 24 hours of the day). Windows in general seems to have so many different date/time formats that using Unix time is quite surprising.

Re: VBScript deprecation: Timelines and next steps

#50

Post by 7bit » Sun, May 26, 2024, 4:36 PM UTC

13of40 wrote: post #38

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 nothin…

No hints?? They are by definition aliases. That ist hint enough. If in doubt, dont use the aliases.