Scala: The Industrial Parts [pdf](monkey.org)
monkey.org
Scala: The Industrial Parts [pdf]
http://monkey.org/~marius/scala2015.pdf
14 comments
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.
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.
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.
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/
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.
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.
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.
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.
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.