Re: The Guile junk drawer and a C plea

[Dr. Arne Babenhauserheide]

Damien Mattei <damien.mattei@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