Functional programming has won all the technical and theoretical battles (at least, most functional programmers think so!), but it’s losing the war on adoption.
He might be only half-serious, but this (and the article in general) seems a little presumptuous for someone who only “picked up Python and Go … in 2014” and only started learning about a functional programming languages “this fall.”
Also, regarding null dereference bugs, a symptom of failing to exhaustively check cases, it seems like Haskellers actually are more lax about exhaustiveness than, say, OCaml developers.
Cool article nonetheless, but the preachiness of functional programmers (even when I use functional programming) gets tiring.
I have a lot of respect for Ron Minsky, but that claim about Haskell is, at least, out of date. (The post is from 2009.) I’m pretty sure you can get a compiler warning about non-exhaustive pattern matching.
There are idioms that require non-exhaustiveness (and would raise warnings). Namely, if you’re destructuring something and you know which branch of a union type it is, e.g.
(Just x)
There are also monad-specific instances that rely on fail, generally held to be a mistake except for this idiom. For example, you’ve got this:
That’s because fail _ = [] in the list monad. One can debate whether that’s the right way to do things… but it’s a case in which you might want non-exhaustive matching because the monad “knows the right thing to do” (and it’s not a runtime blow-up).
I’m pretty sure you can get a compiler warning about non-exhaustive pattern matching.
I think that GHC always had the ability to warn about non-exhaustive pattern matching, but the point is that this warning is not activated by default. A warning that people do not see (or that only advanced, opinionated users that decide to change warnings to fit their programming style and safety desires) has much less effect on the general community style that a warning that is enabled, or even marked as an error by default. The OCaml compiler has always warned about inexhaustive pattern matching, and as a result its uses are frowned upon by the OCaml community.
This is a qualitative difference, and I believe that, contrarily to what you say, it is still a relevant difference today. Note that there has been nice work recently on improving the exhaustivity and usefulness checking of GHC in presence of GADTs or guards (GADTs meet their match, by Georgios Karachalias, Tom Schrijvers, Dimitrios Vytiniotis, Simon Peyton Jones, 2015), so this trend might be changing.
Your example of monadic comprehension only suggests that non-exhaustive patterns in monadic comprehension should not warn. It is very clear that non-exhaustive patterns in monadic comprehension are of different nature, as (1) the syntax does not easily allow making this pattern exhaustive and (2) there is a well-defined semantics of what happens in case of failure. This is unlike non-exhaustive patterns in direct matching constructs, where a match failure should be understood as a programmer error. So the monadic comprehension does not justify not warning by default on non-exhaustive patterns in direct matching constructs.
Another way to phrase my remark is that programmers understand that non-exhaustive patterns in monadic comprehensions get desugared to an exhaustive pattern, with a | _ -> fail fallback, so these patterns should not be considered non-exhaustive.
Another way to phrase my remark is that programmers understand that non-exhaustive patterns in monadic comprehensions get desugared to an exhaustive pattern, with a | _ -> fail fallback, so these patterns should not be considered non-exhaustive.
That’s a really good point. It’s not always a partial function; it’s a total function in the cases where fail _ isn’t ⊥.
Cool article nonetheless, but the preachiness of functional programmers (even when I use functional programming) gets tiring.
More precisely, the parts that are irritating in the article are the following:
It’s not a journey for the dabbler or the faint of heart, but it’s one that’s worthwhile.
Implying that it is good for something to be difficult is generally a bad idea. It may come across as showing off, and it can discourage less confident people from giving it a try.
Functional programming has won all the technical and theoretical battles (at least, most functional programmers think so!), but it’s losing the war on adoption.
I find the use of “battle” and “war” in a technical discussion to be a red flag. Besides, the underlying claim is naive and over-simplifying.
He might be only half-serious, but this (and the article in general) seems a little presumptuous for someone who only “picked up Python and Go … in 2014” and only started learning about a functional programming languages “this fall.”
Also, regarding null dereference bugs, a symptom of failing to exhaustively check cases, it seems like Haskellers actually are more lax about exhaustiveness than, say, OCaml developers.
Cool article nonetheless, but the preachiness of functional programmers (even when I use functional programming) gets tiring.
I have a lot of respect for Ron Minsky, but that claim about Haskell is, at least, out of date. (The post is from 2009.) I’m pretty sure you can get a compiler warning about non-exhaustive pattern matching.
There are idioms that require non-exhaustiveness (and would raise warnings). Namely, if you’re destructuring something and you know which branch of a union type it is, e.g.
There are also monad-specific instances that rely on
fail, generally held to be a mistake except for this idiom. For example, you’ve got this:That’s because
fail _ = []in the list monad. One can debate whether that’s the right way to do things… but it’s a case in which you might want non-exhaustive matching because the monad “knows the right thing to do” (and it’s not a runtime blow-up).I think that GHC always had the ability to warn about non-exhaustive pattern matching, but the point is that this warning is not activated by default. A warning that people do not see (or that only advanced, opinionated users that decide to change warnings to fit their programming style and safety desires) has much less effect on the general community style that a warning that is enabled, or even marked as an error by default. The OCaml compiler has always warned about inexhaustive pattern matching, and as a result its uses are frowned upon by the OCaml community.
This is a qualitative difference, and I believe that, contrarily to what you say, it is still a relevant difference today. Note that there has been nice work recently on improving the exhaustivity and usefulness checking of GHC in presence of GADTs or guards (GADTs meet their match, by Georgios Karachalias, Tom Schrijvers, Dimitrios Vytiniotis, Simon Peyton Jones, 2015), so this trend might be changing.
Your example of monadic comprehension only suggests that non-exhaustive patterns in monadic comprehension should not warn. It is very clear that non-exhaustive patterns in monadic comprehension are of different nature, as (1) the syntax does not easily allow making this pattern exhaustive and (2) there is a well-defined semantics of what happens in case of failure. This is unlike non-exhaustive patterns in direct matching constructs, where a match failure should be understood as a programmer error. So the monadic comprehension does not justify not warning by default on non-exhaustive patterns in direct matching constructs.
Another way to phrase my remark is that programmers understand that non-exhaustive patterns in monadic comprehensions get desugared to an exhaustive pattern, with a
| _ -> failfallback, so these patterns should not be considered non-exhaustive.That’s a really good point. It’s not always a partial function; it’s a total function in the cases where
fail _isn’t ⊥.More precisely, the parts that are irritating in the article are the following:
Implying that it is good for something to be difficult is generally a bad idea. It may come across as showing off, and it can discourage less confident people from giving it a try.
I find the use of “battle” and “war” in a technical discussion to be a red flag. Besides, the underlying claim is naive and over-simplifying.