Hacker News new | past | comments | ask | show | jobs | submit login

I think my takeaway lesson is that it’s very hard to introduce large, breaking changes to a language and not alienate a large proportion of existing users. I don’t know that there’s a right way.

I look at Perl, which was a juggernaut when I first used Python, and announcements of Perl 6 certainly didn’t help Perl’s slide. Often cited is the fact that Perl 6 is a totally different language unrelated by anything but creator and name. The Perl brand was not enough to carry the bulk of Perl users from Perl 5 to Perl 6. Perl 6 is now called Raku, which probably better reflects the magnitude of the change.

On the other hand Python 3 is a small but still significant departure from Python 2. If they’d called Python 3 something else, we’d probably be griping about how superficially different from Python 2 it was without bringing substantially new ideas.

Oddly my feeling is that Racket, in its departure from mainline Scheme, largely did retain its core audience, but that may have been a feature of its usage in academia.

Fast forward to last year when a prominent Racket architect announced “Racket 2” which would completely change the syntax of the language. Prominent community members reacted negatively, due to fears of Perl 6’s fate. But now they’ve decided to simply call the new research language Rhombus and have reiterated plans to continue supporting Racket. I went from feeling very negative to the change to being okay with the direction.

I’m not sure there are lessons to draw, other than noting than version bumping versus making a new language with a new name can be bad for entirely different reasons.




I'm not well informed about the breaking changes made under the hood in Python 3. But I wonder if breaking backwards compatibility in this case wasn't simple an externalization of costs. The community certainly went through a TON of work to port libraries, etc. Could all those man-hours have gone towards making incremental, backwards compatible changes instead?

I think the takeaway is that if you want to make breaking changes, make a new thing and turn the old thing over to a maintenance team. If after a while you learn some things that could improve the old thing see if they can be incorporated without breaking compatibility or if the new thing is really so much better people will switch.


Everything that I've heard that was changed from Python 2 to 3 are reminiscent of things that Perl5 handled while maintaining backwards compatibility.

I mean Perl5 is still mostly backwards compatible back to the original version released in 1987. (There were a few rarely used bad features that should have never been there which have been removed.)

The way it does this is by having you specifically ask for the new features, if they would otherwise break code.


I think that's the wrong takeaway, especially since it kind of absolves Python of doing anything wrong. There were many examples of ways that this was unduly hard just because of how poorly the transition was designed for.

> While hindsight is 20/20, many of the issues with Python 3 were obvious at the time and could have been mitigated had the language maintainers been more accommodating - and dare I say empathetic - to its users.


The author's suggestion of permitting a certain set of "from __past__" imports seems especially astute. This would have made it much more possible much earlier to have a single large codebase running natively on the Python 3 interpreter, but with modules (especially leaf modules) at varying degrees of ported-ness.

In contrast, the original porting guidance for module authors was actually to maintain the Python 2 source as the master copy, and use 2to3 to transform it for running tests or cutting a Python 3 release. How is a transition ever supposed to happen if the new hotness is perpetually a second class citizen?


> The author's suggestion of permitting a certain set of "from __past__" imports seems especially astute.

Hell that's essentially what ended up happening over time, as past features got reintroduced (the `u` prefix, bytes.__mod__, `callable` being reintroduced, `range` being improved, …), as well as the serious Python3-ification of the Python2 branch that was 2.7.


I feel like "from __past__" would have allowed projects to get to the point where they were "on Python 3" much sooner, though.

The mentality would have been "we're on Python 3, and we have a long tail of cleanup to do excising from-past out of our codebase" rather than "we and our users are all still on Python 2 but we thiiiiink our code is mostly using constructs that are Python 3 safe. We get a green CI checkmark, anyway, but who really knows."


Hmm, I didn’t mean to convey that the Python 2/3 transition was done well. I think lots of projects have tried to port their community success to substantially different projects, and that most have failed for a variety of different reasons.

Python 3 is a “success” in that a lot of people have moved. But it was, as you rightly point out, a hard won victory that left a lot of people unhappy.


> introduce large, breaking changes without major benefits

FTFY


Re: Often cited is the fact that Perl 6 is a totally different language unrelated by anything but creator and name

Indeed. That is why Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

I'm not sure what lessons can be drawn from this, other than being indecisive has its price.


I totally agree with you, I am uncomfortable with Racket 2 having a non-Lisp syntax. As someone who has used Lisp languages to get stuff done for over 30 years, I would say NO to the syntax change.

That said, Racket is open source the maintainers have good reasons for a change based on getting a larger user base. I wish them great success.


I disliked the “Racket2” name because it strongly implied that Racket 1 (the one with parentheses on the outside and few commas) was the past, and that something with a vaguely Algol-ish syntax was the future.

But Racket as a project was always about language experiments. I certainly didn’t bristle at Typed Racket or any of the other languages. And so, in changing “Racket 2” to “Rhombus” and committing to mainline support of Racket, I feel pretty comfortable with the direction. I find this fascinating that I feel this way given that nothing has really changed but the name.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: