Effective Scala

It's from Twitter, It's open source, It's about Scala. What's not to like?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What's not to like...

Effective Java is about stuff that works, and stuff that doesn't work, with careful explanations and a lot of examples from, for instance, Java API (these tend to be mostly about what not to do...).

That "Effective Scala" is mostly about style and information about the language itself. The recommendations it makes are not explained, no counter-examples are given to show what breaks.

In other words, it suffers by comparison to Effective Java, and a lot. I wish they had picked a different name.

I was so asking for this...

I was so asking for this...

Slightly unfair

That's slightly unfair -- for example, they do back up their recommendations for implicits (for example), and their recommendations about using immutable collections (again, for example) -- just to pick two random examples.

(Of course it's not nearly as detailed as Effective Java, but...)

flatMap is the new bind

Funny how they carefully avoid mentioning they use monadic style by advocating liberal use of the unsuspicious-looking "flatMap" function!

Of workflows and monads

Yeah, it's a bit of an odd choice. I actually think the term monad is kind of terrible: it sounds far more abstruse than it really is, and doesn't give you a clue as to what it's about. I quite like F#'s choice of the term "workflow", which actually gives a decent feel for what it's about and makes the idea seem ordinary and approachable (which it is).

But I much prefer the term "bind" to "flatMap". The nice thing about bind is that it reminds you of the relationship between monadic bind and let binding, which is an important connection.


I've found that explaining it to people as mapping and then flattening the nested structure is enormously easier to understand what's actually happening. I think that to someone seeing them for the first time, "bind" is about as useful as "monad" in explaining the structure of the computation.

Except it's not true

"Map, then flatten" is not a good description of the bind operation for all monads (although I agree it's a nice intuitive place to start). So if you rename bind to flatMap, you may end up with a bunch of things called flatMap that seem to have extremely obscure semantics.

Actually you can define map

Actually you can define map and flatten for any monad. Whether that is more easy to understand than bind I leave to the psychologists.

Sure, but...

Sure, but while map is usually pretty intuitive, 'flatten' is often non-obvious. But I do see your point. I guess I don't know whether it's easier to understand or not.

In the case of the IO monad, at least, I think bind is a lot more intuitive than join. I guess I feel it's easier to see how bind generalizes beyond "collections", while "join" (and thus "flatMap") has a very collection-centric intuition. But, point taken... maybe it's just me.

Strange advocacy

Strange advocacy: each example with "flatMap" was immediately followed by the same example with "for" instead, and IMHO the example with "for" was more readable.
Is-there some use of "flatMap" where "for" cannot be used?

The for comprehension acts

The for comprehension acts as sugar for a chain of flatMap, filter and map calls, so no, there isn't.