[joshuamorton]

I think in your rush to appear superior, you missed the much simpler explanation. Your first comment was easy to misunderstand:

> print vs print() is what I think the parent comment was referring to.

as another person mentioned is likely what you meant, but it was easy to take your comment as meaning that you had mismatched parens somewhere, which would imply broken python2, as well as 3.

> * given a tool that promises to cease functioning 'correctly' at any future moment based on its own whim, preferences, industry fashions and styles, in an ecosystem where many similar such tools exist that explicitly promise not to cease functioning over the same time period, it is a fool's errand to pick the tool that promises to externalize additional costs on the user when alternatives exist that avoid any such cost.

This is clearly a falsehood, if the tool provides additional value. To bring things back to the topic at hand, if C++ were allowed to break ABI compatibility in very specific ways, it could be faster. stl container types are slower than many third party ones (absl, for example).

Which is to say that if you want "the best" that C++ has to offer, you have to be willing to have your libraries make backwards incompatible changes.

To jump back to python,

> given tool designers who externalize almost frivolously minor technical costs on to every user, where each 'minor' change is amplified perhaps 10000 times over and directly translates into expensive engineering time

I disagree that this happened. The examples you give are trivially fixable with 2to3. There are harder problems that 2to3 doesn't solve, but it sounds like you don't have any, so the frivolously minor technical costs are frivolously minor, and translates into running `2to3 my_code/` one time, to fix all the missing parens and most of the moved functinos.

> bash that continue functioning to the present day

I have yet to encounter a 20 year old program written in bash that functions to this day. It might be syntactically valid, but it won't do what it intended to do.

[slovenlyrobot]

I mistakenly thought you wanted clarity on my reasoning, instead it seems I've been made a fool of by providing an opportunity for you to argue a position I already understood and couldn't care less about. It's funny, this is also pretty much the reason I stopped relying on Python.

You're welcome to absorb all the externalized costs your heart desires, but in future please consider reviewing HN's rules before bandying attacks like "smug" and "superior".

[joshuamorton]

Understanding ones views doesn't imply agreeing with them. A tool is only useful if, well, it's useful. A slow C++ is less useful than a fast one. So how is it that you can claim so strongly that the value from backwards compatibility is greater than the value from speed by default?

Bluntly, if I could break the ABI to get a 10% speed boost across the board, is that not worth it?

And I'm well aware of the site guidelines. I certainly don't think asking someone to tone down the holier-than-thou in their comments is a violation of them. Just the opposite, it's encouraged. So I'll continue to ask that you do so if you choose to respond.