"The language is the code's biggest API" -- my own words.
Breaking that API will result in a new language.
Scala, like several other languages (JS, PHP, Perl), has had very little time to iterate on it's syntax before it got widely used. All these languages want/need to make breaking changes to their syntax, at which point they are at risk of becoming fragmented.
Python3 was not even so much different, still it was (and still is) a hard upgrade for the community.
I really hope Scala manages though, it's the largest FP-on-JVM community I guess, so good luck!
Well -- they have the Python 3 disaster to learn from... you can't break backwards compatibility for minor gains -- if you are going to break it -- break everything you must and make the new thing much better -- half measures in this regard suck.
It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take.
Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point.
Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.
Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless.
Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose.
The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that.
The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption.
Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.
Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.
Sure. But the improvements aren't really that great, and IMO they weren't enough to justify breaking everything. Some combination of a JIT compiler, GIL removal, and optional typing might have been.
The end result is an improved and usable language
And this is why I view Python 3 as instance of choosing purity over practicality. Python 2 was and is a very usable language. It's vastly better than JavaScript, which took over the world by virtue of being available everywhere and having halfway decent performance, which ended up outweighing its huge flaws as a language. I can't help but think that we'd be better off if the effort spent on the Python 3 migration had instead been directed toward speed and browser support.
Perl 6 is an example of a real disaster, on the other hand.
It's a major release and the language does need to evolve at some point. I'd agree that Python maybe got a little too ambitious with the upgrade but it was definitely a good thing.
> Not only is Perl 6 pretty much unusable in practice today
I don't think that's true anymore, and for some subset of people, hasn't been true for a while now. If you consider performance the big blocker, that's getting better all the time[1],and is close to being competitive with Perl 5 ins some areas.
"Compared to Perl 6, the Python 3 development process was perfection."
Comparing to a series of "Apocalypses" (the term used early in perl6 development to refer to radical breaking changes) is not great evidence that python3 is non-disasterous.
Do you really think python3 being 6 years in limbo (and counting) is a good thing? Probably not fatal, but I don't see how it's good.
From the very start its goals were clear. Yes, it took some time to implement them, but this was done rather efficiently and quickly.
Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.
I worked with a group that adopted Python 3 relatively soon after its official release. This would've been around early 2009. We developed a number of large systems using Python 3, without any major problems. Sure, we ran into bugs now and then, but we reported them and they were fixed soon enough. We helped port some libraries to Python 3.
We didn't regret the decision to go with Python 3 then, and the last I talked to people still involved with those projects, they don't regret the choice now. They're glad that their millions of lines of code are targeting Python 3, which is without doubt the future of the Python language at this point.
I don't know why people such as yourself continue to portray Python 3 as a "disaster", when all of the evidence and much of the experience with it shows the complete opposite to be true.
It was a smooth transition for Python 2 users who didn't want to or need to upgrade. It was a smooth transition for Python 3 early adopters. It's a rather smooth transition now for Python 2 users who want to use Python 3. "Disaster" just isn't the sort of term to describe a transition that goes well for all involved.
> Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.
You're speaking in the past tense about a present problem. Many large projects that would like to migrate to Python 3 cannot because the library support isn't there.
This is in no way meant to disparage the motivations that led to Python 3, because it's better in every way than its predecessor. Only that the transition problems are still present, and the larger the project, the more difficult the transition.
Sage (http://www.sagemath.org/), a project I'm involved in, is just one example -- a large, complex project, it relies on dozens of mathematical and other libraries, and to transition to Python 3, all the libraries would have to be available in Python 3 versions -- even one exception would prevent the transition.
It's safe to say that everyone involved would like to see a transition to Python 3. But it's not possible, and for the foreseeable future it's not even likely.
Dynamic language notwithstanding, the transition was badly designed, in terms of being supportable by automation and providing a cost/benefit motivation for upgrade. With something like that, pretty good = disastrously inadequate.
"In terms of complexity, I don't know whether Yammer featured that, but you definitely do hear that a lot [from] many people. Yes, absolutely -- that's precisely what we want to address in the future versions." --Odersky
I read it, I'm just asserting it! Any issue with that?
Breaking that API will result in a new language.
Scala, like several other languages (JS, PHP, Perl), has had very little time to iterate on it's syntax before it got widely used. All these languages want/need to make breaking changes to their syntax, at which point they are at risk of becoming fragmented.
Python3 was not even so much different, still it was (and still is) a hard upgrade for the community.
I really hope Scala manages though, it's the largest FP-on-JVM community I guess, so good luck!