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