4 ms·

I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result,

by spease 2y ago

I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago. I think the only way to address what you're alluding to is to continually deprecate small parts of the language, so that upgrading is manageable for active codebases. And you probably have to be really aggressive about pushing this forward, because there will always be excuses about why you should hold back just this one time and this one feature is an exception that needs to be held back just a little bit longer. But in the long run, if you don't force people to change a little bit continuously, it will become a big enough issue to split the ecosystem. See python2 to python3. Or you end up forced into supporting bad practices for all eternity, like C++. And having to take them into account for every. Single. New. Feature. Further raising the barrier to entry to participation in developing the language to people who are completely focused on its development and have unusual mastery of it, who can't identify with the people struggling with its complexity. If not at the technical level, then at the business level, where people definitely don't have the time to understand why it'd be safer for the go-to heap allocation method should return a scoped pointer instead of a raw pointer. Unfortunately, this probably is only viable for strongly-typed languages like C#; for loosely-typed languages like Python, the risk of iterative changes is that if someone moves a codebase several generations ahead at once, it'll introduce lots of subtle changes that'll only become obvious once certain codepaths are exercised...and given how bad testing coverage is for a lot of software, that probably risks breakages only occurring once it's deployed, that are nontrivial to discern via reviews or even static analysis.

pjmlp 2y ago
Not keeping up with the language is quite common in traditional enterprises, that is why you get shops still doing Python 2, Java 8, .NET Framework (C# 7.x), C89, C++98,.... People get paid to keep running what already exists, not to write new stuff. Usually new stuff only comes to be if there is a new product being added into the portfolio, and most of the time it comes via an aquisition or external contractors, not new development from scratch in a cooler version of the stuff they are using.
pjc50 2y ago
> continually deprecate small parts of the language Did you see https://news.ycombinator.com/item?id=41788026 https://news.ycombinator.com/item?id=41788026 ? "My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jettison packages they may want to keep using, or deal with the hassle of patching unmaintained dependencies on their own. For those Python users for whom writing python is the core of their work that might be fine. For all the other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...) the choice is untenable. While python can and should strive to be a more 'serious', 'professional' language, it _must_ have respect and empathy for the latter camp. Elevating something that should be a linter rule to a language change ain't that." Strongly phrased, but planned obsolescence in a language is really expensive. You're basically quietly rotting the work of your users, and they will hate you for it. I note that C# basically hasn't deprecated any of the language itself, the dotnet core transition was a big change to the runtime. And that was expensive enough, again due to dropping a lot of old libraries.
- sensanaty 2y ago
  But they can simply continue using whatever version of Python works for them, right? I never got this argument, personally. Sure, having to rip out a bunch of code because of lang-level changes can suck, but you also only really need to do that if you're starting a new project anyway or for whatever reason want to keep being pinned to @latest version of the lang. If you're a researcher who uses Python 2 as a means to an end, then just stick to Py2. It's unreasonable to expect the entire python world to freeze in place so you don't have an annoying migration journey. If you need the latest Py3 features, them's just the brakes I'm afraid, eventually APIs need to change.
  - spease 2y ago
    No, because features get added to new versions of Python, and libraries they need to use may depend on those features. “Just don’t upgrade Python” is advice that’s only going to last a finite amount of time before introducing pain points and/or risk.

by spease 2y ago

pjmlp 2y ago

Not keeping up with the language is quite common in traditional enterprises, that is why you get shops still doing Python 2, Java 8, .NET Framework (C# 7.x), C89, C++98,.... People get paid to keep running what already exists, not to write new stuff. Usually new stuff only comes to be if there is a new product being added into the portfolio, and most of the time it comes via an aquisition or external contractors, not new development from scratch in a cooler version of the stuff they are using.

pjc50 2y ago

> continually deprecate small parts of the language Did you see https://news.ycombinator.com/item?id=41788026 https://news.ycombinator.com/item?id=41788026 ? "My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jettison packages they may want to keep using, or deal with the hassle of patching unmaintained dependencies on their own. For those Python users for whom writing python is the core of their work that might be fine. For all the other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...) the choice is untenable. While python can and should strive to be a more 'serious', 'professional' language, it _must_ have respect and empathy for the latter camp. Elevating something that should be a linter rule to a language change ain't that." Strongly phrased, but planned obsolescence in a language is really expensive. You're basically quietly rotting the work of your users, and they will hate you for it. I note that C# basically hasn't deprecated any of the language itself, the dotnet core transition was a big change to the runtime. And that was expensive enough, again due to dropping a lot of old libraries.

sensanaty 2y ago
But they can simply continue using whatever version of Python works for them, right? I never got this argument, personally. Sure, having to rip out a bunch of code because of lang-level changes can suck, but you also only really need to do that if you're starting a new project anyway or for whatever reason want to keep being pinned to @latest version of the lang. If you're a researcher who uses Python 2 as a means to an end, then just stick to Py2. It's unreasonable to expect the entire python world to freeze in place so you don't have an annoying migration journey. If you need the latest Py3 features, them's just the brakes I'm afraid, eventually APIs need to change.
- spease 2y ago
  No, because features get added to new versions of Python, and libraries they need to use may depend on those features. “Just don’t upgrade Python” is advice that’s only going to last a finite amount of time before introducing pain points and/or risk.