Hacker News Reader

This just adds burden to programming language and library authors. Sure I could almost certainly support Python 2.7 and Python < 3.6 in all my libraries, but it introduces more code and shims I've got to maintain. Given I'm not being paid for this work and do it for fun, there's no compelling reason to support the small subset of users that cannot or will not update.

I imagine variations of the above apply to nokogiri and some amount of Ruby core developers.

I basically stopped writing Python because of the 2 -> 3 transition: the cost of waiting for dependencies to be ready for Python 3 was high enough that it made sense just to switch languages for everything.

Python was saved, basically, by it becoming _the_ language for data science in the same time frame. But, this could have very well turned into a Perl 6-style fiasco.

Mike has worked hard over the years to have Nokogiri come with its dependencies. It does come with libxml and all that is required.

From https://nokogiri.org

> These dependencies are met by default by Nokogiri's packaged versions of the libxml2 and libxslt source code, but a configuration option --use-system-libraries is provided to allow specification of alternative library locations.

Some authors work hard to have their tools do the right thing and consistently.

> Why can't I just run Ruby 3.0 with a flag that tells it to emulate Ruby 2.6? Or 1.8 for that matter?

I suspect it would be a nightmare - it's not just small parts of the code, it would be other parts of the code that depend on it.

Take for instance Python 2 & Python 3's approach to if ("hello" > "goodbye") - in Python 2 that would be False and in Python 3 that would be TypeError. So if you are running Python 3 with a Python 2.7 flag, how should Python's internal modules that are written in Python 3 handle this? Do all Python's internal modules need to work on every legacy version of Python and load the correct version, or does the interpreter need to somehow load up instructions for both and parse them together? Then there is the whole problem about libraries - are these allowed to selectively choose which version of python they run on?

This is of course only one small example of the complexity - If it was easy to make these things backwards compatible it would be great, but I would expect the cost for implementing full backwards compatibility to be high and the language authors are probably motivated to make people move towards the latest versions.

> Take for instance Python 2 & Python 3's approach to if ("hello" > "goodbye") - in Python 2 that would be False and in Python 3 that would be TypeError. So if you are running Python 3 with a Python 2.7 flag, how should Python's internal modules that are written in Python 3 handle this?

If the software has been changed so much you cannot be backwards compatible anymore, name it something else and avoid the conflict and confusion.

Even if you can somehow convince the major tooling to take that route, you're never going to convince every piece of software to follow suite. It's a problem that must be tackled, there's no side stepping it.

> You can include a native binary in the gem which does the hard computations. Will that work on random new architectures like M1? No? But you can fall back to a Ruby implementation and show a warning message.

Promptly ignored by most people, all while doubling maintenance efforts.

It's a trade-off without an easy answer.

The obvious answer is that every customer runs a different Ruby and not every customer pays to upgrade it at the same time. I currently have customers and personal projects with any Ruby from 2.4 from 3.0. I'm not upgrading that Ruby 2.4 project for free so it's going to stay like that for a long time.

Yeah, a ruby -2.4 switch would be nice but then every gem should pick its dependencies from back at the 2.4 time. Some could be dead by now. Actually those old projects usually get updated when the OS reaches end of life and they can't install the software on the new OS.

So economical and people reasons, not technical ones.

> But why isn't it backward-compatible?

It is, mostly. 1.8->1.9 was famously a big change, but breaking changes since have been comparatively minor.

IMX the most common cause for gem breakage is simply rot - old gem, maintainer lost interest, a tiny change required (often due to an open-ended dependency on another gem) but there's no one to do it. Unfortunately, adopting an abandoned gem is non-trivial if the original maintainer doesn't respond, and a lot of gems were written in the Rails goldrush but have fallen into abeyance since.

> Why can't I just run Ruby 3.0 with a flag that tells it to emulate Ruby 2.6? Or 1.8 for that matter?

My understanding is that Perl 5 supports this, for any version of Perl released in the 1994-2021 range, but in large part because it hasn't had drastic changes in that time period.