Oh god, it very well could be.

But in general I find certain languages go the "well, the signature of the funciton actually just implies some properties on the given types so i'm gonna generate a proof obligation and if something goes wrong i'll lowkey just spit that at you", which is annoying

Error: couldn't solve this auto generated equation 😔😔😔

it is!

Based and chewing gum pilled 😌

they really are

any noticable changes from that?

the infusion pump actually sounds nice 😌

whatever could this be inspired by 🤔

So I think the problem he identifies isn't completely baseless, but it's a way more narrow problem than he makes out to be and the jab against typed languages isn't that justified imho.

I like the solution and direction he proposes, although most of that is also applicable outside of clojure imho.

when it comes to having partial information and you may want "not quite legal state" because you're still gathering data and you cannot construct the final thing just yet.

On the one hand, yeah, that's pretty handy. On the other hand, sounds like a symptom of bad design if that happens to you

And declaring a bunch of members as Maybe absolutely runs the risk of making them representable. And the solution he proposes is also applicable to typed languages: split it up. make it smaller. don't demand information you don't need.

the only thing where i'm just ... completely ¯\_(ツ)_/¯ is

The point where Maybe can become tedious, is if you use it in the definition of other datatypes. When you bake the optionality into other data. I actually agree with rich here!

But, i would argue that's bad style anyway in any language. Because you want to make illegal states unrepresentable.

and that's fine! e.g. when you want to find something that may not be there!

and if you have functions that require a Maybe as a parameter, you don't have to! you can just write (like rich suggests) normal functions and if they need to deal with optionality, you can lift them. fmap is real.

In Haskell, it's clear that it's part of Maybe, and only Maybe. So in my opinion, Rich has a point here. Because now we have given the absence of a value a type. and through that we need a value to represent that absence. in that sense, you never really don't have a value now.

I would agree they are ill-suited to express optionality of types. I.e. don't define addition like `+ :: (Either Int Double) -> (Either Int Double) -> (Either Int Double)`. But (good) haskell doesn't do that, you just use typeclasses

Maybe is blurry because what's conceptually the type of Nothing?