Hacker News new | ask | show | jobs
by sifoobar 2697 days ago
I'll take structs and multiple dispatch [0] over both of those any day. Raw FP is too primitive and OOP mixes too many concerns, multiple dispatch strikes a nice compromise between the two and offers additional flexibility.

While Common Lisp's CLOS is often referred to as OOP, it's definitely less coupled than single dispatch.

[0] https://gitlab.com/sifoo/snigl#functions

3 comments

Right. Multiple dispatch (the version of OOP that is most suitable for FP) is far superior to classic OOP.
I can't imagine what makes FP too primitive. It is essentially abstract. FP's degree of being primitive depends on the coarseness of its combinators.

What I find limiting is easy access to efficient, immutable data structures. Ocaml leaves you with the option to switch to mutable data structures at the cost of safety, and Haskell provides things like the ST monad for handling mutable updates safely at the cost of type-level complexity.

The post drew a line between OOP and FP; for that line to mean anything, polymorphism would have to go with OOP. Which is what I meant by raw FP.

And solving the same kind of problems without polymorphism (be that multiple dispatch, type classes or otherwise), is a struggle.

Polymorphism doesn't require anything to do with OOP or objects themselves, see clojure multi methods as an extremely pure example that involves nothing even close to an object.

Protocols or typeclasses are also ways to implement functionality over (usually) immutable data. I don't see the relation to a mutable object with a closed set of methods defined at compile time.

I didn't make the distinction, the post sort of did between the lines.

Go back to my original comment and you'll see that multiple dispatch is what got us here.

I never said anything about mutable/immutable data, I'm talking about polymorphism. But I did mention type classes as an alternative.

I frankly fail to see how this is leading anywhere.

Please do correct me if I am wrong, but isn't multiple dispatch basically typeclasses + pattern matching?
But that would still be single dispatch, right?

Multiple dispatch means functions are generic, and all arguments are considered when deciding which implementation to call.

Snigl supports both multiple dispatch and pattern matching, as does Common Lisp.

Haskell type classes by default pick the implementation based on a single type variable in its signature, but it can occur in multiple positions (including the return type). A commonly used language extension (multi parameter type classes) extends this to an arbitrary number of type variables.
As far as I know, all of the arguments are considered when deciding which implementation to call on typeclasses.