4 ms·
It's often said that Java has been held back (feature-wise) by Sun's obsession with downward compatibility. This article indicates that it may be preferable to
by brazzy 17y ago
It's often said that Java has been held back (feature-wise) by Sun's obsession with downward compatibility. This article indicates that it may be preferable to the alternative...
What's the point of new features when hardly anyone uses them because not only their own code but also most of the important libraries don't support the new version?
- chaosmachine 17y agoDrupal suffers from this same problem. Every time a new major version comes out, all of the existing modules break and have to be rewritten. With over 4000 modules (and roughly the same number of module authors), it's a serious problem. What ends up happening is everyone keeps using the old version of Drupal until they're forced to upgrade or abandon it due to security concerns (old versions don't get patches from the security team).
- steiger 17y agoIt's of course a trade-off. I think the changes that made into Python 3.0 were welcome, and breaking downward compatibility was a hard but acceptable consequence. It's a difficult matter: Let the language evolve and break things, or make it grow old and stale? Careful ponderation should be made.
- amix 17y agoI don't think backwards compatibility is the problem. The problem with Py3k is that it does not offer any vital features, it requires a lot work to port to Py3k (to top that off Py3k is slower than Python 2.x). The only way I can see Py3k successful is if there are clear advantages to move to Py3k, like improved performance or extra vital features (like improvement of inline functions (lambda)). The improved performance is also a big question as teams like PyPy and Unladen Swallow are working on improving Python 2.6 and not Python3k.
- eru 17y ago> extra vital features (like improvement of inline functions (lambda)) I would not consider this a vital feature. You can already nest arbitrary functions, you just have to name them. However Tail-Call-Optimization would be a vital feature. (Alas, it's not going to happen.)
- masklinn 17y agoI'm pretty sure the improvement he was talking about is "full" anonymous functions (w/ multiple statements & everything).
- scott_s 17y agoAnd I'm pretty sure eru understood that, which is why he pointed out you can achieve the same functionality by naming them.
- eru 17y agoYes. And if you want multiple statements, you are either doing site-effects (evil) or using variables inside your closure, so you might as well name it, too.
- masklinn 17y ago> you are either doing site-effects (evil) Uh not necessarily, and even if you are there are many situations where it's interesting and useful. > or using variables inside your closure, so you might as well name it, too Does not follow.
- jnoller 17y agoHow about this one: 2.x is dead. While bug fixes and minor changes are occuring, it's going to slip into maintenance mode once 2.7 comes out. All the cool things, such as importlib and other items are py3k only.
- amix 17y agoHow is 2.x dead? Everyone in the Python community is using and developing for 2.x. If you develop for Py3k, then you loose backward compatibility and you can't use upcoming optimizations like Unladen Swallow. I think Python might end up in a situation like PHP4 and PHP5 - where tons of people still use PHP4, even if PHP5 holds tons of improvements and is around 5 years old. Breaking backward compatibility to fix some essential things is an ok move, but I think it's only going to work if Python3k has a much better offering than it currently has.
- scott_s 17y agoIt's not a language, but look at the Linux kernel. The jump from 2.4 to 2.6 was significant - programs that took advantage of some of the added support in 2.6 couldn't run on 2.4 kernels. 2.4 was maintained because many people used it, but eventually all new development started occurring in 2.6 Now 2.6 is the default. I hope Python will go through the same process. It's not that Python 2.x is dead, but that we've scheduled its retirement.
- masklinn 17y ago> programs that took advantage of some of the added support in 2.6 couldn't run on 2.4 kernels. yeah but programs which ran on 2.4 kernels still run on 2.6 right? So the situation is totally different.
- scott_s 17y ago"Totally different," no. Not exactly the same, yes. Similar enough to make a meaningful comparison? I think so.
- 17y ago
- masklinn 17y ago> This article indicates that it may be preferable to the alternative... No. Python 3.0 was never expected to see widespread adoption, nor was it expected that libraries be ported to it. Ever. Python 3.1 is expected to have a better adoption rate, and library porting to start in earnest during its time and even more with Python 3.2 next year, especially with tools such as 3to2 appearing. Everything is going according to the plan, and this plan is the reason why 3.1 was released less than 7 months after 3.0 (3.2 will probably be released early next year, putting barely a year between 3.0 and 3.2). That's also why 2.7 is in the works (and was already planned before the 2.6/3.0 releases), and there might even be a 2.8 (though that's unlikely). edit: when you get down to it, those claiming Python 3 has failed are either morons or FUD-spreader, Fox-style. I'm not saying Python 3 has succeeded, but we won't know whether or not it has failed before the end of 2010 at the earliest. Right now, everything's going according to the plan. Please remember the planning for Python 3000 started for real during the 2003 State of the Python Union. Meanwhile the release of Python 3.0 was in december 2008.