Debunking Scala myths [closed]

Answer 1

Myth: this.type refers to the same type represented by this.getClass.

As an example of this misconception, one might assume that in the following code the type of v.me is B:

trait A { val me: this.type = this }

class B extends A

val v = new B

In reality, this.type refers to the type whose only instance is this. In general, x.type is the singleton type whose only instance is x. So in the example above, the type of v.me is v.type. The following session demonstrates the principle:

scala> val s = "a string"
s: java.lang.String = a string

scala> var v: s.type = s
v: s.type = a string

scala> v = "another string"
<console>:7: error: type mismatch;
 found   : java.lang.String("another string")
 required: s.type
       v = "another string"

Answer 2

Myth: Pattern matching doesn't fit well with the OO paradigm.

Debunked here by Martin Odersky himself. (Also see this paper - Matching Objects with Patterns - by Odersky et al.)

Answer 3

Scala has type inference and refinement types (structural types), whereas Java does not.

The myth is busted by James Iry.

Answer 4

Myth: That Scala’s “Option” and Haskell’s “Maybe” types won’t save you from null. :-)

Debunked: Why Scala's "Option" and Haskell's "Maybe" types will save you from null by James Iry.

Answer 5

Myth: methods and functions are the same thing.

In fact, a function is a value (an instance of one of the FunctionN classes), while a method is not. Jim McBeath explains the differences in greater detail. The most important practical distinctions are:

• Only methods can have type parameters
• Only methods can take implicit arguments
• Only methods can have named and default parameters
• When referring to a method, an underscore is often necessary to distinguish method invocation from partial function application (e.g. str.length evaluates to a number, while str.length _ evaluates to a zero-argument function).

Answer 6

I think a common misconception amongst many scala developers, those at EPFL (and yourself, Kevin) is that "scala is a simple language". The argument usually goes something like this:

• scala has few keywords
• scala reuses the same few constructs (e.g. PartialFunction syntax is used as the body of a catch block)
• scala has a few simple rules which allow you to create library code (which may appear as if the language has special keywords/constructs). I'm thinking here of implicits; methods containing colons; allowed identifier symbols; the equivalence of X(a, b) and a X b with extractors. And so on
• scala's declaration-site variance means that the type system just gets out of your way. No more wildcards and ? super T

My personal opinion is that this argument is completely and utterly bogus. Scala's type system taken together with implicits allows one to write frankly impenetrable code for the average developer. Any suggestion otherwise is just preposterous, regardless of what the above "metrics" might lead you to think. (Note here that those who I've seen scoffing at the non-complexity of Java on Twitter and elsewhere happen to be uber-clever types who, it sometimes seems, had a grasp of monads, functors and arrows before they were out of short pants).

The obvious arguments against this are (of course):

1. you don't have to write code like this
2. you don't have to pander to the average developer

Of these, it seems to me that only #2 is valid. Whether or not you write code quite as complex as scalaz, I think it's just silly to use the language (and continue to use it) with no real understanding of the type system. How else can one get the best out of the language?