5 ms·

> Once you get users, you have responsibilities, and one of the responsibilities is not to break their code. That is both a good and bad thing. Within both C+

> Once you get users, you have responsibilities, and one of the responsibilities is not to break their code. That is both a good and bad thing. Within both C++ and JavaScript there is a very elegant programming language with powerful semantics. However, there are also a lot of bad solutions and dangerous hacks accumulated. And most of us programmers don't know how or don't have the self discipline to separate the good parts from the bad parts. And sometimes even with the knowledge and self discipline you can't avoid them (e.g: when using someone else's libraries). In some languages (e.g: Lua, Python) the designers are ready to break backwards compatibility. C++ chose not too.

pjmlp 6y ago
Herb Sutter has a nice talk about it, with several examples, expect 10 year adoption delay if breaking features is a thing.
throwaway894345 6y ago
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.
- deleted 6y ago
  [deleted]
vii 6y ago
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!
- nindalf 6y ago
  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.
  - pjmlp 6y ago
    Not really, plenty of MBA type managers use it as a measure to allow for language adoption on their projects.
  - hota_mazi 6y ago
    > Two things - TIOBE is meaningless. Pick any other language survey of your choice and I guarantee you it will generally agree with the TIOBE.
    - rumanator 6y ago
      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.
      - dgellow 6y ago
        That's maybe a good name for a successful programming language :) TIOBE driven design is the future!
  - coliveira 6y ago
    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.
- nojvek 6y ago
  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.
protomyth 6y ago
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.
bborud 6y ago
> 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.
twblalock 6y ago
> 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.
- ErikBjare 6y ago
  >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.

pjmlp 6y ago

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

throwaway894345 6y ago

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.

deleted 6y ago
[deleted]

vii 6y ago

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!

nindalf 6y ago
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.
- pjmlp 6y ago
  Not really, plenty of MBA type managers use it as a measure to allow for language adoption on their projects.
- hota_mazi 6y ago
  > Two things - TIOBE is meaningless. Pick any other language survey of your choice and I guarantee you it will generally agree with the TIOBE.
  - rumanator 6y ago
    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.
    - dgellow 6y ago
      That's maybe a good name for a successful programming language :) TIOBE driven design is the future!
- coliveira 6y ago
  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.
nojvek 6y ago
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.

protomyth 6y ago

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.

bborud 6y ago

> 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.

twblalock 6y ago

> 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.

ErikBjare 6y ago
>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.