Because objectively our languages are still quite awful and we still have a ton of progress to make.

Look at Python or JavaScript or C++ 10 years ago. They each encompassed the same philosophy they encompass today but lacked a lot of the ergnomics and tooling that make them better languages.

Look at Go or Rust 5 years ago. Look at Java. We are constantly improving our languages because improving a language is a great productivity win.

> We are constantly improving our languages because improving a language is a great productivity win.

I think that ignores the time invested in the upgrade churn and making sure all the little pieces stay compatible.

Home OS releases have moved to yearly release cycles and it drives me nuts. AirPods Pro, released in the last few days, requires macOS Catalina 10.15.1 for full compatibility. A lot of software hasn't been updated (and likely will never be updated). I don't mean to single out this one thing, there are countless other examples.

Businesses I've worked at have kind of ignored these cycles. CentOS seems to have 1-2 dot releases a year and most places I've been jump to the new one every 3 years or so (major releases even longer).

I don't have recent experience with Python because my industry is still stuck on 2.x. The transitions between 2.3, 4, 5, 6, 7 were fairly smooth, but at that pace of new versions and code changes it was pretty common to straddle 3 versions and stumble on bugs fixed long ago in major versions we weren't able to adopt yet.

It sometimes feels like we can never make progress in higher level tools because we're trying to keep up with lower level tools.

> AirPods Pro, released in the last few days, requires macOS Catalina 10.15.1 for full compatibility.

With Apple, I suspect this is intentional to force you to upgrade. It may not be an active decision, but there is probably zero internal pushback when it happens.

Python designers should learn a thing or two about how C++ and Java people manage their language updates. It makes no sense to use a language that stops supporting features like Python wants to do.

taking something awful and making it less awful is different than making something good better.

python is 2 is a good programming language by any standard , i would like to see a fork of python 2 with emphasis on LTS and performance optimization.

The whole reason why python became popular is because it had a very shallow learning curve. introducing new cryptic language features every year Is not going to make it easy for new comers. I can say with some certainty that no one is going to use a pure python implementation in production(atleast not yet).

I absolutely agree with this sentiment and seeing Python move further and further from "There should be one obvious way to do it" scares me.

I totally get why you'd want a language with async iterators and typings and why you'd want a language with easy data science interop and easy CPU - I am just not sure they should be the same language and I think it should be possible to learn how to do one (e.g. data science) without the other (high throughput async programming, typings etc).

I really hope the smart people behind the helm have the foresight to discuss the implications of language size. As someone involved in the process in JavaScript both as Node core and as an individual this deeply concerns me there as well.

pypy is going to continue supporting python 2 indefinitely. They focus on that LTS release and care about performance.

its been a long time since i used it . is it stable ? it anyone using it in prod ? does it have a decent packaging solution ?

Yes, it's stable.

