4 ms·

Would you rather Java? Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric? Where everything is shit becaus

by ant5 16y ago

Would you rather Java? Is that a real question or were you just setting up your false dichotomy via some well-placed rhetoric? Where everything is shit because of backwards compatibility? Oh, so that's why Java is so bad? Because it has some stagnant corners in which they're maintaining backwards compatibility? That's silly. Backwards compatibility isn't holding back Java the language, or even Java the VM. Bad design decisions and an almost knee-jerk opposition to any forward progress holds Java back. You don't have to break compatibility to implement closures, you just have to herd cats until you can get people to agree on a proposal and implement it. They've put a hell of a lot of work into making everything as compatible as possible with 2.7 But it's not actually compatible. And it may not be again in the future. And it's really easy to introduce binary incompatibility due to the implementation of traits. If you look at other production programming environments, from C# to Objective-C, the maintainers bend over backwards to maintain binary and API compatibility across releases because it's bloody expensive to upgrade everything in lock-step, force all your customers to upgrade, wait for all your vendors to upgrade, and move the entire ecosystem to a new version in one gigantic step. At some point you need to say, enough is enough, we're going to upgrade out and people will have to make minor changes to their source code to get the new features. They had 7 release candidates, so they've made a commitment to quality and given people time to upgrade leisurely. Upgrade leisurely? To a release-candidate quality language release? Are you joking? Even if we wanted to upgrade to an RC release (and we didn't!), we'd had to wait for the libraries we depend on to be updated too (and wait for time to block development while we upgrade all internal components in lock-step).

andrew1 16y ago
That's an excellent response, and I'd mostly agree with you. I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose. Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.

by ant5 16y ago

andrew1 16y ago

That's an excellent response, and I'd mostly agree with you. I'd only add two things; firstly, I got the impression at Scala Days and from mailing list discussions that there was a little bit of a feeling that 2.8 was the last chance to fix some design choices that the designers didn't like. That Scala is big enough and well used enough now that they're not going to get away with the same behaviour for 2.9 or 3.0 and that there will be a lot more concern for compatibility in future. Whether it happens remains to be seen I suppose. Secondly (although you might disagree with this), there are no glaring problems with 2.7 so there's no need to rush to upgrade to 2.8, there shouldn't really be a problem with waiting 3-6 months for your dependent components to release (stable) 2.8 versions. I think that we're lucky that we don't depend on many external libraries so we'll be upgrading pretty soon, but it wouldn't be the end of the world if we had to wait a few months.