[runeks]

    > I think its because until recently pattern matching and
    > algebraic data types (a more robust alternative to 
    > switch statements) [...]

Could you elaborate a bit on what this accomplishes, eg. pattern matching vs a "case" statement? As I've programmed in Haskell for the past year or two, I've observed exactly this change in my style of writing - that I've started to get rid of "case" statements inside function definitions, and have moved them into the pattern-matching part instead ("outside" the function definition).

But I have to admit, I'm not entirely sure why I do this. It just feels more robust to me in some way.

[ufo]

I was just comparing the pattern matching from FP languages with the more primitive C-like switch statement. The big advantage comes from the algebraic data types (tagged unions), which let you model data with many "cases" in a type-safe manner. For example, in Haskell we don't have null pointers because we can use the Maybe type instead.

The case-expression vs function-definition difference you mentioned from Haskell is just syntactic sugar. In both situations you are doing exactly the same pattern matching under the hood.

[sundarurfriend]

Just FYI, I asked a pretty similar question a few months ago here [1]. The main arguments for pattern matching seemed to be that:

* [at least some] compilers will check for exhaustiveness

* "Pattern matching isn't just conditional matching. It's also binding, and even some common operations. "

[1] https://news.ycombinator.com/item?id=11159321