> Whenever somebody quotes growth numbers instead of absolute numbers, they are trying to hide something.
No, it is the data you asked us to look at and it refutes your claim that "they are as insignificant today as they were five years ago". They are _less_ insignificant. They may still be several orders of magnitude lower, but your claim is still incorrect.
Just take absolute numbers: According to indeed, there are over 1000 open jobs mentioning Scala in the US, and over 750 in the UK. Taken together, the number of open Scala jobs in both countries exceeds the number of open Groovy jobs. It's still small compared to Java jobs (to be precise 1.5% in the US, close to 3% in the UK), but Java is by far the most demanded language, so this is not surprising. To say there is no pick-up in adoption of functional languages is disingenuous, IMO.
And most of those job ads mentioning "Groovy" are for using groovy as an add-on to Java, while those mentioning "Scala" are usually for using Scala as the primary language.
And, I should add, given this level of demand it's a good thing we just finished the Scala massive open online class with more than 10'000 developers completing the course with success.
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.
Being in Aus we don't get to see many live and rely on the videos being made available. Of those I particularly liked Daniel Spiewak's "Extreme Cleverness: Functional Data Structures" and Rich Hickey's "Simple Made Easy".
We were fortunate enough though to have the excellent YOW conference with many excellent talks, particular stand-outs coming from Simon Peyton-Jones and Mike Lee, but the absolute best talk (not necessarily the best tech, it is Perl after all) was Damian Conway's flabbergasting "Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces...Made Easy!"[1]
