Scala – 1 Star – Would Not Program Again

1. Lack of documentation

2. Breaking backwards compatibility

3. Opaque error messages

4. Encourages ad-hoc syntax that makes sense to one person (or team) but does not to the next -- maintenance nightmare.

5. Lack of general stability in language and libraries serving to confuse the eco-system.

Hmmm....

It starts with a criticism of a build system that is most likely SBT. Now, for all its strengths, you could not pick an easier target than SBT if you wanted to bad mouth a piece of Scala software, but what we get is:

* It is slow to recompile the build definition (true, not the most complex build files I ever saw ever took anywhere near that time); * I didn't bother to learn the syntax (or what was going on).

Is that it? If all you have to complain about SBT is this, then you never actually made even a passing attempt to learn to use it. That doesn't make me much confident about the author...

Next, the author has been writing Scala code for the past two weeks. Scala is not, I argue, as complex as people make it to be, but it has enough different concepts than what most other languages offer that you simply don't pick it up in two weeks, just like you didn't learn your first programming language in two weeks.

If you come from Java, two weeks of Scala let you use Scala like Java: you'll produce working software, though not in any idiomatic style. Well, we pick later on that the team is using Spray, and Spray is a very idiomatic library. You do have to unlearn many habits to pick it up, and the author doesn't seem interested in unlearning anything he "knows".

He picks Scala because, hey, there were doing XSL and doing XML processing, so Scala must be good at it, right? Well, actually, no, but I can see why one would think that, and also why one would be disappointed that it actually isn't, but picking the wrong tool doesn't mean the tool is bad: it's just not the tool for that.

So we go to TDD, where he comes up on Scala awful compile times (which troubled him with SBT before). That is a problem that Scala community has faced, and it has produced solutions to that problem. Specifically, it has adopted SBT, a build tool which can compile incrementally (and automatically on change), and even execute just the tests that are affected by a change (automatically as well).

Of course, the author, having chosen Scala, decides to ignore the existing solutions and picks up Gradle, which supports none of this. Now, Gradle is a very nice build system, but, again, the author picks the wrong tool and proceeds to blame the wrong thing from it.

Next, the author proceeds to have problems with libraries -- problems somehow not shared with the rest of the community (see comments by other Scala users). He mentioned stability problems, and then mentions two pieces of software with excellent documentation, extremely stable, and supported across a broad range of versions of their dependencies.

Now, choosing Spray when you are not familiar with Scala was a terrible decision, and I can well see where the author had trouble using it -- while not agreeing there's any problem with Spray itself. Having trouble with Specs2, however, makes me seriously doubt his abilities -- if he truly had trouble with it.

Next he proceeds to some discussion of simplicity, and I'd grant that Scala is not simple. However, he ties that to a lack of regularity, which is interesting in that Scala is highly regular, much more so than Ruby. It just allow different things than the languages he is used to, so it looks different.

I can buy "looks different" -- yes, it does. But the author's inability to realize how regular it is just goes to show that he has a very, very poor knowledge of Scala. That's not a problem with Scala, it's just that he didn't learn Scala, and it keeps showing.

So, having not learned Scala, he tries to accomplish something that required a specific Scala knowledge he lacked and fails. And somehow that's Scala's fault and Spray's fault, not his.

Well, I admit it: if you don't learn Scala, it is very difficult to program in Scala. That's certainly not the case with PHP, for example, but I have certainly struggled with rather simple tasks in Ruby when trying to write code in Ruby without learning it. I just never blamed Ruby for it.

Next, "everything is a type". I disagree that this is in any way a problem -- if you are going to complain about that, how about just writing "Scala is a statically typed language" and leave it at that? We all knew that, didn't we?

So, having chosen a statically typed language, he dislikes the fact that it actually tries to use types? Weird, but at least he doesn't make it a problem of Scala itself.

On the other hand, it took me thirty seconds to find RawHeader, which allows arbitrary headers, which indeed would be a weird thing to be missing. It's right there, among the other headers. Among, say, Origin and either Access-Control-* headers, which happen to be the CORS headers, all of which appear in the API docs, so what gives?

Maybe they are new headers? Well, the CORS headers are new, if not that new, but maybe the article refers to something that happened months ago. The raw header is there for quite a while, as you can see for yourself here: https://github.com/spray/spray/blame/master/spray-http/src/m...

At this point, I don't even know where the author is coming from, that he failed to spot this. It is certainly not Spray's fault, much less Scala's.

Next comes a rant on lack of H-M type inference. Well, we all would have liked to have more type inference (without making the compiler even slower!), but separate compilation, subtyping and full type inference is not a solved problem. Which doesn't mean we can't gripe about it.

But there's a damning comment among it: the error message he describes in his "workflow". Hey, Scala infers the return type, so he doesn't need to add it, unless he's doing recursion of calling overloaded methods. If he were doing that, however, the error message would be different.

What the error message says, however, is that he is using procedure syntax -- that is, a method returning void in C/Java parlance -- when he actually intended the method to return something. He doesn't need to add the type, he just needs to use the correct declaration:

def method() { body } // procedure (unit-returning method)

def method() = expr // function

He spent two weeks programming in Scala, then went on to write a blog about it, but he still hasn't figured out a simple detail like this, despite the compiler telling him what the problem is?

