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

I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless.

To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in both ways, changing the language just enough to break most people's code, while changing it too little to effect significant change. It combines most of the disadvantages of both backward compatibility and novelty, with few of the advantages of either.




I'll happily debate the merits of breaking compatibility in general, but it's boring and completely academic for Python 3 which is getting on for a decade old and has very wide community support.

Same thing every Python thread. It doesn't matter if you liked the way 3.0 was handled (and there certainly was complaint at the time too), it's what Python is now, and that's that.


To also compare: Ruby made big breaking changes similar to Python 3 and called it "Ruby 1.9".

It wasn't really a big deal. There was some pain and it became essential to have multiple versions of Ruby installed. But I haven't heard of anyone insisting on new code written for Ruby 1.8.

So languages can break backwards compatibility once in a while, and it doesn't always have to be the shitstorm it was for Python.

Early 3.x was bad, and that probably gave critical mass to the backlash. But there's no reason to care anymore about what early 3.x was like. Modern 3.x is a way better language.


I was an outsider to the Ruby changes between 1.8 and 2.0, so thanks for the perspective. My sense was that, like modern JS programmers, they were used to constant churn and breakage, so having the language break as well was only a minor additional nuisance. Most of the stuff they used with 1.8 would be "obsolete" in a year or two even without 1.9.


Your view of Ruby programmers might be confused with Rails programmers. Those are more used to the "constant churn and breakage" which I also see as coming somewhat from the web side of programming. Although it's less of an issue in Rails as you can have properly stickied versions in a project.

AFAIK there was no breaking change in Ruby after 1.9, so anything that runs on 1.9 should run on any Ruby version up to the most current.

The biggest change in 1.9 was the support of different encoding and making UTF-8 the default encoding. Ruby did it differently than Python, so a string in 1.8 was a byte string, whereas a 1.9 string was a UTF-8 string. This off course broke many scripts.


Python 3 demonstrates exactly how much change a language project can get away with. Python is just barely managing the transition; any more change and it would have ended up like Perl 6. Perhaps future developers can use this data to plan large and painful migrations.




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

Search: