

The Dark Side of Scala - lauriswtf
http://nurkiewicz.github.io/talks/2014/scalar/?utm_content=bufferaef95&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer#/

======
A1kmm
Scala is a powerful language - it has lots of ways to make really nice
embedded DSLs, but you can also write obfuscated code that doesn't behave
intuitively in it (as with many languages).

To explain the behaviour of some of the non-intuitive things in the slides:

    
    
      * List(1,2,3).toSet()    This is asking is () i.e. Unit a member of the Set(1,2,3) - the answer is false. List((),1,2,3).toSet() is true. The programmer probably wanted List(1,2,3).toSet.
      * The val code on slide 6 throws a null pointer exception because triple isn't initialised by the time it is evaluated. Languages like Haskell where order isn't important are nice, but Scala is not such a language. On slide 7 the int isn't initialised.
      * The return in lambda thing is probably a good reason never to use return in Scala if you are doing functional programming, in which case you don't need it. If you aren't doing functional programming, the semantics of returning from the outer function are useful.
      * The Seq-ish example on slide 12 is confusing mainly because the comment is confusing. p is an Iterable, meaning that it is traversable once. Asking for the size traverses it, so at the point of the comment, it has been traversed already, and so p.size is in fact 0 (no remaining elements). It could be fixed easily by writing val p = Seq(1,2,3).permutations.toList
      * The map comparison is unfair, because the Scala example is more general - the Haskell and Clojure examples work over a particular data structure only.

~~~
dllthomas
Regarding the first, a lint checker that demanded a space before () if it is
following a token other than some kind of open (parens, braces, brackets...)
would probably clear up whether it was intended or Java habits.

