[dozzie]

>> that can be easily replaced with similar constructs

> Mind giving an example?

You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values.

I've never seen in imperative languages anything similar to conditional that checks both type and content of an expression, and allows to capture parts of that expression into variables. Well, except for precisely the pattern matching construct, where it was implemented deliberately after functional and declarative languages (Rust).

>> Using a not very popular programming language can actually make it harder for you to hire people.

> Do you really want to work with people who can't learn a tiny little language?

I see things a little differently. It's extremely difficult to find an idiot who can write OCaml, while it's fairly easy for C++, Java, or C#.

Also, allowing people to learn OCaml and use it every day on the job is a big plus for a company. It's way better than free sandwitches for breakfast in the long run.

[loup-vaillant]

> You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values.

That's dynamic typing. Very different from pattern matching over sum types: with dynamic typing, you can basically forget about most compile time guarantees. Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?". I can tell you from first hand experience that they do not feel the same at all.

The other classic example, class hierarchies, is also very different from pattern matching —and much more cumbersome. The only language I know of that kinda bridged the two is Scala, with case classes.

[dozzie]

> That's dynamic typing.

No, that's run-time branch selection. Exactly as with pattern matching (`match .. with ..'), except the latter is more convenient.

> Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?".

And you really think I consider elaborate constructions a better thing than concise pattern matching?

[sklogic]

> Exactly as with pattern matching

With pattern matching you'll get static checking if your matching is exhaustive. Impossible with an if ladder. Therefore they're not semantically equivalent.

[dozzie]

Static checking of a variable, value of which is determined in runtime? How can you do that?

[dragonwriter]

Statically checked pattern matching validates that the provided patterns cover all possible values the variable could have (the whole space of the variables declared/inferred type). So the actual runtime value is not necessary: if the match is exhaustive, there is no possible value that could be taken at runtime that would result in no match.

[sklogic]

  type 'a myOption = Some of 'a | None
  let f (Some x) = x*x

Gives this output:

  Warning 8: this pattern-matching is not exhaustive.
  Here is an example of a value that is not matched:
  None

[dozzie]

Oh, now I see what you meant. But this has little to do with selecting the branch, what I was talking about the whole time.

[rlander]

You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values.

That's nowhere near pattern matching. Two concepts make pattern matching vastly superior to if-else constructs:

- Non-exhaustive checks by the compiler.

- Destructuring

[dozzie]

Oh, look, non-exhaustive checks are exactly as with if-else. And no, `match .. with' cannot be calculated in compilation time typically. Poor argument.

It's being a combination of destructuring, branch selection and variable assignment that makes pattern matching superior.

[sklogic]

You can also do it in Brainfuck if you like, with an equivalent code bloat. Pattern matching is an order of magnitude more readable and dense than the if ladders.

As for the hiring, it is a silly idea in general to seek "programmers in XXX language" (and to position yourself as an XXX programmer). Hire programmers. Just programmers. Languages are irrelevant.