Scala: The Industrial Parts [pdf] | Hacker News Reader

Scala: The Industrial Parts [pdf]

monkey.org

To be honest I was a bit disappointed by this presentation. I think Scala can be very simple -- at least 95% of the abstractions I use are just algebraic data types and type classes -- but this presentation didn't provide much clarity on "good" Scala beyond the usual pithy statements (e.g. "prefer composition over inheritance.") Beginners need very clear guidelines as they don't have the experience to make nuanced decisions.

Furthermore I found "Effective Scala" to be rather random in its presentation. I've found it much more effective to concentrate on the core Scala patterns (i.e. algebraic data types, type classes) and present language features in the context of the patterns they support.

I think you've already lost most programmers when you even mention the words 'alegbraic data types' or 'type classes'. Devs on HN and /r/programming know those words (or many do), but in industry... good luck.

I get blank stares and even hostility sometimes from very competent engineers when I try to explain the Java type system is not the end-all be-all of type systems and that it is in fact... not all that powerful or particularly safe either.

When teaching Scala I wouldn't start with the jargon first -- start from the problem, show the solution, then name the patterns used. When teaching algebraic data types, for example, we start with more familiar OO terminology like "is-a" and "has-a", and then say we have this other name for these patterns.

To be clear, I have a horse in this race: I teach Scala (and have written a book on it, which you can find here: http://underscore.io/training/courses/essential-scala/). I also strongly believe Scala has been held back by poor teaching.

It depends on the country.

For example, in Portugal many companies do require a CS or EE degree, which means everyone has been exposed to those terms, at least if they enjoyed a degree in universities like IST, UNL/FCT, UC and similar.

Just as an example, back on my day, the Prolog and LP classes were shared between CS and EE degrees.

I somehow hadn't come across Twitter's Effective Scala guide, which is a great companion to this presentation.

https://twitter.github.io/effectivescala/

> The primary objective of a type system is to detect programming errors. The type system effectively provides a limited form of static verification, allowing us to express certain kinds of invariants about our code that the compiler can verify. Type systems provide other benefits too of course, but error checking is its Raison d’Être.

I'd argue that understandability should be the goal. Verification without understandability is a loss. Understandability without type-based verification can win. Put understandability first with types and get the benefit of both.

Google cache: http://webcache.googleusercontent.com/search?q=cache:srB_qjf...

With great power comes great responsibility...

Sounds like they should use Go.

And then their O(10^7) LoC increment the exponent, as Go has fuck all higher level abstractions.

    > Sounds like they should use Go.

You're being too pithy and probably a bit snarky, but I think there's truth in this. I think Marius underemphasizes the problems of incidental complexity that plague Scala, and overemphasizes the importance of futures as a mechanism of composition. Specifically, I think all of the advantages he attributes to futures and async methods can also be equally well achieved with coherent synchronous code, which is the domain of Go. Generalizing, I think the (good and interesting!) things he outlines in this presentation can not only be achieved in Go, but in a way that makes them even easier to reason about, manipulate, extend — all of the things he wants to optimize for.

Maybe Scala was a good, or even the best, choice of implementation language for concurrent application services six or eight years ago. I don't believe it's a good, and certainly not the best, choice today.

With Go you have less type safety and no generics though.

Stuff like this is why many developers don't take Go people serious anymore.

Reply on news.ycombinator.com