Yes, beginners might well struggle with this oddity, but for two weeks??? And despite having fixed it throughtout the program? Really?

Now, detour briefly through long vs int, which I actually agree with, but saying he was "reminded" of it shows a complete lack of familiarity with statically typed languages.

Again, fine that you don't like statically typed languages, though I think one ought to first learn one of them before criticizing, but you could start and end your post with "I don't like statically typed languages".

Then there are other issues which he enumerates but don't describe, and which I can only disagree with. Horrible repetition required by case classes? Err, what repetition?

So, in the end, it seems that what the author really wanted to say is: I don't like statically typed languages, and I tried to use one for the wrong reasons, in the wrong way, without learning it, and failed. No need to blame Scala for his bad decisions.

Again, in my experience, the documentation in Scala land is very good. The standard library has a really good API documentation, also checkout the documentation project at http://docs.scala-lang.org/ plus there are several very good books available; then there are the libraries in Scala's ecosystem, like Play2, or Akka, or Slick for example that do have good documentation. The online documentation for Play2 does not match the online documentation for Ruby on Rails or Django, but it's newer and it's improving and I remember a time when Rails was several years old and lacked online documentation. I did find undocumented features in Play2's online documentation, but nothing that couldn't be solved with a question on its mailing list. These are open-source libraries, with strong communities that communicate a lot on mailing lists, you know.

The great thing about Scala is that you can also use any Java library you want and wrapping Java libraries in Scala-ish interfaces is actually easy and a great learning experience. I wished you'd be more explicit about this point, because for me I don't feel like there is a lack of documentation.

> 2. Breaking backwards compatibility

This is a point that comes up a lot, but I don't think it's that important for people actually using Scala. Scala is a compiled language, the libraries get distributed / deployed as compiled bytecode packaged up as Jars. This means that breaking compatibility is really easy, as all you have to do is to change an interface, like adding, removing or changing the signature of a method and boom, all code that depends on that interface needs to be recompiled, even for code that's not using the method in question. Dynamic languages that get interpreted or compiled on-the-fly, like Python or Ruby, are distributed as source-code. So by their nature don't have this disability.

The alternative to breaking backwards compatibility in Scala is to freeze the standard library. Personally that's not a compromise I want, because for this very reason Java's standard library is full of idiosyncrasies, broken interfaces, broken behaviour and various other artefacts going back to Java 1.0, that were never fixed in order to preserve backwards compatibility.

Scala has improved a lot though, compared to the 2.8 days. Nowadays you've got a guarantee that minor versions aren't breaking backwards compatibility. Code compiled with Scala 2.10.0 is guaranteed to be compatible with Scala 2.10.3 at least. The next version free to break compatibility with 2.10 is Scala 2.11. The tooling in Scala's ecosystem, like SBT, is also friendly to supporting multiple versions. To compile, test and deploy versions for multiple Scala versions is often just a configuration change, assuming you don't use APIs that aren't available in older Scala versions, in which case the back-ports are hard to accomplish in any language.

> 3. Opaque error messages

That's in the eye of the beholder. Sometimes the error messages are not so good, especially when triggered by the new macro support in Scala 2.10, but you know, those macros are experimental and improving by leaps and bounds. 90% of the time I have no problem understanding the given error messages and many times you get really helpful errors or warnings about code that you think it's correct, but isn't, like when pattern-matching on an ADT and missing a case. And I prefer opaque compile-time error messages to subtle or non-deterministic runtime error messages. In Python I used to suffer from null pointer exceptions all the time. In Scala null pointer exceptions are very rare.

> 4. Encourages ad-hoc syntax that makes sense to one person (or team) but does not to the next -- maintenance nightmare.

This is a thing that gets repeated by people that haven't used Scala, either personally or in a team. The syntax, even for libraries that go over the top on DSLs, is quite sane. It's much saner than in Ruby. And I prefer the succinctness of it, compared to code written in Java that often feels like a puke of useless crap that you have to read through in order to get to the bottom of whatever the piece of code you're reading actually does. Code written in more powerful languages feels like being harder to read, simply because each line of code does more.

It's not the syntax that's the problem dude. Having worked with Scala in a team, the real problem are the functional programming concepts involved. In Scala you end up using recursion, error-handling without exceptions (e.g. Either/Option/Try), lazyness, monads, applicative functors, iteratees or other forms of doing stream processing and the list can continue. But it's hard because most developers are not familiar with these concepts, because many of the techniques involved are like death by a thousand cuts to apply in more mainstream languages.

Then there's the type system. Scala is much more static than languages like Java or C#. It's great for users of properly designed libraries. It's not so great for language designers themselves, as people sometimes end up jumping the shark on static type safety, digging themselves into a corner. When you're seeing libraries that are hard to read because of all the generic types involved, well, on the flip side, Scala allows you to do things that are impossible to do in Java. That's why you're seeing a lot of type-casts in Java, whereas in Scala type-casts are more like an anomaly. Plus, Java uses wildcards for covariance/contravariance, which suck. Java libraries are often not generic because generic types in Java suck so badly.

> 5. Lack of general stability in language and libraries serving to confuse the eco-system.

I think at this point, you're being redundant, for the lack of better criticism. I disagree of course.