Your mileage may certainly vary, but having used Scala pretty steadily for the last year, I find the strong majority of Scala code I see in practice generally very easy to intuit. You can do stupid things with it--see Scalaz, which is bad ideas[1] given form--but for the most part, people don't.

I used to have the same concern you're expressing, and a few others besides--I've written comments on HN along the lines of "I'm writing Scala that I can't read the next day"--but I got past that stage not too long afterwards, and I find it remarkably predictable and consistent in everyday use.

[1] - this isn't a fair characterization, see deeper in the tree

what is wrong with scalaz?

Sorry, that was a little more flip than it should have been. Scalaz attempts to wedge into Scala a set of idioms that don't really work well in Scala; as an OO language that's still largely imperative at its core, it's swimming upstream and the code--and the use of that code--is pretty clumsy.

Scala isn't a pure-FP language, and trying to treat it as one doesn't really...work. Square peg, round hole. For me it falls in the "neat hack, but" bucket. That it can be done as Scalaz does is cool, but the practical value of it seems vastly oversold and I'm uncomfortable with the functional-everywhere political viewpoint pushed by some of its leaders (and fortunately Odersky seems opposed to a lot of it, which IMO bodes well for Scala's future).

> as an OO language that's still largely imperative at its core

Why do you say this? vals and immutable data strucutres are clearly emphasized in Scala, so how can you say that FP isn't at its core?

>Scala isn't a pure-FP language, and trying to treat it as one doesn't really...work

Why do you think scalaz concerns itself primarily with enforcing 'purity'? Scalaz' effects library isn't even part of it's core repo.

>You can do stupid things with it--see Scalaz, which is bad ideas given form

Oh the irony.