News for hackers. Stuff that matters.
Re:JDK 8 Release Notes by yummyfajitas on Wednesday March 19, 2014 @12:48AM (#7426873)
Why would you ever pattern match on Option[T] in Scala? In all my code, I do either:

    optionalF.map( _.whatever ).getOrElse(fallback)
or perhaps

    (optionalF <+> optionalFallback).getOrElse(finalFallback)
For those unfamiliar with <+>, see here: http://www.chrisstucchio.com/blog/2014/handle_failure_with_p...
Re:JDK 8 Release Notes by modersky on Wednesday March 19, 2014 @04:06AM (#7427297)
I think that's a pretty extreme position. First, it will run a lot slower than the pattern matching alternative:

    optional match {
      case Some(x) => whatever(x)
      case None    => fallback
    }
Second, I find the pattern matching code much clearer. Sure, it's also longer, but clarity trumps everything.
Re:JDK 8 Release Notes by noelwelsh on Wednesday March 19, 2014 @04:31AM (#7427353)
map / getOrElse is standard in all the Scala code I've seen. Abstracting over the monad is also a pretty big win that has made some big refactorings painless for me. Pattern matching is really only used by beginners IME.
Re:JDK 8 Release Notes by modersky on Wednesday March 19, 2014 @06:04AM (#7427601)
Well, then maybe the beginners do it right? You have not argued against my two points: It's much slower, and less clear.
Re:JDK 8 Release Notes by noelwelsh on Wednesday March 19, 2014 @06:38AM (#7427726)
Clarity comes from familiarity. It's not an objective measure.

The speed benefit is well known, as is the corollary, premature optimisation. I expect checking for null is even faster if speed is the main concern. It's an engineering tradeoff, just like making the abstraction to a monad (or monad plus). In the normal course of events I'm more concerned about flexibility than performance and would prefer the abstraction.