A little nitpick: Personally I think that using an Optional<A> is helpful in an untyped setting as well. On the producing side you have a meaningfully named value constructor, which explicitly denotes the created value is optional: Some(x)/None. On the consuming side you need to pattern match, since Optional values are tagged unions. With Optional you always have the Some or the None case. Consequently each use of an Optional value emphasizes its possible absence.
Optional renders the effect of computations that may not yield a result at all explicit. Explicit is almost always better than implicit, right?
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
In languages where Optional is idiomatic I see it as a great staff. As the language itself works greatly with the concept, and far most there is no null concept at all, then I am in. The problem with JS/TS is that there is null, and the whole ecosystem is using it, from core to third party libs. Secondary the language itself evolves into Nullable, in contrary to for example Java which picked Optional.
And yes tagged union has here a benefit that we can make a Functor from it. We cannot make a Functor from Nullable, but we can have kinda substitute which joins map and flatMap in smth similar to Promise.then. So we can make a function chainNullable which will be calling functions until one of them will return null.
About explicit, I don't fully get what you are saying here but with Nullable and TS you are also quite explicit as you see z | null in the types. TS also has optional fields by ? , and this is again idiomatic for Nullable.
For pattern matching, there is nothing like that in JS/TS, but also pattern matching for two cases is not really beneficial. And consumer of Nullable also needs to do the check, and it's not a problem to make an abstraction which also will enforce the else case.
Still the biggest issue I see is - you need to really refuse to use the language and you go into alien concepts from Haskell and others. Don't take me wrong, those concepts are great, but when language has different thing to offer you, it's not so great anymore.
With explicit I was referring to untpyed Javascript. And pattern matching in JS is usually just an ordinary switch statement, which still makes the cases explicit.
I agree that tagged unions in general and my opinion specifically are not mainstream in JS/TS. Maybe the former will change in TS in the future..
Anyway, good post.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A little nitpick: Personally I think that using an
Optional<A>
is helpful in an untyped setting as well. On the producing side you have a meaningfully named value constructor, which explicitly denotes the created value is optional:Some(x)
/None
. On the consuming side you need to pattern match, sinceOptional
values are tagged unions. WithOptional
you always have theSome
or theNone
case. Consequently each use of anOptional
value emphasizes its possible absence.Optional
renders the effect of computations that may not yield a result at all explicit. Explicit is almost always better than implicit, right?In languages where Optional is idiomatic I see it as a great staff. As the language itself works greatly with the concept, and far most there is no null concept at all, then I am in. The problem with JS/TS is that there is null, and the whole ecosystem is using it, from core to third party libs. Secondary the language itself evolves into Nullable, in contrary to for example Java which picked Optional.
And yes tagged union has here a benefit that we can make a Functor from it. We cannot make a Functor from Nullable, but we can have kinda substitute which joins map and flatMap in smth similar to Promise.then. So we can make a function chainNullable which will be calling functions until one of them will return null.
About explicit, I don't fully get what you are saying here but with Nullable and TS you are also quite explicit as you see
z | null
in the types. TS also has optional fields by ? , and this is again idiomatic for Nullable.For pattern matching, there is nothing like that in JS/TS, but also pattern matching for two cases is not really beneficial. And consumer of Nullable also needs to do the check, and it's not a problem to make an abstraction which also will enforce the else case.
Still the biggest issue I see is - you need to really refuse to use the language and you go into alien concepts from Haskell and others. Don't take me wrong, those concepts are great, but when language has different thing to offer you, it's not so great anymore.
With explicit I was referring to untpyed Javascript. And pattern matching in JS is usually just an ordinary switch statement, which still makes the cases explicit.
I agree that tagged unions in general and my opinion specifically are not mainstream in JS/TS. Maybe the former will change in TS in the future..
Anyway, good post.