In Defense of Scala. Response to “I Don’t Like Scala”(blog.gridgainsystems.com)
blog.gridgainsystems.com
In Defense of Scala. Response to “I Don’t Like Scala”
http://blog.gridgainsystems.com/in-defense-of-scala-response-to-i-dont-like-scala/
13 comments
Edward Kmett is a Haskell evangelist (not to mention absurdly productive engineer) so it's natural for him to point out the inconsistencies in Scala, inconsistencies that the average programmer will never even realize exist.
He ends his semi-rant with a concession: there's a lot of good in Scala, and that's absolutely true, there is _so much good_ in Scala that only when you leave it's confines do you realize, shit, I miss:
Ok, compile times and IDE support leave something to be desired, but things have improved by leaps and bounds in the past 3 years, and more goodness to come with Scala 2.11 in (hopefully) March.
He ends his semi-rant with a concession: there's a lot of good in Scala, and that's absolutely true, there is _so much good_ in Scala that only when you leave it's confines do you realize, shit, I miss:
immutability
lazy vals
case classes
pattern matching
named parameters
implicits
import aliases
partial functions
Option, Either (wish latter was biased)
map/flatMap/fold & collections FP friends
Ok, compile times and IDE support leave something to be desired, but things have improved by leaps and bounds in the past 3 years, and more goodness to come with Scala 2.11 in (hopefully) March.
>Edward Kmett is a Haskell evangelist
Really? Could you point me to some of his evangelizing? Or did you mean "he uses haskell and is quite happy with it"? Because that isn't the same thing.
>inconsistencies that the average programmer will never even realize exist.
Do you honestly believe that? http://www.youtube.com/watch?v=TS1lpKBMkgg
>Scala that only when you leave it's confines do you realize, shit, I miss
But the very point Edward makes is that you don't give up those things when you leave scala. You only give up those things if you leave scala for something worse. You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
Really? Could you point me to some of his evangelizing? Or did you mean "he uses haskell and is quite happy with it"? Because that isn't the same thing.
>inconsistencies that the average programmer will never even realize exist.
Do you honestly believe that? http://www.youtube.com/watch?v=TS1lpKBMkgg
>Scala that only when you leave it's confines do you realize, shit, I miss
But the very point Edward makes is that you don't give up those things when you leave scala. You only give up those things if you leave scala for something worse. You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
There's nothing wrong with language evangelism, if you love the language you work in you'll evangelize it without even thinking about it.
Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete. At any rate he does mention in one his videos (maybe on www.haskellcast.com) that he is coding less now due to his new obligations, which includes [completely from fallible memory] promoting [read: evangelizing] the language.
>inconsistencies that the average programmer will never even realize exist.
Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO. When you leave the JVM, then yes, you can dive into Haskell and experience (compared to Scala) longer compile times, yelp o_O, poor to non-existent (IDE) tooling (just type :t in the REPL to see the inferred type, AKA beginner's joy), lack of an enterprise ecosystem, and yes, purity in all its glory, with a superior type system and quite a friendly community of mostly brilliant minds.
In the end I'd say there's some degree of PITA everywhere, even in Haskell. Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete. At any rate he does mention in one his videos (maybe on www.haskellcast.com) that he is coding less now due to his new obligations, which includes [completely from fallible memory] promoting [read: evangelizing] the language.
>inconsistencies that the average programmer will never even realize exist.
Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO. When you leave the JVM, then yes, you can dive into Haskell and experience (compared to Scala) longer compile times, yelp o_O, poor to non-existent (IDE) tooling (just type :t in the REPL to see the inferred type, AKA beginner's joy), lack of an enterprise ecosystem, and yes, purity in all its glory, with a superior type system and quite a friendly community of mostly brilliant minds.
In the end I'd say there's some degree of PITA everywhere, even in Haskell. Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
>There's nothing wrong with language evangelism
He says, after suggesting you can't trust what someone says because they are an evangelist.
>Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete
FP complete is an independent company and has no official involvement in GHC or any other haskell implementation. Edward is not involved with FP complete. Edward is involved in the haskell community and the scala community. In neither case is he anything like an evangelist (which would make no sense anyways, you can't convert the converted). It seems odd that you are so adamant about inventing a fictional promotional context for him after claiming there's nothing wrong with that.
>Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
Perhaps you should actually take the time to listen to it. A significant part of what he was saying was "this stuff matters". Just because the person doing the presentation knows scala very well, does not mean the problems he points out do not effect people who know scala less well.
>When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO
I am not sure how that is relevant. I don't care about the JVM.
>Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
He says, after suggesting you can't trust what someone says because they are an evangelist.
>Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete
FP complete is an independent company and has no official involvement in GHC or any other haskell implementation. Edward is not involved with FP complete. Edward is involved in the haskell community and the scala community. In neither case is he anything like an evangelist (which would make no sense anyways, you can't convert the converted). It seems odd that you are so adamant about inventing a fictional promotional context for him after claiming there's nothing wrong with that.
>Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
Perhaps you should actually take the time to listen to it. A significant part of what he was saying was "this stuff matters". Just because the person doing the presentation knows scala very well, does not mean the problems he points out do not effect people who know scala less well.
>When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO
I am not sure how that is relevant. I don't care about the JVM.
>Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
> He says, after suggesting you can't trust what someone says because they are an evangelist.
What the hell are you talking about? I provided a counterpoint to Kmett's detailing all that is wrong with Scala, by providing some of the good. Kmett is a living legend, I'm not questioning the guy's integrity; he went off in that reddit thread based on his [deep] experience of the language, which is entirely non-average.
re: Paul Phillips, he's knows Scala probably better than anyone else on the planet; yes, the soundness of the compiler affects everyone, but those who are most bitten and bothered by it are library authors (read: advanced users), not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
> Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
> You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
That sounds great! I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
What the hell are you talking about? I provided a counterpoint to Kmett's detailing all that is wrong with Scala, by providing some of the good. Kmett is a living legend, I'm not questioning the guy's integrity; he went off in that reddit thread based on his [deep] experience of the language, which is entirely non-average.
re: Paul Phillips, he's knows Scala probably better than anyone else on the planet; yes, the soundness of the compiler affects everyone, but those who are most bitten and bothered by it are library authors (read: advanced users), not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
> Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
> You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
That sounds great! I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
Hi virtualwhys
> I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
With apologies if you think this is too OT and/or if you are uninterested in immature languages/ecosystems, let me mention Rakudo and its increasingly capable JVM backend.
Today's Rakudo Star release (Star means "batteries included") is expected to be the last to ship without Rakudo's JVM backend. Almost certainly there'll be a February Rakudo Star release and it is expected to support the JVM backend out of the box.
I would be happy to say more about why I think P6 is going to become relevant again one day, perhaps this year, to folk at least interested in Scala.
> I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
With apologies if you think this is too OT and/or if you are uninterested in immature languages/ecosystems, let me mention Rakudo and its increasingly capable JVM backend.
Today's Rakudo Star release (Star means "batteries included") is expected to be the last to ship without Rakudo's JVM backend. Almost certainly there'll be a February Rakudo Star release and it is expected to support the JVM backend out of the box.
I would be happy to say more about why I think P6 is going to become relevant again one day, perhaps this year, to folk at least interested in Scala.
>What the hell are you talking about?
Exactly what I said. You can go read your post if you have forgotten its contents.
>not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
You are simply repeating yourself. Paul Phillips contradicts you, and I find him to be much more credible.
>Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
Ocaml, F#, SML and clean.
>please name this better alternative that is presumably not Haskell.
Why would it not be haskell? Haskell is pretty obviously the best option.
Exactly what I said. You can go read your post if you have forgotten its contents.
>not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
You are simply repeating yourself. Paul Phillips contradicts you, and I find him to be much more credible.
>Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
Ocaml, F#, SML and clean.
>please name this better alternative that is presumably not Haskell.
Why would it not be haskell? Haskell is pretty obviously the best option.
I have high hopes for Ermine, but it's not (yet) a real alternative to Scala; it doesn't have anything like the maturity, tool support, or library ecosystem. Which is to be expected - it's barely a year old, whereas Scala has been with us for ten years.
Scala is far from perfect, to be sure; even ten years in the future I'd expect/hope there will be a better option, whether that's Ceylon, Fantom, Ermine or something else. But right now Scala is in the sweet spot: it's a huge step up from most popular languages, and at the same time it's mature, popular, and java-compatible enough to be a practical choice for many projects.
And as someone who does FP in Scala all the time, I'd be interested to hear what you're talking about with your "pretty strong image".
(Also I think Scala's @implicitNotFound covers the interesting cases for customizable type error messages, no?)
Scala is far from perfect, to be sure; even ten years in the future I'd expect/hope there will be a better option, whether that's Ceylon, Fantom, Ermine or something else. But right now Scala is in the sweet spot: it's a huge step up from most popular languages, and at the same time it's mature, popular, and java-compatible enough to be a practical choice for many projects.
And as someone who does FP in Scala all the time, I'd be interested to hear what you're talking about with your "pretty strong image".
(Also I think Scala's @implicitNotFound covers the interesting cases for customizable type error messages, no?)
I agree with just about everything you've said. In fact I just published this blog post that makes the same point (right at the end) http://underscoreconsulting.com/blog/posts/2014/01/29/unboxe...
The reason most people use Scala is because of JVM support and Java interop. Those are exactly the reasons that typeful programming can be a pain in Scala. Multi-arg functions don't compose as easily as curried functions. No TCO. Subtyping breaks extensive type inference. The JVM is Scala's blessing and its curse. I wish more people realised this. It would save us from a lot of frothing-at-the-mouth blog posts, if nothing else.
The reason most people use Scala is because of JVM support and Java interop. Those are exactly the reasons that typeful programming can be a pain in Scala. Multi-arg functions don't compose as easily as curried functions. No TCO. Subtyping breaks extensive type inference. The JVM is Scala's blessing and its curse. I wish more people realised this. It would save us from a lot of frothing-at-the-mouth blog posts, if nothing else.
I also agree with all of that. Scala is an ugly incomplete attempt at replicating Haskell on the JVM that fails at being Haskell, and also fails at being Java, it's the worst of both worlds. On a semi-related note have you taken a look at Ceylon? I found out about the language a few months back and I really like it. It isn't Haskell by any means, but for a JVM based language it's one of the most Haskell-ish feeling languages I've found. The type system in particular reminds me a lot of the Haskell type system.
Dude cmon seriously, you find ceylon closer to haskell than Scala? I must have read about another ceylon then.
Scala tries to be Haskell but does so badly. Ceylon isn't trying to be Haskell, but the type system feels very Haskell-ish.
It isn't functional, but that's fine, it's based on the JVM after all so things like tail-call optimization are going to be tough anyway. It has non-nullable by default variables. It supports immutable data (and encourages you to use it as much as possible). The way you instantiate an instance of an object is very much like the way types are instantiated in Haskell. It has mixin inheritance which is very similar to an OO version of the class system in Haskell.
In other words, it isn't Haskell, isn't trying to be Haskell, and isn't functional, but it does have a lot of the things I love from Haskell, and it feels very elegant to boot. Scala I feel is what happens when you literally try to copy chunks of Haskell on top of Java, and it's a mess. Ceylon I think is what happens when you take the best features of Haskell, and where it makes sense to do so apply them to a traditional OO system.
I'd still rather do something in Haskell, but if I absolutely must use a JVM based language, I think Ceylon is a very strong contender that would make a lot of people who are familiar with Haskell feel right at home.
It isn't functional, but that's fine, it's based on the JVM after all so things like tail-call optimization are going to be tough anyway. It has non-nullable by default variables. It supports immutable data (and encourages you to use it as much as possible). The way you instantiate an instance of an object is very much like the way types are instantiated in Haskell. It has mixin inheritance which is very similar to an OO version of the class system in Haskell.
In other words, it isn't Haskell, isn't trying to be Haskell, and isn't functional, but it does have a lot of the things I love from Haskell, and it feels very elegant to boot. Scala I feel is what happens when you literally try to copy chunks of Haskell on top of Java, and it's a mess. Ceylon I think is what happens when you take the best features of Haskell, and where it makes sense to do so apply them to a traditional OO system.
I'd still rather do something in Haskell, but if I absolutely must use a JVM based language, I think Ceylon is a very strong contender that would make a lot of people who are familiar with Haskell feel right at home.
> Scala tries to be Haskell but does so badly.
No, it doesn't try to be Haskell. It tries to be something very different from Haskell which happens to share some features with Haskell.
You, presumably, don't like what it actually tries to be, and that's fine, but its just incorrect to say that it is trying to be Haskell but doing it poorly.
No, it doesn't try to be Haskell. It tries to be something very different from Haskell which happens to share some features with Haskell.
You, presumably, don't like what it actually tries to be, and that's fine, but its just incorrect to say that it is trying to be Haskell but doing it poorly.
This comment is so confused, that it's getting funny again.
I don't necessarily agree with everything you said - I don't know enough about Scala to have a good opinion - but I absolutely agree with your first paragraph.
"For sane type-level programming look at latest Scala collections"
Is this a joke? The Scala collections library are terrible. They are inconsistent, hard to reason about, suffer from scope creep, and have terrible performance characteristics.
Is this a joke? The Scala collections library are terrible. They are inconsistent, hard to reason about, suffer from scope creep, and have terrible performance characteristics.
Every time I've used Scala collections, they've behaved exactly how I'd expect them to. What parts of the collections perform poorly?
The scala collections (even the mutable ones) generate tons of garbage (e.g. getting a value out of a map automatically creates another new object). Scala hashmaps (even the mutable ones) are much slower than equivalent java collections.
A recent comparison was made with scala and java collections. Lots of interesting tidbits. http://www.takipioncode.com/2014/01/23/java-scala-guava-and-...
It seems that the performance difference has little to do with temporary objects, but is to be fixed 2.11 anyway:
https://groups.google.com/forum/#!msg/scala-internals/Fw37Nm...
> getting a value out of a map automatically creates another new object
Do you have a code sample for this?
Do you have a code sample for this?
From MapLike.scala
def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }
From HashMap.scala
def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }
From HashMap.scala
def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
Out of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.
Not sure how familiar you are with the Scala syntax, but that code actually has null pointer problems. The apply function turns Options into null pointers. They've given me the worst of both worlds, not only do I get null pointers, I get to have extra garbage created to accomplish it.
Yep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?
I actually have no problem with the extra allocations if they maintain safety (that's not quite true, I actually need to break safety occasionally).
The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for.
If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE.
Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming.
PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for.
If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE.
Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming.
PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
Makes sense, thanks for your answer :)
I hate to call you out on this but look at the collection hierarchy and tell me its not complex.
http://docs.scala-lang.org/resources/images/collections.muta...
http://docs.scala-lang.org/resources/images/collections.muta...
Doesn't look very different from the equivalent diagram for Java. Have you seen how many different collection classes and interfaces there are in the Java standard libs?
AbstractCollection
AbstractList
AbstractMap
AbstractMap.SimpleEntry
AbstractMap.SimpleImmutableEntry
AbstractQueue
AbstractSequentialList
AbstractSet
ArrayDeque
ArrayList
Arrays
BitSet
Collections
Dictionary
EnumMap
EnumSet
HashMap
HashSet
Hashtable
IdentityHashMap
LinkedHashMap
LinkedHashSet
LinkedList
PriorityQueue
Stack
TreeMap
TreeSet
Vector
WeakHashMap
ArrayBlockingQueue
ConcurrentHashMap
ConcurrentLinkedDeque
ConcurrentLinkedQueue
ConcurrentSkipListMap
ConcurrentSkipListSet
CopyOnWriteArrayList
CopyOnWriteArraySet
DelayQueue
LinkedBlockingDeque
LinkedBlockingQueue
LinkedTransferQueue
PriorityBlockingQueue
SynchronousQueue
BlockingDeque
BlockingQueue
ConcurrentMap
ConcurrentNavigableMap
TransferQueue
Collection
Deque
Iterator
List
ListIterator
Map
Map.Entry
NavigableMap
NavigableSet
Queue
RandomAccess
Set
SortedMap
SortedSet
I looked at it and understood it in a few seconds. What about it do you find complex? It looks like a well organized api to be honest.
What is wrong with that? There are three core data structure types (maps, sets, sequences), and variants of those depending on need. Most of these are standard data structures you would find in an undergrad textbook.
That is just the "published" hierarchy as well. Paul Phillips likes to pick on the ParSeqViewLike trait, and if you ever find yourself delving into it, you'll see why.
As someone who actually writes production code in Scala on a daily basis Paul Pillips' "concerns" have had zero practical impact on my daily use of the language. I tried to find content in his presentations that actually had any impact on me but I couldn't.
As someone who also writes production code in Scala on a daily basis, and who took exception to the idea that the Scala collections library was a good example of type programming, Paul Phillips' concerns are spot on.
If you are using the collections library as example of how to structure your own code, you are in for a bad time. The abstractions are not right, and things like the silly ParSeqViewLike trait are an expression of that.
If you are using the collections library as example of how to structure your own code, you are in for a bad time. The abstractions are not right, and things like the silly ParSeqViewLike trait are an expression of that.
In day-to-day use I haven't run into any of these issues. Your mileage may vary.
"Brilliantly simple" is an odd description of Scala. I would easily put Scala in the top 3 most-difficult-languages-for-me to work with. Maybe even top 2.
I had my first experience for Scala last week with doing the Stripe CTF.
I really liked the look of the language and I started trying to develop my solution in it. I knew exactly what I wanted to do, and had a reasonable idea of what to write to get there.
Holly molly, compilation times were absolutely horrible. I tried to persevere but a tiny change would mean 2 minutes waiting for a recompile. In the end I just switched to python where I could develop a solution from scratch (remember, the Scala solution was 90% finished) in no time at all.
Would like to look closer at the language one day but I have better things to do with time than waiting for a machine to churn through code.
I really liked the look of the language and I started trying to develop my solution in it. I knew exactly what I wanted to do, and had a reasonable idea of what to write to get there.
Holly molly, compilation times were absolutely horrible. I tried to persevere but a tiny change would mean 2 minutes waiting for a recompile. In the end I just switched to python where I could develop a solution from scratch (remember, the Scala solution was 90% finished) in no time at all.
Would like to look closer at the language one day but I have better things to do with time than waiting for a machine to churn through code.
Use incremental compilation during development, and keep your files small (this is a good idea anyway). If you're coming at it from a python background were you working in the command line? A lot of the benefits of scala only really apply when using it in an IDE.
> I tried to persevere but a tiny change would mean 2 minutes waiting for a recompile
incremental compilation: sbt> ~run
in most cases code changes should take one second. Note: SBT sub projects are God's gift to Scala devs (or Mark Harrah's gift at any rate).
You have to get your feet wet in the language, trying something last week for a day or two is not going to result in you flying to the moon on the productivity spaceship of delight.
Programming in Scala 2nd edition is a great intro to the language.
incremental compilation: sbt> ~run
in most cases code changes should take one second. Note: SBT sub projects are God's gift to Scala devs (or Mark Harrah's gift at any rate).
You have to get your feet wet in the language, trying something last week for a day or two is not going to result in you flying to the moon on the productivity spaceship of delight.
Programming in Scala 2nd edition is a great intro to the language.
Ok. Sounds like there's a solution so I'll try again at some point. There was a build.sh with the project that I was using. I saw something about sbt in there so had a look on their website but couldn't obviously see how to fix the issue.
Play framework's a decent gateway drug to Scala, can help you get some of the basics under your belt while seeing tangible results.
Otherwise, a book or 2 on Scala goes a long way.
Otherwise, a book or 2 on Scala goes a long way.
I guess you were having some troubles and asked around in #scala. A huge amount of work in Scala is left for the compiler, all the niceties and features put that load on it. So while it makes life a lot more easier for you it also has more work to do. Anyways compile times have improved significantly in Scala 2.11 but more importantly, incremental compilation has landed.
I've used Scala for a few years now. The blog post doesn't do a particularly good job of selling Scala despite the best intentions. I would encourage anyone who is interested in Scala to spend some time learning the language and using it, rather than worrying about occasional misdirected criticism which the blog seeks to counter.
I've found Scala to be very expressive and well suited to large-scale systems. It takes some effort to learn the language, but once you have put in the effort coding in Scala is a pleasure (esp. compared to Java).
I've found Scala to be very expressive and well suited to large-scale systems. It takes some effort to learn the language, but once you have put in the effort coding in Scala is a pleasure (esp. compared to Java).
"intellectual laziness of dynamically typed languages"
What a claim! What an absurdity!
Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript, etc...) enable styles of programming impossible in non-dynamically checked languages. So it certainly isn't the users who are being "intellectually lazy." Nor are the creators, who have focused on productivity and usability instead of waiting for proof systems (static type checkers) to catch up with their ideas. Laziness doesn't factor in on either side.
What a claim! What an absurdity!
Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript, etc...) enable styles of programming impossible in non-dynamically checked languages. So it certainly isn't the users who are being "intellectually lazy." Nor are the creators, who have focused on productivity and usability instead of waiting for proof systems (static type checkers) to catch up with their ideas. Laziness doesn't factor in on either side.
Provide an example where such a style would be deemed useful or superior to doing it the statically checked way.
Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like:
complex_object.to_json
and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)).
It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)).
It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
> Canonical example would be marshelling one type to another, something that typically requires a fair amount of boilerplate in statically typed languages, whereas in Ruby, Grooy et al you just do something like: complex_object.to_json
The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc.
(Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way)
> It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc.
(Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way)
> It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
You're talking about simple 1-to-1 mappings where both db result and case class to json conversion are straightforward.
The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
In Haskell, I can add a single line containing a macro to derive the JSON [de]serialization code.
Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
I have no idea whether or not the implementation is easier is dynamic languages or not. I do know that for the language user it's a simple foo.to_json, end of story.
If you can marshall objects of arbitrary complexity to JSON in Haskell with a single line of code that covers all possible cases (e.g. your entire database model), consider me beyond impressed.
If you can marshall objects of arbitrary complexity to JSON in Haskell with a single line of code that covers all possible cases (e.g. your entire database model), consider me beyond impressed.
It's (toJson foo) on the entire data, however complex, as long as there is a sane way to jsonify it. For example, if the data contains functions, there's no default way to convert it into json.
And also, deserialization is going to be more concise in Haskell because type inference decides which type to deserialize to.
And also, deserialization is going to be more concise in Haskell because type inference decides which type to deserialize to.
That's pretty awesome, sounds ideal for a RESTful API. In Scala I've noticed a tendency toward using NoSQL storage engines like MongoDB, which speaks a form of native JSON (i.e. it removes the BP required to marshall to/from JSON).
A few months ago I took a stroll through available Haskell libraries for web dev., found Yesod, HaskellDB, and a couple of other glue items.
What's the state of the art on the web framework front in Haskell? Snap looks interesting but incomplete, and HaskellDB is fairly ancient (LINQ-to-SQL lib would probably get me very interested in Haskell sooner rather than later). Assume email, PDF generation and other web must-haves exist in Haskell ecosystem.
A few months ago I took a stroll through available Haskell libraries for web dev., found Yesod, HaskellDB, and a couple of other glue items.
What's the state of the art on the web framework front in Haskell? Snap looks interesting but incomplete, and HaskellDB is fairly ancient (LINQ-to-SQL lib would probably get me very interested in Haskell sooner rather than later). Assume email, PDF generation and other web must-haves exist in Haskell ecosystem.
I do a lot of Haskell development, but virtually nil web development.
I know the Yesod ecosystem is well-developed and should have good solutions for most problems. I think the downside of Yesod is that it is not as principled/based-on-sound-theory as most of the Haskell ecosystem is, so it gets a lot of negative sentiment. But it solves a real problem now -- at least until a principled approach is proven.
Yesod also has "persistent", which can persist over SQL and IIUC, nosql DB's as well.
Snap is more minimalist, and solves a smaller part of the problem for you -- but is much simpler (and perhaps more elegant) than Yesod.
Happstack is another web framework, like Yesod (all 3 are under active development). Its main problem (perhaps this was fixed already) was prevalent use of "lazy I/O" which is very controversial. I personally despise lazy I/O and think it violates the basic principles that make Haskell great. I heard something about Happstack immigrating to an alternative to lazy I/O though.
Email is a solved problem in the Haskell ecosystem, as far as I can tell.
PDF libraries exist: http://hackage.haskell.org/packages/#cat:PDF but I haven't used them, so I don't know how good they are.
I don't know about other must-haves. I know an automatic "admin webpage" didn't exist until recently even in the Yesod ecosystem. A friend who encountered this missing piece contributed one, but it was pretty barebones/preliminary. This was a couple years ago though.
I know the Yesod ecosystem is well-developed and should have good solutions for most problems. I think the downside of Yesod is that it is not as principled/based-on-sound-theory as most of the Haskell ecosystem is, so it gets a lot of negative sentiment. But it solves a real problem now -- at least until a principled approach is proven.
Yesod also has "persistent", which can persist over SQL and IIUC, nosql DB's as well.
Snap is more minimalist, and solves a smaller part of the problem for you -- but is much simpler (and perhaps more elegant) than Yesod.
Happstack is another web framework, like Yesod (all 3 are under active development). Its main problem (perhaps this was fixed already) was prevalent use of "lazy I/O" which is very controversial. I personally despise lazy I/O and think it violates the basic principles that make Haskell great. I heard something about Happstack immigrating to an alternative to lazy I/O though.
Email is a solved problem in the Haskell ecosystem, as far as I can tell.
PDF libraries exist: http://hackage.haskell.org/packages/#cat:PDF but I haven't used them, so I don't know how good they are.
I don't know about other must-haves. I know an automatic "admin webpage" didn't exist until recently even in the Yesod ecosystem. A friend who encountered this missing piece contributed one, but it was pretty barebones/preliminary. This was a couple years ago though.
Thanks for the overview, midway through Learn You a Haskell and it's clear I need to sit down and write some code as reading about Haskell is entirely different than reading about Java, Scala, etc. ;-)
In other words, a simple web project is in order. Snap looks like a good call, along with Yesod's Persistent. PDF, email, etc. can come later, just trying to explore the language.
Thanks again.
In other words, a simple web project is in order. Snap looks like a good call, along with Yesod's Persistent. PDF, email, etc. can come later, just trying to explore the language.
Thanks again.
>whereas in Ruby, Grooy et al you just do something like: complex_object.to_json
So, just like you would in a statically typed language like scala or haskell?
So, just like you would in a statically typed language like scala or haskell?
I don't really feel I need to provide you with specific examples, they are already a google away. Try: "python vs java" or "why ruby" or similar. Experiment with programming in these languages and see what type of flexibility you can get, especially during prototyping and initial development phases. Their simplicity is to their benefit when comparing to Scala which brings a lot of overhead to enable static checking of certain constructs. Furthermore, I would bet that you can do things in Python or Ruby that are not possible in Scala (for instance see Armin Ronacher's Euro Python 2013 presentation for some interesting tricks https://ep2013.europython.eu/media/conference/slides/5-years...)
So, basically you have no clue what you are talking about.
>I can't back up my absurd claim with an actual argument, so go google some strawmen for me
Really? How does this kind of shit not get downvoted to oblivion?
Really? How does this kind of shit not get downvoted to oblivion?
1. I did provide a link to a slide deck of examples.
2. This is a well written about issue.
3. I do not consider my claim absurd if I did I would not have made it.
4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
2. This is a well written about issue.
3. I do not consider my claim absurd if I did I would not have made it.
4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
1. The link you provided does not support your absurd claim in any way.
2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect.
3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it.
4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support.
You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.
2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect.
3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it.
4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support.
You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.
Duck typing in dynamic languages can allow you to do some pretty cool things.
The request was for some examples of the claim. You just repeated the claim.
Compared to Java? No question. Compared to Scala with its implicits and associated patterns? I've yet to see a case I couldn't handle in Scala.
[deleted]
An in place and efficient quick sort? :)
Ha! Fair enough, though I was thinking something different in two ways. Namely, something that worked on the common collections used by people and more readable than this. Still, bad example.
That doesn't make sense. The whole point of quicksort's algorithm is to do things in place, which requires fast indexed access and mutability.
Common collections lack both of these things.
Common collections lack both of these things.
It would be nice to have more substantive criticisms. While I dislike SBT[1], scalaz and spray are a large part of why I enjoy scala so much. While akka was so difficult to use that it almost soured me on the whole thing, and shapeless' monstrous compile times made it practically unusable. So don't think this post represents some kind of consensus.
[1] The notion of configuring your build tool in a full programming language is alluring but ultimately a bad idea IMO; builds should be simpler and more declarative than that.
[1] The notion of configuring your build tool in a full programming language is alluring but ultimately a bad idea IMO; builds should be simpler and more declarative than that.
Agreed, I would like to hear more specifics on why spray was so maligned.
Scalaz is a library that I wish I grokked better, but in all I think it has hurt as much readability as it ever hoped to help. That is, learning the concepts I fully want to do. Using the opaque names, not so much. I'd rather have that level of understanding on my target domain, not category theory. (Were I only smart enough to do both...)
I also agree regarding Akka. I want to like it, but I also feel it purposefully makes things complicated. It was hilarious to read the quote from Torvalds saying that "distributed algorithms are really hard" in context of why microkernels are hard to do, and then see Akka basically say that they make it so that all algorithms are written in a distributed way. Or sad. Not sure which.
Scalaz is a library that I wish I grokked better, but in all I think it has hurt as much readability as it ever hoped to help. That is, learning the concepts I fully want to do. Using the opaque names, not so much. I'd rather have that level of understanding on my target domain, not category theory. (Were I only smart enough to do both...)
I also agree regarding Akka. I want to like it, but I also feel it purposefully makes things complicated. It was hilarious to read the quote from Torvalds saying that "distributed algorithms are really hard" in context of why microkernels are hard to do, and then see Akka basically say that they make it so that all algorithms are written in a distributed way. Or sad. Not sure which.
I have found Akka and the actor model to be pretty straight forward, easy to use and understand. I think it makes writing distributed algorithms a breeze (first hand experience). Can you give more details about what you found complicated in it?
Agreed. We run an Akka cluster with 5-6 nodes as our backend, clocking in at 15Kloc. It's been running for months now with no problems. If we need to add capacity, we just provision a new EC2 instance with Vagrant/Chef and it auto-joins the cluster. Once we're done, we can remove it gracefully and the rest of the cluster just deals with it.
Distributed algorithms, in general. :)
Don't get me wrong, if what you are doing is already a distributed algorithm, then it doesn't hurt. But turning all algorithms into distributed algorithms just seems crazy. Unless, I suppose, you don't care about such things as speed and memory consumption.
Don't get me wrong, if what you are doing is already a distributed algorithm, then it doesn't hurt. But turning all algorithms into distributed algorithms just seems crazy. Unless, I suppose, you don't care about such things as speed and memory consumption.
Don't use the wrong tool for the job, it's as simple as that.
On Akka home page, in bold "Build powerful concurrent & distributed applications more easily."
On Akka home page, in bold "Build powerful concurrent & distributed applications more easily."
Maven always had a number of issues -- SBT came along and solved none of them and introduced a few new ones.
I know that I'm in the vast minority, but I don't see what people find difficult about SBT. For the most part, it seems to keep itself out of the way. I would say I've found it only slightly more cumbersome than Rake, and a breath of fresh air when compared to the JVM alternatives (although I haven't had first-hand experience with Leiningen).
If used with discipline it's fine. But it ends up encouraging people to put complex logic in their build files. I prefer the rigidity of maven, where it's simply impossible to do e.g. conditional dependencies.
I can't understand that. Maven is the absolutely worst cluster fuck in terms of a build system I have ever seen.
I can't deal with Maven's position of "Oh, you want to have some tiny bit of intelligence in your build? Guess what, a) fuck you, b) write a crappy plugin for it." anymore after seeing that simple things can be indeed simple and straightforward with SBT.
I can't deal with Maven's position of "Oh, you want to have some tiny bit of intelligence in your build? Guess what, a) fuck you, b) write a crappy plugin for it." anymore after seeing that simple things can be indeed simple and straightforward with SBT.
> If used with discipline it's fine.
I think this is actually an astute criticism of Scala as a language, and not just the SBT library; it holds true for many of its more unconventional features.
Scala is probably not a good language choice if you/your team are prone to shooting themselves in the foot.
I think this is actually an astute criticism of Scala as a language, and not just the SBT library; it holds true for many of its more unconventional features.
Scala is probably not a good language choice if you/your team are prone to shooting themselves in the foot.
I am with you brother, I like SBT. Plain and simple.
The last time I used SBT, which was well over 3 years ago, the SBT file wasn't really valid scala - this may not be the case now.
"intellectual laziness of dynamically typed languages"
Ouch. So if I choose to use python, ruby, javascript, lisp, - I am 'intellectually lazy'?
Ouch. So if I choose to use python, ruby, javascript, lisp, - I am 'intellectually lazy'?
The world was different when those languages were designed; type theory was not as mature as it is today. IMO if you're designing a new language today and not giving it a real type system, yes, that's intellectually lazy.
As for using them... eh. My subjective view is that scala is much better than all those languages, outside certain small domains. But that's not exactly objective fact. I will say that if you don't know scala then you're being intellectually lazy - even compared to ocaml, it's different enough to be worth knowing, and it's a language you'll learn something from, whether you ultimately find yourself using it or not.
As for using them... eh. My subjective view is that scala is much better than all those languages, outside certain small domains. But that's not exactly objective fact. I will say that if you don't know scala then you're being intellectually lazy - even compared to ocaml, it's different enough to be worth knowing, and it's a language you'll learn something from, whether you ultimately find yourself using it or not.
All one has to do to avoid intellectual laziness as a programmer, is to have enough curiosity to constantly re-establish how much one doesn't know. The surprising part is that it might take 10 years to approach an accurate answer.
Also, as you probably know, it's possible to program static typed projects in a Lisp.
Also, as you probably know, it's possible to program static typed projects in a Lisp.
Yes, and this is a feature not a bug. As Larry Wall observed, three cardinal virtues of a good programmer are laziness, impatience and hubris. Laziness is important because I have more things on my to-do list than hours in my lifespan, and more things I need to know than neurons in my brain. I didn't choose Python only or even primarily because it's dynamically typed, but nonetheless, every thought I don't have to think about static types is a thought I can instead think about something I actually care about.
Odd that you cite Larry Wall given that he thinks haskell is one of the most important languages for any programmer to learn. I always find it weird that people try to use someone famous to support their opinion when that famous person disagrees. Perl lacks a type system because that was what made the most sense for perl. That doesn't mean it makes the most sense period.
>every thought I don't have to think about static types is a thought I can instead think about something I actually care about.
Static types do not add something to think about. You already have to think about what things are. Static types just let the compiler ensure that you didn't make any mistakes. Passing a user object into a function that wants a string isn't suddenly useful because there is no type system giving you an error.
>every thought I don't have to think about static types is a thought I can instead think about something I actually care about.
Static types do not add something to think about. You already have to think about what things are. Static types just let the compiler ensure that you didn't make any mistakes. Passing a user object into a function that wants a string isn't suddenly useful because there is no type system giving you an error.
> Perl lacks a type system because that was what made the most sense for perl.
Perl 5 that is. Perl 6 has a (gradual) type system.
Perl 5 that is. Perl 6 has a (gradual) type system.
Ultimately, every language is simply a tool and they all have their issues. I'll admit that I pegged Scala as "C++ for JVM" when it first came out, but am not a hard headed man.
Q to the op is what is the turn over of your dev team? Please provide a defense of Scala in terms of economics of development (from a business pov). Items to address are maintaining the codebase after the whiz kids have left for more exciting pastures.
Q to the op is what is the turn over of your dev team? Please provide a defense of Scala in terms of economics of development (from a business pov). Items to address are maintaining the codebase after the whiz kids have left for more exciting pastures.
Nurturing, retaining and hiring competent developers ... that's probably vastly simpler with Scala than with Java-enterprise-patterns-EJB2 stuff.
"The biggest issue with Scala’s perception is the deeply varying quality of frameworks and tools that significantly affect one’s perception of the Scala language itself"
I've seen the same thing said about Common Lisp.
I've seen the same thing said about Common Lisp.
That's a pretty terrible defense of scala. Sounds more like a "I hate some random scala projects for made up reasons". How does scalaz have "colossal snobbism" exactly? Because it contains stuff you haven't learned?
Agreed, doesn't paint Scala in a good light despite claiming to defend it.
As for Scalaz elitism, the canonical example would be the T-hole himself, _ Morris (who has more or less been expelled from the main Scala user groups). I think the general POV the OP is trying to convey is that Scalaz is an incomprehensible cluster fuck of symbols to everyone but those in the know; in other words, the learning curve is steep and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
SBT suffers a similar problem but that's, IMO, more due to lack of IDE support for the project/ build than anything else (i.e. it's difficult to discover [for me] the library without being able to click through method calls and experientially explore the code [Scala docs only get me so far]).
In other news the last milestone of Scala 2.11 was just released; 2014 should be a good year for Scala on many fronts (faster compilations and improved IDE support particularly)
As for Scalaz elitism, the canonical example would be the T-hole himself, _ Morris (who has more or less been expelled from the main Scala user groups). I think the general POV the OP is trying to convey is that Scalaz is an incomprehensible cluster fuck of symbols to everyone but those in the know; in other words, the learning curve is steep and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
SBT suffers a similar problem but that's, IMO, more due to lack of IDE support for the project/ build than anything else (i.e. it's difficult to discover [for me] the library without being able to click through method calls and experientially explore the code [Scala docs only get me so far]).
In other news the last milestone of Scala 2.11 was just released; 2014 should be a good year for Scala on many fronts (faster compilations and improved IDE support particularly)
> historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
There's a lot of tutorials in Haskell that are papers, but if you go to #haskell or ask on stack overflow, the answer to questions are rarely "go read this paper", at least in my experience (even for some pretty deep type-level programming stuff).
There's a lot of tutorials in Haskell that are papers, but if you go to #haskell or ask on stack overflow, the answer to questions are rarely "go read this paper", at least in my experience (even for some pretty deep type-level programming stuff).
>I think the general POV the OP is trying to convey is that Scalaz is an incomprehensible cluster fuck of symbols to everyone but those in the know
Right, I get that there are lots of scala people who are very anti-intellectual and are vehemently opposed to learning anything. But what I don't get is how "if I don't learn this stuff, I don't understand it" is "snobbism" on the part of people providing the library you didn't learn.
>and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
I have not seen that response in either scalaz or haskell. It sounds an awful lot like the common strawman used to dismiss haskell as "academic" from people who have never bothered to try it. Practical experience with haskell in particular has been that people are ridiculously accommodating and helpful.
Right, I get that there are lots of scala people who are very anti-intellectual and are vehemently opposed to learning anything. But what I don't get is how "if I don't learn this stuff, I don't understand it" is "snobbism" on the part of people providing the library you didn't learn.
>and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
I have not seen that response in either scalaz or haskell. It sounds an awful lot like the common strawman used to dismiss haskell as "academic" from people who have never bothered to try it. Practical experience with haskell in particular has been that people are ridiculously accommodating and helpful.
The community around Scalaz is notoriously hostile (I've not experienced it myself however)/
Besides this, Scala has way too much Java in it to really be "algebraically elegant" or even simple! Scala is a compromise. It has the legacy of Java compatibility dragging it down. That's one of the main reasons it's caught on, but it's also the reason it isn't actually particularly simple or elegant. It's one of the most complex (but not necessarily difficult) languages in common use.
It is nowhere near as elegant or simple as OCaml or Haskell as they can afford to be much closer to the λ-calculus. Which is also why they can afford such incredible things like tail call elimination and type inference!
Also, while Scala is a multiparadigm language, it is not the best of both worlds. In embracing Java and OO, it throws away many of the advantages of functional programming. In fact, any non-trivial functional programming quickly becomes unbearable. Especially compared to Haskell.
Edward Kmett wrote a nice Reddit post[1] about how Scala falls short from a functional standpoint. This is from an entirely practical commercial standpoint based on his experiences at S&P Capital IQ. Here is what he had to say about functional programming in Scala: "If scala was the only language I had to think in, I'd think functional programming was a bad idea that didn't scale, too." A pretty strong image!
Their story is interesting: they took a Java project to Scala. It was an incredible improvement. Then Scala became a pain on its own, so they designed their own functional language for the JVM[2] and moved to that. It was the same sort of incredible improvement. The same thing that happened to Java happened to Scala!
Ermine, their new programming language, is basically like the core of Haskell adopted to the JVM along with some interesting new features. One thing that really stood out for me is that they have customizable type error messages: they can have type errors that are domain-specific! That by itself probably has a fair amount of value.
[1]: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
[2]: https://github.com/ermine-language/ermine