As a peripheral observer and user of Scala, I feel like it gets a lot of things right if you want to use it as a "better Java". But that doesn't mean it's particularly usable as a "better Java"; obviously reasonable people can disagree but personally I find it uncomfortable to write Scala code for too long. It feels like it leads to awkward structures (blocks within blocks within blocks, hard-to-follow but oh-so-functional transforms) and an odd sort of terseness that reminds me of Python (not a compliment, I find Python irritating to read even though I like a lot of the ways it does stuff). It's like there's so much stuff there that it encourages you to be way too clever. "Too clever" is a thing and a bad one; somebody (maybe even you) has to puzzle out your cleverness later.
I do find cases where the language actually does cause problems, though. There appears to be three main groups involved with Scala: PL academics, "better Java" people, and "why isn't it Haskell?" people. The last group is, to me, rather frustrating, because it's the group that gets up in arms at the idea of a 'for' statement in the language. (The standard method of iteration is a foreach method over a collection and it is insanely slow; people resort to writing while loops because the foreach construct is so laughably slow. Why am I faking a for loop in such a "modern" language?) There are a few areas like this where practicality has apparently lost out to zealotry and it makes the language feel vaguely hostile to somebody who already Does The Right Thing in Java (immutable-by-default, dependency injection rather than creation, etc. etc.). As silly as it may sound, when I'm writing Scala I don't feel welcome in my own code--and I've been using Scala off and on for a couple of years, it's not just fear of the unknown.
I'm actually really looking forward to Kotlin (and Ceylon, to a lesser extent) because it's a language with a focus. JetBrains knows where they want to go with it instead of just dumping a box of stuff on your lawn and telling you to piece together what might or might not actually be what you want. The comparison always reminds me of The Big Lebowski: "Say what you want about the tenets of National Socialism, dude, but at least it's an ethos!"
no, in 2.9 using a 1 to 10 generator and a foreach was slower than using one using primitives due to the boxing. This is fixed in trunk.
> gets up in arms at the idea of a 'for' statement in the language
Scala's for is an expression, you can use it as a statement by not yielding anything if you want. Scala's for is extraordinarily versatile, basically allowing you to work within any monadic context (where a monadic context is some container that implements map/flatMap and some other optional methods.
These "I can't believe its not Haskell" people tend to want to stay with the realm of FP, which is a very useful place to be. Minimising and tracking side-effects and having more expressive and useful types makes more composable software. This is not at all academic, it is an entirely practical result. It does however require you to rethink your approach to writing code, and it really helps to learn a few seemingly difficult things like the typeclassopedia (Monads, Monoids, Functors, Applicatives etc).
Personally I find that the Scala community is generally consolidating around functional approaches, and that this is a very good thing. It is a step beyond a "better Java" and is perhaps more initially intimidating, but it is definitely worth the effort.
no, in 2.9 using a 1 to 10 generator and a foreach was slower than using one using primitives due to the boxing. This is fixed in trunk.
Last I checked (and this may be stale because I've basically given up on Scala except in trying to get the Play Framework to not suck, high-performance code isn't really necessary where I'm using Scala now), foreach over a collection emitted very ugly bytecode that was notably slower than a while loop using Java ArrayList<T>.get(). I'm not aware of that having changed, but I could be wrong.
.
These "I can't believe its not Haskell" people tend to want to stay with the realm of FP, which is a very useful place to be. Minimising and tracking side-effects and having more expressive and useful types makes more composable software. This is not at all academic, it is an entirely practical result. It does however require you to rethink your approach to writing code, and it really helps to learn a few seemingly difficult things like the typeclassopedia (Monads, Monoids, Functors, Applicatives etc).
Thank you very much for the lecture you decided I needed, but as it happens I am a teensy bit familiar with the concepts of functional programming. The more pure forms of it are uninteresting to me except as intellectual exercises. There are very valuable lessons to be learned from FP, but I do not find, and have not found, the pure-FP approach to be the panacea of which it is generally claimed. In particular, the loud noises of the pure-FP crowd about scary side-effects has generally been mystifying to me because it really is not a problem I generally encounter in the code I write now. While it may strain your credulity, somehow this half-blind OOP-using simpleton manages to cobble together comfortably composable code with the meager tools available to him and, perhaps even more shockingly, it doesn't involve one single line of XML. =)
I would agree in a heartbeat that I am a better programmer overall because I have been exposed to functional languages. Obviously, many of the lessons from functional languages lend themselves beneficially to procedural/OO programming: immutability (for obvious reasons), function composition (Haskell's functor laws, as simple as they may be to a FP devotee, are something that often come to mind while I'm designing an API because so many implementations don't compose cleanly!), and careful choice of when and where to exercise side effects (which are, really, the interesting part of 99% of code). But I find the "let's make Scala into Haskell" people way, way overboard (I don't find the morass of monads and applicatives to be doing anything useful) and I generally find their style of programming aesthetically displeasing.
Please don't misunderstand me--the "functional people" are welcome to do whatever they'd like, of course, and I wouldn't tell them to write code the way I choose to! But the post I was responding to was under the "Scala is a better Java" impession, and I think this definitely qualifies as a reason that's not true.
.
Personally I find that the Scala community is generally consolidating around functional approaches, and that this is a very good thing.
I'm glad for you. Different strokes for different folks. And if they want to do that, cool. I've made my peace with that and am sort of hanging my hat on Kotlin and Ceylon as the next place to go from here.
.
It is a step beyond a "better Java" and is perhaps more initially intimidating, but it is definitely worth the effort.
There's no "definitely" about it and while I don't mean to pick on you, that sort of zealotry is exactly why I personally think Scala's future is being that guy in the corner complaining about how crude and unenlightened everyone else is and why aren't they using this thing I like?
I would totally agree with the idea that it is worth knowing a functional programming language or two so you can make a reasoned judgment about where to apply functional principles to all of your code. I would never agree with the idea that it is "definitely worth the effort" to use them in all cases because it's silly on its face. For me, going whole-hog on FP isn't worth a thing because it makes me much slower (and this didn't improve with practice), leads me to write code that I have a lot of trouble maintaining later, and leads me to write code I come to despise because the end result is code that I personally and subjectively find really fugly. So, for me, it's not worth the effort. I know, because I've tried it and found it wanting.
To be honest, I'm a little bit frowny that you'd evangelize it so dogmatically without pausing to think that maybe the person you're talking to does know a thing or two (the automatic assumption that disliking the FP zealots means I don't know anything about it is...interesting) and that it doesn't seem like you've considered the possibility that it isn't all-encompassingly wonderful for everything.
As a peripheral observer and user of Scala, I feel like it gets a lot of things right if you want to use it as a "better Java". But that doesn't mean it's particularly usable as a "better Java"; obviously reasonable people can disagree but personally I find it uncomfortable to write Scala code for too long. It feels like it leads to awkward structures (blocks within blocks within blocks, hard-to-follow but oh-so-functional transforms) and an odd sort of terseness that reminds me of Python (not a compliment, I find Python irritating to read even though I like a lot of the ways it does stuff). It's like there's so much stuff there that it encourages you to be way too clever. "Too clever" is a thing and a bad one; somebody (maybe even you) has to puzzle out your cleverness later.
I do find cases where the language actually does cause problems, though. There appears to be three main groups involved with Scala: PL academics, "better Java" people, and "why isn't it Haskell?" people. The last group is, to me, rather frustrating, because it's the group that gets up in arms at the idea of a 'for' statement in the language. (The standard method of iteration is a foreach method over a collection and it is insanely slow; people resort to writing while loops because the foreach construct is so laughably slow. Why am I faking a for loop in such a "modern" language?) There are a few areas like this where practicality has apparently lost out to zealotry and it makes the language feel vaguely hostile to somebody who already Does The Right Thing in Java (immutable-by-default, dependency injection rather than creation, etc. etc.). As silly as it may sound, when I'm writing Scala I don't feel welcome in my own code--and I've been using Scala off and on for a couple of years, it's not just fear of the unknown.
I'm actually really looking forward to Kotlin (and Ceylon, to a lesser extent) because it's a language with a focus. JetBrains knows where they want to go with it instead of just dumping a box of stuff on your lawn and telling you to piece together what might or might not actually be what you want. The comparison always reminds me of The Big Lebowski: "Say what you want about the tenets of National Socialism, dude, but at least it's an ethos!"