Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.
This article seems almost entirely concerned with code organization, but in my case I basically never do functional programming and am only concerned about data modelling and data structures. In an adjacent, comment I do acknowledge one point (probably not all software really needs sum types) but I still feel as though languages without sum types are missing an important data and state modelling tool. Trying to take something like a state machine and jam it into interfaces or polymorphism kind of sucks; you lose exhaustiveness checking obviously, but also it enforces a lot of constraints about control flow and data. In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions. Not ideal IMO.
I feel this pain basically any time I hand-write lexical scanners/parsers in Go or even C++.
> I still feel as though languages without sum types are missing an important data and state modelling tool.
That's because they are. jerf subtly shifts the point to one they can criticise, but it does not change the basic fact that sum types are a critical tool which is just... missing.
There's probably no tool which can't be misused, even the humble boolean, that's not an issue with the tool, and pointing that out is at best irrelevant. It does not change the fact of the matter: you're missing a critical axis of composition. It's like saying screwdrivers are useful but you can misuse them to hammer nails as if that justified trying to screw with a hammer.
Where I'd disagree is that they are a tool, not a critical tool, and they aren't missing from Go, they are simply not the preferred choice. You can cover 75% of the use cases with this approach. It is not 100% of the use cases. But there isn't a language where you can cover 100% of the use cases with 100% effectiveness, which is why we don't have and never will have The One True Language.
Moreover, Go seems to attract this sort of criticism as if Go is Uniquely Broken and it's nirvana in all the other languages... but I've used enough of them to know better. Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
> Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
Which other side? Product types (aka structs)? I don't think there are any languages with Sum types that don't also include Product types.
"In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions."
I am not clear what you mean by that, exactly, but generally I model a state machine as a type that composes a state:
type State interface {
isState()
}
// a whole bunch of state types here
type StateMachine struct {
State // exported or not exported, depending on local needs
// additional data
}
func (sm *StateMachine) Event1(args...) error {
// can call current state and change it here
}
You can add an "Execute" method on to the State and have it return an entire state if that's how you want to do it. The state machine can pass in any cross-state data. There's a number of options. You aren't obligated to do exactly, only, and precisely what you'd do in another language, and program X in Y. For some reason, that's common wisdom in the programming world... except for functional programming. I say "don't program X in Y" is simply true and there is no carveout for functional programming in non-FP languages any more than there is the other way around for OO in FP languages.
I guess what I don’t understand about this is sum types represent a state that is so ubiquitous in our lives that it’s hard for me to go a day without seeing one. It’s simply the state of something either is this or that or that. It would be like a language without records. It’s missing a part of reality that shows up all the time
I like how you start the article by deriding this idea of using sum types dogmatically because “FP is Better” (the dogmatic capital-case “Better”, even) and then close the article with a therapeutic angle about making do with what you are given.
> I don't really care if you do or do not stay angry at the language you're forced to work in for your job. What I do want for you is to be able to make the best of the situation you're in and not be unhappy.
Because maybe enumerations in Go are subpar compared to other languages (FP or not).
Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.