> A command line switch or environment variable can tell the language implementation "please behave like version N".
That's not a fix. If you tell people running existing code that they need to pass a new parameter to maintain the existing behavior, you've broken them. This is no better than just telling them to update their scripts to call "Invoke-WebRequest" instead of "curl". For the record, powershell already supports this. You can request a specific version of powershell. Most of the time people don't use this functionality, though.
> It's not a perfect solution but it placates most of the concern of the form "this is a good all-round fix, but it will break things for some unknown numbers of users".
It's actually not a good all-around fix. It might be the best fix for this situation, but breaking an unknown number of users' scripts of unknown importance is still a pretty bad fix. Some guy's payroll processing will break because of this. Some startup's web scraping logic will break. Lots of stuff will break if they fix this.
> Users who have to be absolutely sure that their code will work the same way regardless of language interpreter and run-time updates simply have to package their work together with a specific version of those components, and have their code refer to them instead of the standard installation.
So basically no expectation of backwards compatibility? That's why Chrome ships with its own copy of Windows, right?
> If you tell people running existing code that they need to pass a new parameter
So, make it an old parameter by having this from the beginning in your language.
Once the parameter is several years old, it's no longer a new parameter.
Users can use it proactively, before something breaks. It can be a recommended practice for deploying code.
> This is no better than just telling them to update their scripts to call "Invoke-WebRequest" instead of "curl".
It is substantially better than asking people to change source code.
Users can still change their scripts to call Invoke-WebRequests (and should!); just in the short term, they just adjust some version mechanism.
> That's why Chrome ships with its own copy of Windows, right?
Windows has versioning mechanisms in some of its API's, by which it can tell that a program is calling it that was compiled for an old version.
Speaking of browsers, web pages declare what version of HTML they are in with <!DOCTYPE ...>. If your page begins with <html>, you can't expect it to render the same way everywhere.
Deploying applications in containers with copies of operating systems is not unheard of these days.
> So basically no expectation of backwards compatibility?
Backward compatibility is the normal modus operandi. This type of mechanism is just for "oh shit" situations: there is no way we can fix this thing while remaining backward compatible. Any newly introduced use of the version emulation is treated with great regret.
> Users can use it proactively, before something breaks. It can be a recommended practice for deploying code.
I'm sure it is recommended practice. That's irrelevant if people aren't following that best practice. And they generally aren't, because it adds friction to development.
The "go back in time and do it right from the beginning" fix isn't feasible due to the lack of reliable time machines.
> It is substantially better than asking people to change source code.
It's really not. If the workaround avoided compilation, this would be lower cost. But the cost to make a small change to a script and the cost to change the way the script is invoked are pretty much the same.
> Windows has versioning mechanisms in some of its API's, by which it can tell that a program is calling it that was compiled for an old version.
No. Windows is just super-serious about backwards compatibility. Some APIs are versioned. Most are not. Microsoft just bends over backwards to keep stuff running (to the point of emulating bugs that programs relied on).
> Speaking of browsers, web pages declare what version of HTML they are in with <!DOCTYPE ...>. If your page begins with <html>, you can't expect it to render the same way everywhere.
Also no. HTML5 did away with the versioned doctype crap because it wasn't actually useful. It's just "<!DOCTYPE html>" now, because that's what you need to get browsers to render your site in a standards-compliant way.
> Backward compatibility is the normal modus operandi. This type of mechanism is just for "oh shit" situations: there is no way we can fix this thing while remaining backward compatible. Any newly introduced use of the version emulation is treated with great regret.
This type of mechanism 1) already exists for powershell, and 2) doesn't really help much here. I'm sure if they take this breaking change, they'll advise impacted people to use this workaround if they cannot for some reason fix their scripts. But this is not a "fix".
Disclosure: MSFT employee, but not on PowerShell or Windows
I never called this a "fix". I used "fix" in reference to whatever backward incompatible change was being made to make this workaround necessary. (For whatever reasons, it is considered a fix that is desirable; and so the question is then now to mitigate the impact.)
Of course the fix for any behavioral regression is to make it go away without the user having to do anything (other than apply the fix).
The versioning request mechanism has to be supported via an environment variable also, because if a user has a tree of scripts calling each other, it may not be feasible to insert this extra argument into all those calls.
> But the cost to make a small change to a script and the cost to change the way the script is invoked are pretty much the same.
That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places.
There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment.
Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue.
> HTML5 did away with the versioned doctype crap because it wasn't actually useful. It's just "<!DOCTYPE html>" now,
I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance.
You called it a solution. You called it a way to address the issue. Nitpicking use of the specific word "fix" is pointless, when you were clearly proposing this as a fix.
> That is true, but the cost to make hundreds of changes to a script versus one command line parameter isn't the same. A change which breaks backward compatibility could affect some programs in many places.
You're right. The cost to hack it with a specific version is higher. You either have to set a system-wide environment variable (which someone will forget about and ship a break because locally they were using a newer version) or you have to inject it at each point a relevant script could run. Or you could do a find/replace for the problematic alias and be done.
> There is also the cost of finding that there is a problem, and what that problem is: where is it breaking and what changes need to be made. All while ensuring that those changes work for the older versions of the interpreter too, not just in the upgraded environment.
It's literally a grep/findstr. I don't know why you're acting like it's hard to find uses of the tokens "curl" and "wget" in ps1 files.
> Say I have some big, 10000 line script. I update to a new interpreter, and the script doesn't work. First thing I will try is the compat option to emulate the previous version. If it works, then there is my workaround; for the time being, I don't have to care why, or whether forty places in the script are affected or only three. The thing has a way of continuing to work (for a good, long time) so I have plenty of time to investigate it. I can treat it as a low-priority issue and give it as a background task to a co-op student instead of as an urgent blocking issue.
What are you talking about? The whole reason to maintain backwards compatibility is so you don't end up in this situation. You can use the version switch if you need to, but in general if you need to in production it means someone screwed up.
In the scenario you described, there's a 95% change you'll never take the version switch off once it's in place (because it's "low priority"), so you'll have this hanging over your head until something breaks and it becomes critical to upgrade, at which point you'll be frantically trying to fix the problem and cursing Microsoft for not maintaining backwards compatibility.
> I.e. HTML5 just shortened the spelling of the utterance that you need to indicate that "this page is HTML5". If your page is HTML4, you need the older, more verbose utterance.
Not exactly. If you slap the "HTML5 doctype" on an HTML4 page, it's expected to work. Because again, that abbreviated doctype is all you actually need to get a browser to use standards-compliant mode. But also, this is the doctype going forward. So far as I understand, there is no plan for HTML6/7/whatever to change this. Because backwards compatibility is greatly preferred over trying to force a specific version.
If I have a problem with Firefox and switch to Chrome, that addresses my problem and is a solution; yet it isn't a fix! When I use words like "address", I'm specifically being weasely, avoiding the word "fix". :)
> The whole reason to maintain backwards compatibility is so you don't end up in this situation.
That's the ideal, which ignores the negative aspects of absolute backward compatibility. Very good backward compatibility most of the time is all round better than perfect, absolute backward compatibility.
If you want perfect backward compatibility and an excellent design everywhere, then you have to make only perfect design decisions in everything right from the start.
Dennis Ritchie regretted not fixing the precedence of the & operator in C. It's strangely low because at one time there had been no logical && operator and & was used in its place. He wanted to fix it, but, alas, the story goes, they already had several hundred kilobytes of C code written across three machine installations. The result: a piece of technical debt spread to immeasurable numbers of lines of C written since, world over.
> I don't know why you're acting like it's hard to find uses of the tokens "curl" and "wget" in ps1 files.
Simply because I'm thinking of the whole class of possible backward-incompatible changes in a language or library, not all of which can be necessarily found this way. For the ones which can be found by looking for specific identifiers, you need reliable release notes to tell you what they are.
That's not a fix. If you tell people running existing code that they need to pass a new parameter to maintain the existing behavior, you've broken them. This is no better than just telling them to update their scripts to call "Invoke-WebRequest" instead of "curl". For the record, powershell already supports this. You can request a specific version of powershell. Most of the time people don't use this functionality, though.
> It's not a perfect solution but it placates most of the concern of the form "this is a good all-round fix, but it will break things for some unknown numbers of users".
It's actually not a good all-around fix. It might be the best fix for this situation, but breaking an unknown number of users' scripts of unknown importance is still a pretty bad fix. Some guy's payroll processing will break because of this. Some startup's web scraping logic will break. Lots of stuff will break if they fix this.
> Users who have to be absolutely sure that their code will work the same way regardless of language interpreter and run-time updates simply have to package their work together with a specific version of those components, and have their code refer to them instead of the standard installation.
So basically no expectation of backwards compatibility? That's why Chrome ships with its own copy of Windows, right?