some form of computation Mathematical foundation (category theory) Popular in functional cycles (e.g., Haskell) Learn the jargon so you can understand and not feel (too) intimidated Make your head explode (?!)
paradigm shift) Add another tool to your toolset (more power to you!) Refactor + eliminate some boilerplate (through better abstraction) Hopefully, write better programs. (different structuring mechanism for data + flow control)
don't. <cough> Java <cough!> Some do to some extent. <mmmh> Scala <mmmh!> Some pretty much require it. <hmmm> Haskell <hmmm?> Don't try to fit a square peg in a round hole. Don't work against the grain of your language.
about types belonging to a big hierarchy of types Instead, think about what the types can act like and then “decorate” them with appropriate typeclasses e.g., an Int can act like a lot of things. It can act like an equatable thing, like an ordered thing, like an enumerable thing, etc. implicit def (x: Int): Equality[Int] = … implicit def (x: Int): Ordered[Int] = … implicit def (x: Int): Enumerable[Int] = … implicit def (x: Int): Numeric[Int] = …
arbitrary monoids, def sum[A](xs: Seq[A])(implicit m: Monoid[A]): A = if (xs.isEmpty) m.identity else m.combine(xs.head, sum(m)(xs.tail) And an be called as follows: sum(List("a", "bc", "def")) => “abcdef” sum(List(1, 2, 3)) => 6
(Int, Int) // through the Stream Monoid to generate Fibonacci numbers val fib: Stream[Int] = (0, 1).iterate[Stream] { case (a, b) => (b, a + b) } map (_._1)
requires the ability to take stuff out of the box! But a few monads do allow you to... e.g. List[_], Option[_], ... One notable monad that insists on keeping everything to itself: IO[_] !
two computations X and Y, • Run X, discard result, then run Y • Run X and feed result to Y. * This intuition is generally more useful, but is more difficult to explain, precisely because it is so general.
properties • Raise level of abstraction • Lead to code reuse Who knew mathematical abstractions could be useful? :-) But where's the killer app? (Hint: somewhere in your own code)
types” • Crazy #$^&@! operators • Some abstractions can be difficult to grok Identification can be surprisingly difficult “Natural” or default abstractions aren't necessarily universal Layering monads becomes geometrically complex • Not a silver bullet against complexity
problematic • Running out of operators • Boilerplate to create/use typeclasses • Performance: boxing overhead • At least we have for-comprehensions ...
overdone. And everyone has a different limit where more abstraction hurts rather than helps. For instance for me category theory is over the limit but for some others it's fine.” – Martin Odersky, Dec 24th 2009 scala-user@ mailing list
are generally “over [my] limit” Outside of the usual suspects, need a critical mass of easily identifiable, natural monoids/monads in codebase to warrant using Scalaz Nonetheless, I enjoy seeing Scalaz pushing the functional envelope of Scala I hope the Scala standard library progressively integrate more typeclasses (Equality, Numeric, …) and standardizes functional idioms – in moderation.