Hacker News Reader

Comment by tribby | Hacker News Reader

while I don't disagree with your premise, I think a more generous conclusion is that the angular team has learned from the 1->2 disaster, and has decided to focus on the long term, even if that means causing more headaches in the short term.

still, I'm glad I moved to vue.

View on HN

But my concern is about how they are scheduling breaking changes to occur so frequently, and almost two years in advance! Why induce that kind of headache over and over so regularly that the short-term issues become a long-term software maintenance burden?

I cannot imagine working on a software project where I'd want to plan out four distinct breaking change updates. I simply cannot prognosticate my needs that well, nor chessmaster so deeply that I wouldn't just do it in one bigger change. If they're anything like me, that means they're committing to inducing the hassle _without even knowing what the payoff is_!

I think they're just being very strict about what counts as breaking. They gave the example of upgrading the typescript compiler they use as breaking.

There's a Korean saying for this, it goes something like: "when the navel outgrows the belly".

> while I don't disagree with your premise, I think a more generous conclusion is that the angular team has learned from the 1->2 disaster, and has decided to focus on the long term, even if that means causing more headaches in the short term.

Did they really ?. If they did they would focus on API stability instead of breaking changes. Moving to semver is an issue when a product didn't use semver at first place.

I want them to succeed but I also want to be able to pickup a framework I didn't use for a year without having to relearn its API.

This was the same philosophy behind python 3, released 8 years ago. Still amazes me how slow the shift from 2.* -> 3 has been.

Python 2 to Python 3 is the preeminent example of how NOT to transition a software platform.

Can you post a summary of what they did wrong, and what they should/could have done different?

Or do you think they should not have done any breaking change at all?

They probably should have followed the PHP release pattern, which introduces breaking changes to the language in a more gradual way, over a couple of releases, instead of doing it in one big go.

On the other hand, the assumptions people have about the changes between Python 2 and 3 are probably bigger than they really are. I've started writing new code in P3 the last two years or so, and the only thing that still stumbles me from time to time is the parentheses around the `print` method.

Honestly, the string / unicode fix is the biggest thing that breaks Python 2 scripts in Python 3, and Python 3 is so much better for having made the change. I don't see how that particular change could have been pushed through without breaking everything--and yes, I am counting the miscellaneous fixes they pushed through afterwards like bringing back u''.

They didn't do anything wrong. But users are left with massive Python 2 codebases (certbot/letsencrypt, caldav-server/twisted, blender, maybe some OpenStack stuff and probably much more) that are very useful/essential to their users. What do you expect mere users to do? Invest massively in porting (adding test cases in the process where there don't exist any)? They will rather keep Python 2 around forever.

I wouldn't be surprised if Blender was dragging their feet moving to Python 3 just because all of the major 3d software tools have embedded Pythons that are only recently reaching 2.7 (Maya, Nuke, Houdini, Mari, etc).

Every OpenStack release has "more compatibility with Python 3" in their changelog.

One big problem they had was that they felt that hosting multiple Python versions on a system was a sysadmin problem, not a language runtime problem.

This is an issue because many platforms and products shipped with some python2 scripts. So a developer trying to use python3 needed to start by setting up a mixed environment on their own.

Ruby could get away with crap like that because it wasn't widely used outside of Rails before rvm/rbenv was common.

Setting up python3 as the default python could break certain Linux distros.

Even today MacOS ships with python 2.7 as the default.

don't forget perl6...

As someone not familiar with the situation, could you please give a brief of what happened with the Python 2 to 3 transition and why did it turn out so bad?

Python 2 had an inherent flaw with character encoding. While passing data around, strings and bytes were treated as the same thing, until they weren't the same thing, at which point your software broke in horrible and unexpected ways.

Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/ https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.

The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.

Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.

Reply on news.ycombinator.com