[ljm]

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get).

It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

[int_19h]

Given that we're talking about it in a pattern matching context, you'd just pattern match on x vs nil, rather than matching on Just x or None. And in case of Either, you'd match on the types that you expect.

[obstacle1]

An alternative to scattering null checks around or using exceptions for control flow could be more thoughtfully designing your data/object model. No additional language constructs required!

[coldtea]

That attitude is the source of billions of dollars in bugs...

Never manually do the work that the compiler / runtime could do.

You can design "more thoughtfully designing your data/object model" (in other regards) AND have the compiler make sure you're not doing null referencing for you (so that that's not your concern anymore) -- instead of manually and in an ad-hoc way per project implementing another menial responsibility into the design of your model.

[ljm]

What if using those functional concepts is my attempt at thoughtful design? You're making a hell of an assumption with that one.

[jolux]

Yeah I suppose my bigger beef is I just don't like dynamic languages. Perhaps it is in fact a good idea for them, but being someone primarily interested in types, it largely falls into the realm of "don't care."

[coldtea]

Huh? Both Maybe / Optional and pattern matching is used in Haskell, Scala, and other typed languages... It's not about dynamic languages...

[jolux]

If you’ll notice my other comments in this thread, I think you’ll see I vastly prefer statically typed functional languages over dynamic ones. I was more commenting that I like monads and functors and Maybe and Either/Result but don't like dynamic languages.