Hacker News Reader

Comment by adamkl | Hacker News Reader

> I feel about them the way I do about switch statements - they're brittle and inextensible.

What is meant by this statement is that pattern matching violates the open/closed principal. If you add a new type to switch on, you need to update all the pattern matching code in the whole application to account for the new type.

It’s one of the two sides of the “expression problem”[0] (the other being object oriented polymorphism).

Clojure’s approach to this is to use “multi methods” which is sort of a “pattern matching”/“strategy pattern”. You are free to add in a new implementation of the multi method without having to update existing code

Here is a great post that talks about Clojure’s approach to polymorphism and covers multi methods in detail: https://aphyr.com/posts/352-clojure-from-the-ground-up-polym...

[0] http://wiki.c2.com/?ExpressionProblem

View on HN

I think the artificial shape example does not adequately show how variant types/pattern matching are actually used in languages like SML/F#/Haskell. It combines two different cases.

Suppose you have a type `colour` defined as `RGB(int, int, int) | HSL(int, int, int)` and then you add representation as CIE. Then having to update each match on a colour is absolutely a feature not a bug. If you miss some out then your code will be wrong.

On the other hand, suppose you have various ways of serialization (JSON/XML/s-expressions). In this case, it would probably be nice if you could add a way to serialize to e.g. protobufs without having to jump around your codebase and all its clients fixing type errors. But in most languages of the kind we're discussing, you can do! You just have to represent the different serialization methods in some way other than a variant type. For instance, in OCaml you could just use classes and inheritance (although in practice you probably wouldn't because the language provides nicer tools).

Thanks for the link to Clojure's polymorphism. I'll need to read through it later and in more detail.

Isn't the open/closed principle more of an OOP design concept? In a statically typed language like F#, I want and expect to be notified what functions I need to update when I add a new type constructor to an existing type. This isn't a problem and is welcomed. Just because one updates functions doesn't make them brittle or inextensible. By only adding a new pattern matching branch, one is able to extend a function without affecting the other branches. However, this is getting into the statically typed nature of F#.

I think that link explains the expression problem rather superficially. It says you just need to add a new class, but neglects to mention that that also entails adding the new method overrides. So simply saying the OOP way is easy and functional programming is difficult when adding a new type is not really accurate. Same thing for adding a function in the functional programming paradigm, because it neglects you need to add a branch for all types. In reality, OOP inheritance and functional pattern matching are simply transposes of each other, and I'd argue that one is not really necessarily better or worse than the other. They're simply different organizational methods of how the data and functions on the data are organized.

Reply on news.ycombinator.com