If it's indeed too complex for the mass average developers, then I can use it to filter them out. I got a free way to hire better developers (I don't have to use Scala in production in order to use it in interviews...) Also if you do find a top developer who managed to master Scala's complexity, then the complexity is no longer a problem, it becomes a benefit, and they use it to create better libraries and APIs for the "regular" developers to use with more ease and type safety.
If it's not complex then I can easily hire any decent Java developer and provide Scala training (I think there is no argument that it's more productive / expressive than Java*, and remember in this "scenario" Scala is not more complex to learn than Java)
Win win
Now the real issue is compile times. If anything itches me toward trying Kotlin is having way too many coffee breaks (http://xkcd.com/303/)
Definitely you can achieve more with less characters in Scala than Java. Are you paying by the character?
For me, legibility and long term readability is the most dominating factor out of any. This is really subjective, but saving on characters you have to type, only to make the code a lot harder to read seems like penny wise pound foolish to me.
And to pull out an expert who agrees with me, Linus slaps C++ around for many of the same reasons. He noted that it's a lot easier to review patches in C because there is no hidden features (eg: operator overloading) that prevent comprehension.
I think the focus on operator overloading is misplaced; in C you might not be able to write "a + b" and have it launch some missiles, but you can write "add(a, b)" and have it launch some missiles, which is just as bad. If anything Scala is more predictable and uniform here - "a + b" is just sugar for "a.+(b)", methods and operators work the same way, and the operator precedence list you have to memorize is much shorter than C's.
However, it's pointless to compare methods when we need to be comparing applications. In my experience, I'd say I get about... 100 times reduction in LOC compared to a java application. Not hyperbole, two orders of magnitude LOC reduction compared to java applications.
Now, given that information, does it matter if each particular line takes you three times as long to read? With more type safety to boot?
Leaky abstractions, as you mentioned, result in unclear code. On the other hand, well-designed and easily understood abstractions reduce complexity.
Take for example, the atrocious lambda 'hacks' needed before Java 8 - create an anonymous class, then override a method. Compare that with something like words.map { _.size }
Some people think that terse code is more readable, not just more writeable.
For truly widespread adoption, I'm talking PHP or Java levels, you need to have a totally different mindset. I don't think Scala is that language.
I'm not sure if that's Scala's fault or Scalatra or SBT, but no matter how I sliced it, as of 9 months ago or so, Scala didn't feel amazing to develop code in. Everything felt a bit clunky. The code itself I loved, but the way I got there felt worse.
Surprisingly when I tried Go, it was a much better developer experience in terms of the near instant compile, refresh, see change loop and also running tests was nearly instant. The "instant" feeling I get in PHP and Ruby was there, but in a compiled language. However, in Go, I don't have some of the functional and immutable concepts that I have in Scala, which sort of sucks.
At the end of the day I'm making tradeoffs somewhere and it doesn't feel awesome anywhere. I might check out Facebook's Hack simply because it offers type checking, performance, and fast refresh. Also maybe the latest .NET stuff announced with continuous compile might bridge the gap for C#. I really don't know.
I have yet to find the language that really feels amazing as a developer in sort of all areas. Every language seems to have baked in tradeoffs.
Anyway,it's great Scala choosed the JVM because it can be part of the stack of any business that already relies on it.That's what matters IHMO.If it is not fit,one can still switch back to java and still use the jar developped in scala or exploit java libs.
Equally complex, if not moreso, and not any easier, but it felt simpler since it focused on a single paradigm instead of attempting to mix two big ones, and the whitespace-enforced readability and uniformity helped reduce cognitive load while learning and working with it. Great performance too, C-like in some cases with expert optimizations, and a range of concurrency and parallelization options.
And there's something about Scala using traits for everything that rubs me the wrong way.
Stuff like this I still find odd, mixing abstract classes with functions and inheritance.
abstract class IntSeqBuffer extends SeqBuffer {
type U = Int
}
object AbstractTypeTest1 extends App {
def newIntSeqBuf(elem1: Int, elem2: Int): IntSeqBuffer =
new IntSeqBuffer {
type T = List[U]
val element = List(elem1, elem2)
}
val buf = newIntSeqBuf(7, 8)
}There is a ton of complexity in the type system but you don't need to learn it all at once. If you approach Scala development like you approach C# development you'll go far.
If we are talking about the typical enterprise, with mega projects, having out-sourcing and off-shoring components, then Java is still the king.
Since a few years I am mostly involved in such type of projects and I see how many of such developers struggle with modern programming concepts.
When it was first announced some Scalaz core members freaked out on Twitter (due to proposed simplification of the type system), but that died down, apparently the changes won't completely neuter the type system down to that of other JVM languages.
Presumably tooling and build times will improve, along with fewer ways to do the same thing, when Dotty comes on the scene (guessing a couple of years away).
For now, if one makes use of SBT sub projects along with incremental builds in SBT 0.13 (and turns off automatic builds in Eclipse/IntelliJ), one _can_ have a snappy development experience and decent compile times.
Have to learn the ropes though, as with any powerful language, out of the box there are hard yards to get through...
I tend to wonder why more people do not talk about Eckels book on Scala if they want a more basic intro to the language.