

Scala: The Industrial Parts [pdf] - mariusaeriksen
http://monkey.org/~marius/scala2015.pdf

======
noelwelsh
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.

~~~
meddlepal
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.

~~~
noelwelsh
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/](http://underscore.io/training/courses/essential-scala/)). I also
strongly believe Scala has been held back by poor teaching.

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

[https://twitter.github.io/effectivescala/](https://twitter.github.io/effectivescala/)

~~~
michaelfeathers
> 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.

------
aaronbee
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:srB_qjf...](http://webcache.googleusercontent.com/search?q=cache:srB_qjfGK84J:monkey.org/~marius/scala2015.pdf+&cd=1&hl=en&ct=clnk&gl=us)

------
eranation
With great power comes great responsibility...

------
dkarapetyan
Sounds like they should use Go.

~~~
sagichmal

        > 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.

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

