4 ms·
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 an
by tree_of_item 9y ago
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.
- masklinn 9y ago> 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.
- infinite8s 9y agoTo make it concrete, it's like 90% of all programmers are trying to do basic algebra with just multiplication available.
- alkonaut 9y agoAll 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.