[scythe]

Like C++ and Perl, there's a bit of caution required to avoid writing unreadable OCaml code. A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later. IDE support for obscure languages is also often weak or requires extensions or idiosyncratic IDEs which are unfamiliar to many people (and often you want some kind of tool to collapse a 500-line function). OCaml has good vim plugins but not everyone uses vim.

That's my experience with it anyway.

[wtetzner]

> A disadvantage of pattern matching is that it's relatively easy to write a function where you define a variable and then first access it 500 lines later.

I've written plenty of OCaml, and I can't see how this would ever be a problem. Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml. An why would pattern matching cause it?

Maybe I'm misunderstanding something.

[scythe]

> Are you writing 500 line functions in OCaml? It seems like it would be difficult to write such a long function in OCaml.

Me, no; my colleagues, yes. I am averse to writing long functions even more than most people. I agree with 'jldugger that this is a sign that some cleanup is needed but the point is that bad code exists in cool languages too (there are also Mondays in Australia).

[jldugger]

I've done it when writing translators / compilers for school. If you're pattern matching against an AST, its easy to to have a pretty big list of possible types the AST can contain.

Probably this is a code smell that should be rearchitected.

[abhirag]

Haven't used OCaml but the recommended practice in Erlang/Elixir is to break down complex pattern matches into separate function clauses, as function calls are also driven by pattern matching.