

Does Scala as a FP Language Suffer From Its OO Syntax? - bertzzie
http://java.dzone.com/articles/does-scala-fp-language-suffer

======
andolanra
Fundamentally, this post conflates _type classes_ with _functional
programming_. Yes, type classes are one way that functional languages approach
ad-hoc polymorphism (i.e. distinguishing which implementation of a function to
use based on the types of its arguments.) This is not the only way to approach
said problem. For example, OCaml has both objects and modules/functors to
support ad-hoc polymorphism. That Scala and Haskell take a different approach
to this problem does not make Scala "less" functional than Haskell.[1]

As usual, the real problem is one of terminology. If you take FP to mean
"Haskell and Clojure", then one could easily find features of, say, Erlang or
OCaml or Scheme that are "not FP." All of these are conventionally considered
functional languages, and IIRC none of them—save Scheme-based ports of
CLOS—feature multimethods or type classes. So, before nitpicking about whether
a language is more or less FP, one should always clarify: _what do I mean by
FP?_

[1]: Not on its own, anyway; there are other arguments that can be made both
ways, but this is not the space to make them.

------
crntaylor
Why the focus on type classes? Yes, type classes can sometimes be very helpful
(the Num, Monad and Functor typeclasses in Haskell for example - where would
we be without them?)

But overuse of type classes in any language is an antipattern. Luke Palmer
sums it up well in his blog post [1]

 _Advanced type system features have their place, but plain old functions go a
long, long way. Functions are the masters of reuse: when you use an advanced
feature, you need a yet more advanced feature to abstract over it. But all you
need to abstract over a function is another function._

Using type classes where they're not appropriate leads to 1. writing
unnecessary boilerplate code, 2. torturing the type system and 3. a slippery
slope of adding more and more advanced type system features to bludgeon your
poor design choice into the right shape. Use functions!

It's also worth reading Gabriel Gonzalez's post on a similar topic [2]

[1] [http://lukepalmer.wordpress.com/2010/01/24/haskell-
antipatte...](http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-
existential-typeclass/)

[2] [http://www.haskellforall.com/2012/05/scrap-your-type-
classes...](http://www.haskellforall.com/2012/05/scrap-your-type-classes.html)

~~~
sfvisser
I think this point can not be stressed enough. Type classes have their place
in day to day (Haskell) programming, but overuse quickly leads to bad
abstractions that boil up from deep inside a codebase to all the way up to the
public API.

My experience as a library author is that adding a type class for an
additional layer of abstraction is easy and feels very natural. My experience
as a library user is that understanding what problem the library author has
solved using a type class can be very hard and confusing.

------
eranation
No. (<http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines>)

But seriously, I don't feel so, (though I came from writing Java). I like the
protection of static typing, and haven't encountered yet anything that made
the FP part suffer from the OO part.

p.s. if you haven't already, Martin Odersky himself is delivering a course
named Functional Programming in Scala (still not too late to join)
<https://class.coursera.org/progfun-2012-001> It might be too basic if you are
fluent, but I found it just in the right level for me. In any case, learning a
language from it's creator seems to give you some insights.

------
jjm
Once you understand that Scala is a hybrid, all those not-pure FP aspects
start to make sense in that context.

------
ndepoel
I think you ought to see this the other way round: Scala as an OO language
definitely benefits from its FP syntax.

