Hacker News Reader

Comment by Lewisham | Hacker News Reader

Can someone please explain to me why Scala has been getting such vitriol on HN comments lately? I've never found Scala "difficult"; you can use Java and take in new bits as you go. Why do people keep saying its too complex? It's no more or less complex than Ruby, and certainly less of a learning curve than Haskell, more familiar syntax than Lisp (for more programmers), yet the comments here indicate that "Oh, Scala is so complicated, how could anyone learn it?" This article seemed on the money for me.

I know things like type erasure and other programming language bits and bobs upset the PLs gurus, but I really don't care about that. I can write concise code that looks like a dynamic language, but get full static type-checking. That's a huge win.

I really just don't understand it.

View on HN

It so happens I've been trying to write my first "real" Scala application these past few days. It's been a harrowing experience. Just a few highlights off the top of my head:

* Eclipse support is spotty. Apparently legal programs suddenly develop lots of errors. Sometimes restarting Eclipse will allow the program to run anyway.

* Types are constantly getting in my way. Sometimes types are correctly inferred, sometimes I need to add types to hint the compiler about what I'm doing.

* Writing anonymous functions remains hit and miss. I just throw in underscores at random until something works.

* I don't understand where the round or squiggly parentheses go in for comprehensions; i.e. what goes in the parens and what stays outside.

* Hashmaps have a cool "+=" operator to add a key-value pair. So why does "put" work but "+=" doesn't? Another mystery.

* Sometimes the parentheses after function invocations are optional if there are no parameters. Sometimes not. Why?

It's not Scala's fault that the Eclipse plugin is less than perfect, it's already very powerful. As for my little struggles with the language, none of this is witchcraft; I'm sure there are well-defined rules and sensible answers to all these questions and many more. But I must say I'm annoyed with the huge number of rules behind Scala. The amount of stuff I need to learn to really use Scala effectively is daunting.

Contrast this with my Ruby experience. This is a language that places great value on orthogonality: wherever possible, every operation works the same in every situation. So you have a smallish number of versatile functions, not too much stuff to absorb and things generally Just Work (TM). I taught myself Ruby and Rails and wrote my first useful Web app in a couple of weeks' worth of evenings, and it was a very pleasant experience.

Clojure, similarly. All the parentheses took some getting used to, but the language's syntax is wonderfully simple and consistent, so getting stuff done is mostly just a matter of looking up the most appropriate function in the cheat sheet. I managed to be productive (for small programs) with Clojure in a couple of days.

Scala is no doubt a fantastic language. But thanks to its kitchen sink attitude, it's not an easy language to come to grips with for someone with an aging memory and a less than full-time commitment.

Spending a little time with the unofficial Scala Style guide (http://davetron5000.github.com/scala-style/index.html) helped me figure out some of the "when? why?" questions.

Programming in Scala has a very straightforward explanation of for comprehensions. Mysteriously, almost every other explanation I read left me more confused than before. I don't know why there are so many poor and/or partial explanations out there. Read Programming in Scala instead and you'll be fine.

As for type inference, another week of programming and you'll fall into a groove where you're anticipating when you need to declare types and when you don't. I had the same pain, and after a week, it had dropped down to a very occasional annoyance. It might just be my programming style, though -- I declare the return types on all functions that are meant to be called from another class or object, so there's a lot of information for the compiler to work with.

I agree about the underscore thing. It's pretty useless, and Clojure's version looks superior to me. As best as I can tell, the underscore doesn't work inside an extra layer of parens or curly braces. But it's just syntactic sugar, after all. Using a named variable isn't the end of the world. It's just three extra non-whitespace characters, "n =>".

But thanks to its kitchen sink attitude, it's not an easy language to come to grips with for someone with an aging memory and a less than full-time commitment.

Perhaps this is one of the things that is tripping people up that I'm not doing. I tend to still be quite verbose in my code, even if only as a way of reminding myself what I thought the code was supposed to do (ever look back at Python and you're not really sure whether the variable is supposed to be a list or a tuple or a string? I have that problem all the time). I don't tend to use all the flourishes like underscores and such.

It seems a bit like Perl's many ways to do it attitude. Except I feel like Perl was designed by ideology, whereas Scala has a lot of bits and pieces because it wasn't clear to Odersky et al. which bits people would like and which they wouldn't. Perhaps rather than trying to enforce an idomatic style, they wanted programmers to find their own way. But that means there's things in the language that exist and can't be taken out (XML literals), and there's no documentation cohesion (by which I mean different documents will tell you to do different things, and you're not sure which is best).

If you Google "effective scala", you'll see a number of people clamoring for a book along the lines of Effective Java, and Scala sorely needs it, but Scala is still too much of a moving target to warrant putting anything in dead tree form yet. The Davetron Scala Style guide, however, is a really good stop gap, and helped me a lot.

I can't explain vitriol, but when I took a brief look at scala it seemed to have unnecessary complexity from a bunch of ad-hoc rules to simplify some specific case. Little things, mostly syntax, like the conditions for leaving out parentheses in a function call, or around a tuple, or braces around a function body. If there's a unifying explanation for all the syntactic abbreviations, it wasn't in Odersky's book. Some of the conditions for traits and implicits look fairly ad-hoc, but at least you can guess they conservatively ensuring some simple essential propertly like decidable implicit inference.

This sounds like a good explanation. I think there's a lot of complexity bolted on in order to make the syntactic sugar work.

Most of the complaints I see from Java programmers amount to this:

http://blog.tmorris.net/anti-intellectual-euphemisms/

Specifically:

> using the word complex, unnatural, academic, “your world” or unintuitive to mean “I am not able nor am I willing to invest the effort to come to to understand this.”

Other than those people:

The blog author I quote above is one of the many "PL gurus" you speak of that rip into Scala because of its various deficiencies when compared to the likes of Haskell. The ones I am smart enough to understand mostly revolve around the type inference and type erasure problems. You mentioned those but I have already run into issues where I did care about them so I don't think its fair to dismiss them as you did.

The amount of hyperbole that comes from elements of the Scala community on actors I think is a cause of a fair amount of vitriol, mostly because actors are not a silver bullet and come with their own host of problems. Akka is trying to solve some of those problems of course :)

And of course the lack of tools. It's hard for me to talk about this because I loathe IDEs. So far I have been writing my medium sized project entirely in vim + NERDTree and it's been great. I imagine with enterprise scale projects I would start to miss Eclipse though.

I know several (good) java programmers which thought they should without learning be able to understand/write idiomatic scala code. But idiomatic scala has also a lot of concepts (functional programming etc.) which they just don't knew.

Reply on news.ycombinator.com