Yes, people are using it in production. (Examples at https://www.reddit.com/r/Python/comments/bv50uz/is_anyone_us... ).

Is 'pip' a decent enough packaging solution?

cool i will check it out then .

Something can't be objectively awful.

Awful is a subjective descriptor.

There are several objective measures for programming language "awfulness". The ones I've seen published the most in papers are:

- Time to identify bugs in code

- Defects in written software in fixed exercises

- Defects in written software in real code

- Time to develop a certain program

I can't say that the measurements of these is easy - but when we measure these with old vs. new languages we see change.

One can claim something can't be "objectively good or bad" in the Popper sense of science only caring about falsifiability or in the Quine sense of "just predicting" but that becomes a philosophical argument and debate.

In my opinion since languages are how we express ourselves and we write code in a _very_ roundabout way in many cases - languages are in fact objectively awful, the number of defects is huge, development time is long and developer experience is something few people deal with.

The literature on developer experience and programming language API is just starting to emerge and we are still very very early on.

And of course all the research on this is pretty bad, on grad students / biased samples and the methodology isn't great but it's better than nothing and we should strive to improve it.

If anything that just shows how bad things are. (Although I believe they really are improving)

> One can claim something can't be "objectively good or bad" in the Popper sense of science only caring about falsifiability or in the Quine sense of "just predicting" but that becomes a philosophical argument and debate.

Yes, one can claim such a thing. However you don't have to debate it you have the foresight to not make claims about the subjective qualities of the objective world.

Your comment inspired an interesting thread about how nothing can be objectively good or bad. ..until it seems the only thing that is or can be objectively bad is the GP's use of language.

Well, ok, maybe his language wasn't objectively awful, but just philosophically confused, not efficient or sensible use of words for his intended purpose. If you elaborate on that sentence, you will both be able to agree on what was actually meant, coming at it from each side.

I don't think language can be objectively bad. It can be more or less effective in communicating an idea.

I just wanted to help him see the world in a way that is more similar to the way I see it. I think the way I see the world is a good way to see it.

I spreed my perspective like a virus.

Even in taste, some things are objectively awful -- eating shit for example.

Whether some bizarro outlier likes it doesn't matter, the statistically significant majority doesn't. So, it's not that shit is subjectively good or bad taste it's that said persons are objectively weirdos.

In other fields things are subjective, but people who know better have a canon, which is a more objective ranking. E.g. how Vanilla Ice is worse than Bach in substantial ways, even though some (even many) might prefer the former.

Programming languages are also part of computer science, which has some downright objective criteria too.

Counter-example: https://en.m.wikipedia.org/wiki/Whitespace_(programming_lang...

Thank you! That page links to a funny Bjarne Stroustrup (April Fools) paper I hadn't seen on overloading whitespace, Generalizing Overloading for C++2000.

http://www.stroustrup.com/whitespace98.pdf

I think Python 3 is a less cohesive and worse-designed language than Python 2 in many ways. JavaScript and C++ should have been abandoned.

And yes, let’s look at Java. Scala, Clojure, and Kotlin were all exciting new languages at one point that maintain backwards compatibility by sharing the JVM, obviating the need to make Java itself better—though I will admit that Java itself has improved a hell of a lot.

Java itself has improved a lot taking inspiration from Scala and other languages itself and adding a lot of features (streams lambdas etc).

Worth mentioning Kotlin, Scala and Clojure also improved and changed _a lot_ in recent years and so did Go and Rust and other "new" languages that aren't 30 :]

Nothing would make me happier than to see JavaScript and C++ abandoned (two of the most popular programming languages and the two I use the most except Python probably). However that would require a lot of work to accomplish and such huge undertaking is usually done a lot more incrementally. Doing it in a "big bang" fashion would be quite a lot of work.

That is, JavaScript and C++ are very different than they were 10 or 20 years ago - not just in terms of tooling but also in terms of the language itself.

I understand improvement, all right. I am not against that. What I feel is wrong here is that we get new features every year. A language should be a minimum set of features that everyone uses and not 'all features everyone would ever need'

and long term stability and backward compatibility is a must for a language which is as famous as Python

Python is not just the language, there is a standard library that is part of the distribution. That library requires bug fixes and feature updates.

Yes, but what good is a language which was easy to use and one which is now introducing a new feature every year? Do you think everyone will upgrade? At work, we are still stuck with Python 2.7 with no intention to upgrade despite what.

No language is perfect, so languages either improve over time or lose to other languages which do.

On why fixed release cycles are a good thing, I find this FAQ by Herb Sutter of C++ fame enlightening: https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...

It doesn't make them necessary, just likely better than the alternatives (ie. no change or changes “when it's done”).

Given that the pace of technological innovation cannot be stopped and all existing technologies have flaws, the alternatives are:

A) Accept that your language will change over time and manage it.

B) Over time, keep changing to better languages after your language dies out.

Yeah, I think A would be the preferred option.

English constantly changes. We invent new words to encapsulate new concepts that we didn't have before. It's kind of necessary because the world keeps changing. Why not computer languages too?