Perl was the #3 language on the Tiobe ranking in 2005. It had massive codebases in banks and other industries. In 2019 it was ranked #19 and the incompatible replacement, Perl6, is #93. Breaking backwards compatibility is hugely costly. It creates immense work as people have to validate that new versions of previously working code meet the implicit, accumulated requirements.

Old code will always seem old fashioned. It will not address modern concerns. However, the option to keep using it is very valuable!

Two things - TIOBE is meaningless. And secondly, Perl is a valid example, but so is Python. After a 10 year painful transition, Python is more popular than ever. It's used more than any other language bar Javascript.

> Two things - TIOBE is meaningless.

Pick any other language survey of your choice and I guarantee you it will generally agree with the TIOBE.

Agree with what? TIOBE is just a vague measure of online chatter. I mean, right now TIOBE's site has a section on how Go, Swift, and SQL are tied. What is there to agree with? I mean, you can add "burrito" to TIOBE and the result would be just as meaningful.

That's maybe a good name for a successful programming language :) TIOBE driven design is the future!

That may be true about Python, but despite of the horrible transition from 2 to 3. That transition is a source of frustration to anyone who had to maintain code across the versions 2 and 3.

Not really, plenty of MBA type managers use it as a measure to allow for language adoption on their projects.

The language formerly known as Perl 6 is now called Raku so there are no more backwards compatibility issues.

Perl 7 is the new opportunity for backwards incompatibility (and probably doesn't even have an entry on Tiobe which would make your argument even stronger!)

Also, Tiobe is about as interesting as a gossip column. There are many reasons to pick one language over another, but ranking on Tiobe will never be one of them.

At my current workplace it took at-least 6 months of 2 engineer efforts. That’s about 200k of sunk cost + the opportunity cost of them working elsewhere. Plus other people who got pulled in, it’s easily about 300k to migrate from oy2 -> py3.

We still have a mumbo jumbo mess of py2 scripts lying around.

> In some languages (e.g: Lua, Python) the designers are ready to break backwards compatibility. C++ chose not too.

There are still quite a few Python 2 codebases that will never migrate to Python 3, and quite a few developers who still use Python 2 for new projects.

Anecdotally, several Python developers I know would rather rewrite their Python 2 programs in another language than put in the work to move to Python 3. A lot of them seem to be considering Go and Rust.

The way the Python 2 to 3 change was handled was a huge mistake.

>quite a few developers who still use Python 2 for new projects.

[citation needed], I haven't seen anyone use Python 2 for new projects in the last ~5 years. It reached EOL this year, nobody in their right mind would use Python 2 for new projects today.

Herb Sutter has a nice talk about it, with several examples, expect 10 year adoption delay if breaking features is a thing.

I do wonder about the approach of defining an 'official' Ratfor or F that is strict subset that removes all the old parts of the language and doesn't worry about compatibility with the old code leaving only what is considered best practice. It might be very helpful to show folks the current way to do things while the full language is available to migrate code if it is considered cost effective. Plus, it would be helpful for go forward code. I wonder what a Rational C++ would look like with Concepts and the lot.

In addition to libraries, we often have colleagues and persuading colleagues to agree on a which features should be prohibited can be difficult in many organizations.

> Once you get users, you have responsibilities, and one of the responsibilities is not to break their code.

That's rich. Figuring out how to use C++ on a large project (where you often depend on existing codebases) is always an exercise in figuring out what subsets of what version of the language to use. Presenting C++ like one language that has maintained backwards compatibility is, at best, a gross oversimplification of what is one of the bigger headaches of using C++.

That being said, I can't remember C++ ever doing something directly destructive and unnecessary like redefine how integer division works like I have seen in certain other languages that also result in hostility towards the user.