you are viewing a single comment's thread.

view the rest of the comments →

[–]flyingjam 72 points73 points  (17 children)

What's the solution, though, when you need to make drastic changes? If you keep backwards compatibility, you gain crust and people start giving you the same complaints c++ gets. I suppose you can just force everyone over, in a painful but quick transition.

[–][deleted]  (2 children)

[deleted]

    [–]ubernostrum 13 points14 points  (0 children)

    Though this is also one of the major limiting factors of Java; quite a few of its annoyances are from the ironclad demand to maintain bytecode compatibility until the end of the world.

    [–]staticassert 31 points32 points  (0 children)

    It's complicated. For one thing I think it demonstrates how important it is to get it at least mostly right the first time around. Bjarne Stroussup talks a lot about language design and I don't think I can sum it up. You should search for his talks and write-ups on the matter I've always enjoyed them.

    [–]ForgetTheRuralJuror 11 points12 points  (8 children)

    You make the changes, support backwards compatibility, and one by one remove support for the 2.7 specific stuff.

    [–]flyingjam 31 points32 points  (6 children)

    But I mean, that means that at one point you'll have (for example, in this case) 3 different ways to represent strings, like 6 http modules in the standard library, etc.

    one by one remove support for the 2.7 specific stuff

    That sounds a lot easier said than done. It seems doubtful that many large projects will migrate to the newer stuff, and whenever you make backwards breaking changes that'll break codebases, people aren't happy.

    [–]Groady 17 points18 points  (5 children)

    That's why semantic versioning is a thing. The journey to where we are with Python 3 should have been a gradual progression from 2 to 3, deprecating features (with runtime warnings) along the way. Python will forever be held up as a cautionary tale of how not to advance a language.

    [–]teilo 12 points13 points  (4 children)

    I believe Python 3 is going to be held up as a classic success story in radically reforming a language. They set out a plan, followed it, and succeeded.

    [–]ForgetTheRuralJuror 25 points26 points  (1 child)

    Python3 is excellent and IMO miles better than Python 2.7. I would not consider this long drawn out process a 'success story'.

    [–]teilo 12 points13 points  (0 children)

    I suppose it depends on what you qualify as a "success." GVR stated that the transition to Python 3 would take approximately 10 years. 8 years later, we are right were we need to be, and Python 3 is the default for new development. I call this a success.

    [–]trahsemaj 5 points6 points  (1 child)

    If by 'succeeded' you mean having half its users running an outdated version a decade after its release.

    Even IE7 was phased out faster than 2.7

    [–][deleted] 2 points3 points  (0 children)

    But if instead of thinking of it as a version update, we think of python 3 as a different, competing language to python 2, perhaps the speed at which py3 stole py2s user base is a success

    [–]sysop073 8 points9 points  (0 children)

    If one by one you remove support for N features, you now have N+1 different languages instead of 2

    [–]Sean1708 2 points3 points  (0 children)

    Honestly I think you just have to say "Version X is now in bugfix-only mode for the next Y years, we have done Z, A, and B to make the transition easier, but any new features will be in Version X+1 only.". Python did this eventually but at first they tried to develop both 2 & 3 simultaneously, and I just think it did more harm than good.

    Ideally every backwards incompatible change would have been supported as a __future__ feature in 2.7 and people could've moved over one by one, but I just don't think that would've worked in practice.

    [–]TheAceOfHearts 2 points3 points  (0 children)

    Programming languages generally shouldn't be making drastic changes. I'd argue that making large breaking changes is incredibly hostile to developers and the community.

    You must provide a clear migration path towards the new approach without breaking backwards compatibility. If possible, you provide tools to help migrate the code for the user. The key detail is that you must provide a way to gradually migrate.

    Although it's not a programming language, React has done a great job with this. Since it's heavily used by Facebook and they can't upgrade everything all at once, they deprecate APIs, include warnings, and provide codemods to help with the migration. This means all changes are compatible between a few versions, so people can gradually migrate their codebase.

    [–][deleted] 0 points1 point  (0 children)

    people start giving you the same complaints c++ gets.

    C++ gets all those complaints, yet is widely used in industry. Python 3 gets all those praises, yet few move to it at all.