undefined | Better HN

0 pointsstormbrew11y ago0 comments

I agree this has historically been true, but again, I think this is changing. Ruby 1.9 and Python 3 both did more than accrete, they actively broke existing code in quite significant ways.

C++ has so far avoided completely breaking changes, but with all the accretion it's doing now it's probably only a matter of time before some significant breaking changes happen lest it become even more ridiculously complex than it is now.

Go has had breaking changes as well, I believe, but they have a smart upgrade tool to help with it. This is probably something that will catch on for other rapidly evolving languages.

I think we'll see a lot more of this kind of thing in the future.

0 comments

chc11y ago

Ruby and Python each did one release where they were willing to do significant changes. That's it — they're not doing it again for a good long while now. It's an isolated incident, not a trend in those languages' development practices that we can project into the future.

Go did breaking changes pre-1.0, but they are now committed to providing a stable platform that only accretes features (http://golang.org/doc/go1compat).

stormbrewOP11y ago

I don't expect either of them to do it for a while either. The trends I'm talking about are in PL development in general. More breaking evolution is taking place post-initial-development than ever has before in languages both new and old.

Note that the Go compat wiki you link to acknowledges a future Go 2 that may break compatibility. That's actually a pretty strongly pro-evolution statement compared to past languages.

chc11y ago

The statement you were questioning is that Swift will be "fixed for a decade at least" after release. If you agree that it will be at least four years before Python makes any more changes like Python 3, then you are agreeing with the OP.

stormbrewOP11y ago

I'm noting an acceleration in recent years and believing in the possibility of further acceleration going forward. Part of that being newer languages being more willing to undergo breaking changes sooner in their evolution than older ones were. Thus, I agree that Python might stay at a big change every ten years (which would still be faster than historical language evolution!) while still believing that swift or go might go for faster than that.

It's also worth noting that Swift isn't even at 1.0 yet, and they've said there will be changes before release. So I also disagree with a somewhat hysterical "we'll be stuck with this!!11!!" right now.

It's all just guesses, though. We'll see.

danudey11y ago

Python 3 is also not meant to run Python 2.x code. It's pretty trivial to port most code from Python 2.x to Python 3, but there's no real reason to do so unless you're writing a library or other project for other people to take advantage of.

It was intentionally done as a 'clean break' release; 2.x keeps doing the same stuff it used to do, and Python 3 changes a bunch of stuff which, in hindsight, makes sense (such as a distinction between 'stream of bytes' and 'string of text', vs. 'stream of bytes which may or may not be ascii text' and 'string of unicode text').

That said, there's no real benefit to moving an existing project/codebase from 2.x to 3.x, and it was never intended that there would be one. Python 3 is for new projects; Python 2.x is for existing projects, or new projects which need deployment in older environments.

stormbrewOP11y ago

Which is one of the reasons I think it's a sign towards acceleration. People are developing strategies to deal with language evolution. This, "import from __future__", and gofmt are all tooling that helps you deal with a language that's still willing to evolve.

That said, I don't think this part of the python3 effort entirely succeeded. Unfortunately they share a package source, so a lot of projects do need to support both. But whatever failings there have been in the python jump to 3.0, they're nothing compared to the disaster that was ruby 1.9, even though I think 1.8.7 is truly relegated to legacy now.

As long as they learn from those issues, though, I think the future is bright for non-stagnating languages.

j / k navigate · click thread line to collapse

0 comments

chc11y ago

Go did breaking changes pre-1.0, but they are now committed to providing a stable platform that only accretes features (http://golang.org/doc/go1compat).

stormbrewOP11y ago

Note that the Go compat wiki you link to acknowledges a future Go 2 that may break compatibility. That's actually a pretty strongly pro-evolution statement compared to past languages.

chc11y ago

stormbrewOP11y ago

It's all just guesses, though. We'll see.

danudey11y ago

stormbrewOP11y ago

As long as they learn from those issues, though, I think the future is bright for non-stagnating languages.

j / k navigate · click thread line to collapse