Damien Mattei <damien.mat...@gmail.com> writes: > About breaking backward compatibility , i understand it could be a > disaster... but if Python made this choice
The experience of Python should not be encouragement. It was a disaster. Many tools are *still* broken, especially specialist tools. More than one and a half decades after Python 3 got introduced. The developers continued to maintain Python 2 for 12 years — until 2020. Python 3 still got takeup, because the AI craze hit and it was in a good position to provide readable (yet brittle) APIs. But I personally lost many weekends fixing existing tools. And I am sure that I’m not the only one. I am also certain that Python 3 caused lots of damage to Mercurial. Do you remember when Mercurial showed that Python can compete in performance with C while only using a minimal set of performance critical tooling in C? Mercurial competed on roughly equal terms with Git. One distinguishing factor were thirdparty extensions which added specialized capabilities. Many of these got broken with Python 3. I personally gave up maintenance of two extensions because I wrote them when I had free time for them, but as most other people, when they were broken a when Mercurial finished the Python 3 transition, I didn’t have that time anymore. These extensions were useful, but many where not maintained. Before Python 3 they did not *need* maintenance: they solved a problem and just kept working. After Python 3 that was no longer the case. Mercurial has become a niche tool now. I do not want that fate for our tools. > better things. It is my critic of Scheme: have too little change in 40 > years, even if in Scheme+ i try to be 100% compatible with Scheme. Let’s look at what the one responsible for Python 3 said about changing code: >> No one wants their code to break, but they always want everyone elses >> code to break by adding the keyword they want. — Guide van Rossum, 2018 https://youtu.be/Oiw23yfqQy8?t=163 He has a slide of what went wrong: https://youtu.be/Oiw23yfqQy8?t=769 - underrated Python’s popularity: people using every trick in the book of what worked. - Underestimated the importance of 3rd party packages: dependencies on lots of tiny little modules that solve one little problem. - clumsy migration: only *mostly working* auto-translation. - no runtime compatibility: a single non-converted dependency blocked compatibility. - supporting different versions in the same code is hard. Despite those lessons learned, many tools are *still* broken, especially specialist tools. Most of these are dying. More than one and a half decades after Python 3 got introduced. The developers continued to maintain Python 2 for 12 years — until 2020. And even worse: some Python 3 point releases broke existing code again. The big breakage had caused a cultural change. Breaking compatibility just a bit was deemed OK now. Python 3 still got takeup. I think it was, because the AI craze hit and Python was in a good position to provide readable (yet brittle) APIs to C++ code. But I personally lost many weekends fixing existing tools. And while I can still use Python, I moved on. Which is part of the reason why I’m here now. And I am sure that I’m not the only one. If you have to invest lots of time anyway, you can just rewrite in another language instead, which is much more enjoyable than spending days over days searching for the source of some remaining bytes-to-unicode breakages. > By the way i do not understand why a 100% written scheme program would > no more work with a different (internal) scheme implementation but i > do not know Lilypond design. Lilypond did a lot of optimization to be fast. It couldn’t afford small slowdowns, because it is used by people to create large production-quality scorebooks. So they did what worked to fulfill their requirements. Lilypond is C embedding Guile as scripting language. As the Guile reference manual recommended using Guile back then. They had to use some unclean options to reach the requirements of their users. And similar will be true for many other tools which manage to be best in their domain. I hope that Guile will have many of them, and I want it to be a safe choice to implement these. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
