3 ms·
Funnily enough, languages with sufficiently advanced type systems can focus almost exclusively on the happy path thanks to functor/applicative/monad. -- It se
by jim-jim-jim 3y ago
Funnily enough, languages with sufficiently advanced type systems can focus almost exclusively on the happy path thanks to functor/applicative/monad.
--
It seems that this comment is controversial and I'm not sure why. I'm referring to the ability to do something like
h <=< g <=< f
in Haskell, compared to a much longer explicit error checking equivalent in Go etc.
- robertlagrant 3y agoWhat does that do?
- jim-jim-jim 3y agoIt's more general than this, but in this example it's a chain of three functions, f, g, h, each of which can fail in the same way. The precise failure behavior is encoded in the types themselves, so there is no need to check for it explicitly in the code. If `f` doesn't work, then `g` won't run, and the failure will be handled as expected by the functions' return types. Maybe they'll return an error message or maybe they'll be a "null" sort of value; the types will tell you, but the chaining syntax itself will always be the same. It's far more common to see this chaining done with `do` blocks but I wanted to keep it all on one line. This lends itself to a clean and optimistic sort of programming. You just write what you want to happen, chained within the broader context of some exception that might occur. So I agree with the parent that static typing makes things faster and easier, but I would argue that most unhappy paths don't require unique attention, and that it's language smell to make you care about them.
- robertlagrant 3y agoThanks! It's hard to imagine how this would work in a complex example that has multiple error paths, but I understand what you mean in the case of same types/one error case. Railway Oriented Programming and all that.