Also, no, nothing is not the concept of undefined.
You might expect output as an undefined and do a check on it, but things change and later you realize you have to check for a null, an empty object, an empty array.........everywhere your function is called in the code base you'll keep having to add type checks. Either and Maybe let you decide what is your idea of Nothing or Left; and the code all over your app is already prepared for either outcome. Predictable, maintainable, clean. Your function can return a Nothing(/Left) when the output of itself is going to be can be "not a number", "not a string", "not an object of required shape", more power to it!
You might expect input to be a certain way. But the API developer makes a mistake and the app gets weird data; and bam; things break. With ADTs you can make your functions "safe" and have them do Nothing if the input is weird. This is powerful because you don't have to hope anymore; you can be confident things will always be as you expect.
Yes, I will have to add checks. But I have to add checks for this too, the instance of Nothing will have to be returned too for all the empty array, string cases. I get this is more easier to read and understand. But I could as simply check with isUndefined. And if I'm going to wrap every result in an Nothing/Just I could maintain consistency with returning undefined too.
That doesn't happen automatically, have to validate the input. If there's validation logic already, then undefined can be a safe choice too as long my own code knows to expect it.
I'm not against the idea, I just think this is maybe better as a Type in Typescript then a class. No need to complicate which can be just:
Maybe = T | undefined
Or maybe I haven't understood this completely, will have a look at some more articles.
Yeah I don't think I'm able to explain the idea to you well enough; I hope you find the right resources online! Just to set the right context; no; you will not have to add any checks if you're using ADTs and mapping over them. The reason to use them is to remove all these unnecessary checks.
I think is more about returning a meaningful "empty" value, one that doesn't stop execution in unexpected ways. That's half the story, like many patterns in functional programming, this one encourages extension through function composition. Maybe a more practical example could help you see it, I wrote this one last year.
It's a valid question as this post doesn't put Maybe into context. It's very un-clean to litter your code with null checks etc; moreover, it's not very mathematical to have functions that are that unpredictable. Another reason is inversion of control. The ecosystem around Maybe/Either etc in functional JS is enables the caller of a function to do error management independently, outside of that function, i.e. no more try-catches, no more checking types of returned values, just pattern matching on the returned type if it's an Either.
I've been using Ramda long before I started using Eithers and Maybes and ever since I switched to using ADTs my Ramda composition pipelines have become more succinct, more "clean" and more predictable.
Maybe I don't make any sense, But if you read the replies to Drew's comments and go through Brian Lonsdorf's linked tutorial; it will help you discover a new paradigm of making predictable apps with JS that are easier to reason about.
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.
Isn't Nothing just the concept of undefined? What's stopping me from just comparing to undefined
Also, no, nothing is not the concept of undefined.
I'm not against the idea, I just think this is maybe better as a Type in Typescript then a class. No need to complicate which can be just:
Maybe = T | undefined
Or maybe I haven't understood this completely, will have a look at some more articles.
Yeah I don't think I'm able to explain the idea to you well enough; I hope you find the right resources online! Just to set the right context; no; you will not have to add any checks if you're using ADTs and mapping over them. The reason to use them is to remove all these unnecessary checks.
I think is more about returning a meaningful "empty" value, one that doesn't stop execution in unexpected ways. That's half the story, like many patterns in functional programming, this one encourages extension through function composition. Maybe a more practical example could help you see it, I wrote this one last year.
It's a valid question as this post doesn't put Maybe into context. It's very un-clean to litter your code with null checks etc; moreover, it's not very mathematical to have functions that are that unpredictable. Another reason is inversion of control. The ecosystem around Maybe/Either etc in functional JS is enables the caller of a function to do error management independently, outside of that function, i.e. no more try-catches, no more checking types of returned values, just pattern matching on the returned type if it's an Either.
I've been using Ramda long before I started using Eithers and Maybes and ever since I switched to using ADTs my Ramda composition pipelines have become more succinct, more "clean" and more predictable.
Maybe I don't make any sense, But if you read the replies to Drew's comments and go through Brian Lonsdorf's linked tutorial; it will help you discover a new paradigm of making predictable apps with JS that are easier to reason about.