Functions are data (and very cool data, too)

I'd argue that he's using a bad FP approach. He focuses on one aspect of shapes: testing whether a point is inside it or not. But this is far from a complete, usable representation. How do you draw a shape? Find its edge? Find its bounds? Convex hull? Transform? Test for convexity?

Basically, the original post is just another newbie FP realising that - hey - if you're only every going to call one function of a class then the class is completely defined by that function. He presents a poor and incomplete solution.

There are much better blog posts on FP design than this. Please don't upvote this one.

Haskell types do not have an inheritance structure. Typeclasses do, however this still does not allow you to create a heterogeneous list. This is probably a bit terse, but you'd really be better off to go read an introduction to the Haskell type system than to have me try to explain it here.

The OO approach is possible in Haskell using "existential types". However, this is an extension to the language which is rarely used.

The more normal solution is to make a single data type which is a disjunction of all the shapes which you want to deal with.