Hacker News Reader

Comment by bitL | Hacker News Reader

Seems like a design pattern from Java which often are badly converted functional programming snippets into OOP. I once loved C++, now I can't force myself to read the code anymore... Please add some monads there to destroy my hope for humanity once for all!

I think maintainers of C++ have a case of "functional programming" envy.

View on HN

They should have FP envy if their language doesn't have a simple and clean looking way of defining that a value is either a T or a U. Inheritance in the normal sense doesn't cut it because that defines an open (for extension) set of subtypes. You can't e.g compile time check that a switch/match has tested all cases.

If you want to make a closed set of subtypes that's usually possible only by writing a class hierarchy with private subtypes and an abstract outer type with factory methods for the inner types. That takes hundreds of lines for even just a couple of variants, and then there is still no compiler help for exhaustive switch/match.

Why should C++ as an imperative/OOP language ape everything possible in FP? It feels like when FP languages slap on OOP for a change. C++ wasn't designed with what we call FP these days in mind, so unless it's going to change drastically, there will always be "smell".

FP doesn't have many things C++/D etc. have. Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?

It doesn't need to ape everything possible in every FP language. Just sum types. To me, "closed type hierarchies" are a pretty fundamental thing in programming regardless of how they are represented (OO style subclasses or otherwise), perhaps more important and fundamental than other FP things such as closures/lambdas (which Java, C# and C++ all adopted).

It's already possible to make the class hierarchy in most/all OO languages but it takes 150 lines for what can be expressed in 5 with some help from the language. Most importantly, without lang support the compiler can't validate exhaustive matching.

Sum types are not "everything possible in FP". I'm part of the group that views sums as an extremely basic language feature and I give an extreme side-eye to any language that still doesn't have them in the current year.

> I'm part of the group that views sums as an extremely basic language feature

More importantly it's the second category of type relations. There are product types and there are sum types, if you only have product types, you're missing an entire half of expressible type relations/compositions.

It's not a matter of functional versus imperative, there's nothing inherently functional about sum types.

All OO languages have sum types in a way, but it's just not a very good way. If there is no data or only integer data it's usually called "enum" and if it's a more complex data structure then it's a class hierarchy. It's just really clumsy in most OO languages to type out "type PaymentMethod = Cash | CreditCard(CardDetails d) | Invoice(Address a)"

In OO it's "abstract class PaymentMethod" and then another 100 lines, plus probably a horrible visitor pattern (because you don't want the payment method handling the payment). This to just define the type, no actual payment logic.

Huge amounts of boilerplate, and very little power if the compiler can't ensure exhaustive matching.

To make it concrete, it's like 90% of all programmers are trying to do basic algebra with just multiplication available.

> Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?

yes. all the languages should converge (and the relevant ones actually do)

Discriminated union is low-level pattern from non-OO languages (it is common pattern in C, Pascal has syntax for this and IIRC unions are always discriminated in "standard" Pascal)

In object oriented languages this pattern is mostly unnecessary, because inheritance is usually better solution for the same problem. Only reason to use something like this in C++ is (maybe even only perceived) efficiency gained by removing level of pointer indirection.

The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former.

It really comes from functional languages like ML, and is extremely useful and convenient when combined with pattern matching. In fact, attempts to emulate it in OOP using interfaces and visitor pattern tend to bring a lot of boilerplate, and obscure the actual logic, which is exactly what the author is complaining about.

There's definitely more reason to use it than just "efficiency gain", which is why many languages introduced in the last decade have it built in (e.g. Rust, Scala or Swift).

> The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former.

Could you say something about the difference between the two? I'm not aware what it is.

Edit: wow I accidentally a word.

IIRC discriminated unions are plain C(++) unions with an added type tag, like at the beginning of the article. Brittle, prone to breakage when refactoring, etc. when compared to real sum types.

Actually, the article says, "A sum type, also called a discriminated union..."

I'm really curious, I write a lot of python, and find myself wishing for sum types all the time. How do you see inheritance filling the same space? I'd love to be able to do something like:

    data Choices = Good | Bad | Ugly

like I can do in haskell, where a value of type `Choices` can only ever be one of those options. But there doesn't seem to be any reasonable approximation in python.

The OOP pattern dfox is referring to would look something like this:

    class AbstractChoice:
        # defines all common operations on choices
        # plus potentially some useful stuff on top of those
        pass
    class Good(AbstractChoice):
        # conatins the code specific to good things
        pass
    class Bad(AbstractChoice):
        pass
    class Ugly(AbstractChoice):
        pass

This isn't a straight-on replacement though. It's especially bad when you want to separate your concerns not along the good-bad-ugly-axis but something different (which is when you'd e.g. go on to use mixins, or that ugly visitor pattern we've seen in the OP).

Reply on news.ycombinator.com