Hacker News Reader

It is much easier to do breaking changes in a compiled and statically typed language, as long as it doesn't use a preprocessor. Because you can do automatic upgrades. Some Python 3 changes were not fixable by 2to3 which meant all source needed to be checked manually line by line, vastly increasing the cost of upgrading. Worse, Python 2 wasn't forward compatible with Python 3 in many cases, which required libraries like six to get a transition period through the back door. The whole process was managed horrifically.

C++ has not maintained backwards compatibility by doing automatic upgrades. I don't think that would even count.

Backwards compatibility for a language means that old source code still works without having to update it, even if you can do so automatically.

Also worth pointing out that C++ has broken backwards compatibility in a very small number of cases, e.g. the `auto` keyword has changed meaning. Nobody ever used it before so it wasn't a problem in practice.

clang-tidy has support for doing code upgrades, but doing that in a ISO standard language with several implementations, including compiler specific language extensions, is an almost impossible task anyway.

I wasn't giving C++ as an example of a language that maintains backwards compatibility through breaking changes using source upgrades, I was actually thinking of Go when I said that. Obviously C++ does have a preprocessor, which means upgrades cannot be done automatically in general because e.g. how do you know which macros in an #ifdef are "supposed" to be defined and which are "supposed" to be undefined etc? Instead they have to maintain backwards compatibility in the spec.

C++ has introduced breaking changes, though: https://stackoverflow.com/questions/6399615/what-breaking-ch...

They've just been careful to try to minimize the impact.

JavaScript has made breaking changes though. Strict mode was introduced for ES5, and includes breaking changes, and now all engines in use implement it (it was in at least IE9). The difference between that and the python situation is that JavaScript allowed both versions to coexist in the same codebase.

Strict mode was opt in though, and code would still evaluate without it.

There's also a lot of new syntax though, which does have high costs in cases like generators, and shipping the regenerator runtime because you need your code to run everywhere.

To my knowledge they have extended syntax and added modes, but not actually made any breaking changes.

A mode was a way to avoid making breaking changes.

What I missed from my comment is not just about the engines in use, but also that all old spec confirming JavaScript should still run, in all new environments.

That is backwards compatibility.

I suppose if you happened to previously have code with the string 'use strict'; at the top, and did non-strict things below, it would break. In a very small scale, that does break backwards compatibility.

I'd love to find out if there was anyone affected in reality. It seems improbable, as random string statements with no assignment is a pretty niche way to comment code, or surely it would have been mistake.

But there's so much poorly written JS on the web that there is a chance!

> parseInt("012")

Modern browsers will say 12, old browsers (IE 8 and down) will say 10.

Great example, I guess I forgot that a few changes were made that otherwise did surprising things.

They also changed to (at least more) deterministic ordering of object keys and I wonder how much code worked

Great example, I guess I forgot that a few changes were made that otherwise did surprising things.

They also changed to a (more) deterministic ordering of object keys and I wonder how much software behaved differently / broke as a consequence...

My "favourite" JS quirk is some of the IE versions where it would break if you called console.log without the console open, as it was undefined.

So many quirks, I think I may have slightly overstated the compatibility element.

> Watching the ~11 years of Python 2 to 3 adoption has been somewhat painful

this portrayal of the python 2 to 3 migration does not represent the majority of the community! and yet we keep hearing it over and over because "large" codebases were not migrated on time.

this migration was a software engineering problem. i hope by now, people have learned to write dumb code and avoid clever tricks whenever they can. performance and clever tricks get tied to languages, OSes, & hardware versions. python is no exception!

not saying don't do them. just saying know what you are getting into.

again, the issue is not entirely due to breaking changes. but python made it too easy. c++ for example would have given people such a hard time that they wouldn't have even bothered. python's was too permissive.

i have seen the python 2.7 codebase that shipped with the original appengine. it always felt like traveling to a different world whenever the debugger gets into their code...

Problems of Python 2 to 3 migration were mostly not about clever tricks. They were largely about making Unicode strings and byte strings incompatible (as they should have been from get go). Much of Python 2 code mixed them up, and that was a source of actual bugs. Hence the need to fix manually.

It's hard to overstate how big of a breaking change that was. Python is basically scriptable C. In c, strings aren't really a thing, but they are first class in Python (since everything is effectively a dict). And char's are your typical string-like data structure. So in py2, it made (some) sense at the time to let str and byte[] types intermingle. I don't agree with that choice, but it wasn't unreasonable (much like the null pointer).
This led to all manner of playing fast and loose with str as byte[] usage. I've seen inline asm and even machine code in python.

Now it's the new millenium and oh look, ascii-char won't cut it as your language implementation of strings.