> But the problem is that the more changes you make to the language, the farther you pull away from your users and their programs. If they can't stay with you, you both die.

Should people just not make new languages any more?

Should new languages not bear deep resemblances to existing ones?

> Hand-migrating is nightmarishly costly. Look at Python 3.

> It's much more tractable if you can do most of that migration automatically using tools.

There was and is in fact abundant tool support for this in Python. The `2to3` script shipped with Python and the corresponding `lib2to3` was part of the standard library through 3.11. The third-party `six` compatibility libraries are still downloaded from PyPI more often than NumPy.

> In order to do that, the tools need to be able to reason in detail about the semantics of a program just using static analysis.

The experience of these tools users disagrees, from what I've seen. They produce ugly code in places, but it generally passes the tests. Yes, manual fixes are often necessary, but there were source packages published in that era (and it's not like they disappeared from PyPI either) that would detect the Python version in `setup.py`, run the tool if necessary at installation time, and have happy users.

> Should people just not make new languages any more?

They should, but they should understand it's very hard to get widespread adoption when they do. Not impossible, but very hard.

> There was and is in fact abundant tool support for this in Python. The `2to3` script shipped with Python and the corresponding `lib2to3` was part of the standard library through 3.11. The third-party `six` compatibility libraries are still downloaded from PyPI more often than NumPy.

Yes, and even so everyone involved knows the transition took a very long time, required a ton of labor, and was a major headache for many years.

Work on Python 3 began in 2006, and Python 2 wasn't officially sunsetted until 2020 [1]. To put that in perspective, the Python community spend almost as much time migrating to Python 3 as they spent in Python's entire history prior to that point. (Python was 15 in 2006, and it took them 14 years to deprecate Python 2.)

You'll notice too that the easiest changes to automate were the ones that were either lexical (renaming core library methods) or syntactic (print to print()), and the hardest ones involved the change to types of values (strings).

Static types make it much easier to automatically migrate code.

[1]: https://www.python.org/doc/sunset-python-2/