3 ms·

From the article: > This self-limiting process means that Scala will never truly die out; at any point, there are still more people who are new to Scala than p

From the article: > This self-limiting process means that Scala will never truly die out; at any point, there are still more people who are new to Scala than people who have been burnt by it, so there’s always a fresh supply of people willing to believe that it can’t happen to them. The same is true of smokers, of course. If that's not inflammatory for the sake of it I don't know what is. > And no, 2.10.x and 2.10.y being compatible isn't something to crow about; it should have been the default. The moving of the of the goalposts isn't helping your case that your not being inflammatory for the sake of it. Few people are going to state that Scala doesn't have any problems. However, if you want to raise issues about the language, at least argue fairly and don't insult the users and developers of said language in the process.

alblue 13y ago
I spent a long time trying to get the issue raised back in 2009. http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-requirements.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-req... Key to both of these was 'real' backward compatibility (i.e. the compatibility between versions like 2.8 and 2.9, not the patch level compatibility that exists at the moment). I'm not moving the goalposts here; the issue is that having 2.8.x compatible with 2.9.y (or 2.9.x with 2.10.y etc) is a key point where Scala has failed, and continues to fail. Until this is fixed, Scala won't be enterprise ready. Rod's point (from his Scala days keynote) is that in 5 years Scala has a chance of being 'the' language, but only if it gets the backward compatibility issues sorted between 2.x and 2.x+1. My point was I made exactly the same argument almost 5 years ago and nothing has changed, and since the past is the best predictor of future performance it is a safe bet that in 5 years time Scala won't have solved that problem, and thus won't be applicable for large enterprises. This isn't a rant against users of Scala, it's a critique of the development plans that doesn't see this is a problem, or is happy to use Scala as an experimental playground that isn't likely to get widespread usage in enterprise. If you can fit all your organisation's development teams in a single conference room, these problems are never going to apply to you, since you can just mandate that everyone switches at a particular date. But for organisations with hundreds or thousands of developers such an all-in-one switch isn't feasible.

alblue 13y ago

I spent a long time trying to get the issue raised back in 2009. http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/08/modularity-for-scala.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-requirements.html http://alblue.bandlem.com/2009/09/draft-scala-modularity-req... Key to both of these was 'real' backward compatibility (i.e. the compatibility between versions like 2.8 and 2.9, not the patch level compatibility that exists at the moment). I'm not moving the goalposts here; the issue is that having 2.8.x compatible with 2.9.y (or 2.9.x with 2.10.y etc) is a key point where Scala has failed, and continues to fail. Until this is fixed, Scala won't be enterprise ready. Rod's point (from his Scala days keynote) is that in 5 years Scala has a chance of being 'the' language, but only if it gets the backward compatibility issues sorted between 2.x and 2.x+1. My point was I made exactly the same argument almost 5 years ago and nothing has changed, and since the past is the best predictor of future performance it is a safe bet that in 5 years time Scala won't have solved that problem, and thus won't be applicable for large enterprises. This isn't a rant against users of Scala, it's a critique of the development plans that doesn't see this is a problem, or is happy to use Scala as an experimental playground that isn't likely to get widespread usage in enterprise. If you can fit all your organisation's development teams in a single conference room, these problems are never going to apply to you, since you can just mandate that everyone switches at a particular date. But for organisations with hundreds or thousands of developers such an all-in-one switch isn't feasible.