> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

This mentality is the true cancer of software development IMO. Can you imagine the utter insanity and chaos if any other form of engineering worked this way? Programming languages are like protocols and standards: they are a common platform that people build on; simply deprecating them with no plan for backwards compatibility requires everything to be rebuilt, which represents a tremendous cost. Sometimes these changes are worth it, but outside of software, these are usually once-in-a-lifetime changes.

I can't think of any fundamental technical change between Python 2 and Python 3 that make this scale of disruption worthwhile. If the maintainers of Python don't want to maintain Python 2 anymore, they are completely free to make that decision, but it's a decision worth criticizing and complaining about. It is not a good thing for all software developers to be forced to rebuild the same sand castles every time the tide goes back out.

> Can you imagine the utter insanity and chaos if any other form of engineering worked this way?

You mean like how when I bought my house I had to bring the wiring up to code and replace the knob and tube?

This is how the rest of the world works. The time scales are simply longer.

> This is how the rest of the world works. The time scales are simply longer.

Which is exactly the point I'm making. Nobody is going to deprecate 120V power for the kinds of reasons that software platform deprecations happen.

But big changes do happen. In 1948, the west coast changed their power standard from 50Hz to 60Hz[1]. Or changes don't happen, Japan still has two standards[2]. Or, like metric in the US, it slowly changes but likely will never completely happen.

[1] https://gizmodo.com/before-1948-las-power-grid-was-incompati...

[2] https://en.wikipedia.org/wiki/Electricity_sector_in_Japan#Tr...

Sure, but the pace of these changes is significantly different. Clearly part of this is due to Moore's law; perhaps standards in aeronautical engineering shifted about as quickly during the transition from biplanes to supersonic jets as our software standards and frameworks are changing today.

But that's no reason to reflexively dismiss the very good and very interesting question of why one should have to largely rewrite a Django app in 2019 that does the same thing that it did in 2010, in a language that is virtually functionally equivalent in any respect that is relevant to that particular developer. Software does not inherently need to be as ephemeral as it is.

This is a scope problem. If thousands of people were constantly attacking your door's locks you better believe that locks would constantly be changing and that a house with older locks would need to have them upgraded.

Changes to physical items are costly and not affected by the same types of security scope that _any_ code connected to the internet is. The code in my decade old microwave has never needed to be upgraded and probably never will be upgraded, but it's also not under constant attack.

His Django app continued to run, he just couldn't make use of the most up-to-date features and security unless he upgraded.

I get the need for security updates. That’s why you use high level frameworks to write your application and update the rest of the stack that runs underneath. The issue is when parts of that stack are replaced with backwards-incompatible-but-functionally-equivalent parts, for reasons that have nothing to do with security.

But that's why you have to look at the maturity of the tech when first building it--sometimes you just don't know. Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

If you had built your page using static html there would be a lot less surface area of attack and a lot less maintenance. Even with Django, the amount of churn depends on which features you use.

You hear similar stories about people chasing the new Javascript framework treadmill. Some people stuck with Vanilla JS, others are still using jQuery.

I just don't see the real world being all that different. Blackboards still work just fine like they did 100 years ago. Some schools transitioned to marker boards, and some moved again to "smart boards." Many were forced along because repair/replacement supplies were harder and more expensive to find. I see the same thing with washing machines or people's favorite pen/pencil.

In fairness, I suspect the author would agree that it was a mistake to use Django in the first place. I think that's what he was trying to get at!

> Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

In 2010, the conventional wisdom was still, "nobody uses Python 3, there is no library support for Python 3 so just use Python 2". Django itself didn't support Python 3 until 2013.

In hindsight he can say it was a mistake, but it was glaringly obvious back then that Django, Python 2, or Python 3 wouldn't give you a situation where you would have minimal maintenance for the next 10 years because of the volatility already publicly discussed.

But maybe you're right that this isn't something people think enough about when choosing technologies and the author is trying to raise awareness.

Oh I don’t know... “star-star” is pretty cool... I tend to agree with the others who think this is a little too much bellyaching.

> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

That might not need to be the case. I guess we'll see: one of Rust's tenets is perpetual backwards compatibility. New features (and potential breaking changes) are opt-in with a per project configuration setting.

Doesn't JavaScript do it the same way?