4 ms·

> 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 runn

by dpark 10y ago

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

kazinator 10y ago
> 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.
- dpark 10y ago
  > So, make it an old parameter by having this from the beginning in your language. It's already part of PowerShell. You can request a specific version when you run PowerShell. https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help#version-windows-powershell-version https://msdn.microsoft.com/en-us/powershell/scripting/core-p... > 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
  - kazinator 10y ago
    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.

by dpark 10y ago

kazinator 10y ago

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

dpark 10y ago
> So, make it an old parameter by having this from the beginning in your language. It's already part of PowerShell. You can request a specific version when you run PowerShell. https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help#version-windows-powershell-version https://msdn.microsoft.com/en-us/powershell/scripting/core-p... > 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
- kazinator 10y ago
  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.