You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Very often we run into Option<'T> / null
both None, null, represent something that doesn't exist
I think I've heard some amount of discussions around this matter, such as f# is better because it doesn't have null, such as null is a billion dollar mistake, such as sometimes you still need null to represent something invalid or missing
It's a single value, that's representing, either something gone wrong or something is missing
if your method is returning null, it's likely whatever gone wrong was encapsulated in the method, therefore for you getting a value. if you had side effects in the method that gone wrong and you returned null well something might explode or you threw an exception before doing anything in the method and you are safe because now you can handle the exception and maybe you would then decide yup it's doomed and choose self-destruction -> exit the program -> yet it is still infinitely better than say writing the wrong thing into the database
now in f# we say we build expressions and there's no side effects in the function, we do still have side effects, because at some point maybe at an inappropriate place or maybe eventually we might need to do something, like writing something to the database. so there's also two places we can be looking at the optical scope where null/none can be returned : functions that has no side effects (pure functions in the expression composition) & functions that has side effect.
Now before we are moving forward and look at these cases, I would like to remind ourselves why is it that we have to deal with these values, why can't we just delete null from the language and we never have to deal with them again.
Invalid State.
If you started a program with a valid state, and everything you do is 1+1 then obviously there wont be anything wrong. yet if a program is guaranteed to run forever in valid state on its own, there is no other guaranteed to the program, say for example the cosmic radiation hit its memory and flips a bit.
if external factors are introduced into a valid state, well now it might not be valid. Most oftenly, it's by user interacting with the software
it might still remain intact, although sometimes consider :
let FindSomething (Selection) =
//...
if Found then ...
else ...//what if didn't
People, a pure function simply maps the input to the output with its logics, we can provide the correct input to return the valid output. yet we have to deal with people, that's when we can't guaranteed it's the things we need unless the constrain of valid input of a function is also defined as any by the nature of the function (e.g AI training)
Now if we received null and we are still computing things we can just pass the value on, or optionally we don't care or do nothing and that can be fine
Yet sometimes at some point we must face the fact that we've got null in our hand, it's like a hot potato. in other words, it's a value that should absolutely not be nulled, then the people panic and the kernel panic and the business panic
Because well some method or some operations specifically says they don't accept null or Option.None or any other invalid values, you can choose to do nothing with condition checks and validations and guards, the problem is a program was design to do something and you just absolutely have to deal with it or it's not working anyways. Maybe you can save the UI for it to be responsive, maybe it won't, it depends on what people interpret the state of the program now
Perhaps all invalid states are valid states, because assuming it wasn't the developer who caused it but the user who did, we can pass the responsibility back to the person that's interacting with the program and introduced the external state into the system
However it's frequent that we don't want to piss off the user, who just want things to work, it's reasonable.
So now it comes down to, can we do better when user did something to the program, say entered their passwords or pressed button.
If the input absolutely is unacceptable for the program to do its job, we just don't do the job but don't panic and keep everything in order and don't break the UI's responsiveness, this's damage control
If we can even find a way to make work with the job the program is supposed to do, that's better.
The invalid state however once introduced it won't be gone, you may have done damage control you may have carried on, but it will always reflect back on, either they want you to confirm the email address later, or the video player shows artifacts
We have come a long way
As a developer, to be mindful of how everyone feels, has to, or suffer in chaos caused by unmindfulness, people will, therefore not by running away but face it we shall
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Very often we run into Option<'T> / null
both None, null, represent something that doesn't exist
I think I've heard some amount of discussions around this matter, such as f# is better because it doesn't have null, such as null is a billion dollar mistake, such as sometimes you still need null to represent something invalid or missing
It's a single value, that's representing, either something gone wrong or something is missing
if your method is returning null, it's likely whatever gone wrong was encapsulated in the method, therefore for you getting a value. if you had side effects in the method that gone wrong and you returned null well something might explode or you threw an exception before doing anything in the method and you are safe because now you can handle the exception and maybe you would then decide yup it's doomed and choose self-destruction -> exit the program -> yet it is still infinitely better than say writing the wrong thing into the database
now in f# we say we build expressions and there's no side effects in the function, we do still have side effects, because at some point maybe at an inappropriate place or maybe eventually we might need to do something, like writing something to the database. so there's also two places we can be looking at the optical scope where null/none can be returned : functions that has no side effects (pure functions in the expression composition) & functions that has side effect.
Now before we are moving forward and look at these cases, I would like to remind ourselves why is it that we have to deal with these values, why can't we just delete null from the language and we never have to deal with them again.
Invalid State.
If you started a program with a valid state, and everything you do is 1+1 then obviously there wont be anything wrong. yet if a program is guaranteed to run forever in valid state on its own, there is no other guaranteed to the program, say for example the cosmic radiation hit its memory and flips a bit.
if external factors are introduced into a valid state, well now it might not be valid. Most oftenly, it's by user interacting with the software
it might still remain intact, although sometimes consider :
People, a pure function simply maps the input to the output with its logics, we can provide the correct input to return the valid output. yet we have to deal with people, that's when we can't guaranteed it's the things we need unless the constrain of valid input of a function is also defined as any by the nature of the function (e.g AI training)
Now if we received null and we are still computing things we can just pass the value on, or optionally we don't care or do nothing and that can be fine
Yet sometimes at some point we must face the fact that we've got null in our hand, it's like a hot potato. in other words, it's a value that should absolutely not be nulled, then the people panic and the kernel panic and the business panic
Because well some method or some operations specifically says they don't accept null or Option.None or any other invalid values, you can choose to do nothing with condition checks and validations and guards, the problem is a program was design to do something and you just absolutely have to deal with it or it's not working anyways. Maybe you can save the UI for it to be responsive, maybe it won't, it depends on what people interpret the state of the program now
Perhaps all invalid states are valid states, because assuming it wasn't the developer who caused it but the user who did, we can pass the responsibility back to the person that's interacting with the program and introduced the external state into the system
However it's frequent that we don't want to piss off the user, who just want things to work, it's reasonable.
So now it comes down to, can we do better when user did something to the program, say entered their passwords or pressed button.
If the input absolutely is unacceptable for the program to do its job, we just don't do the job but don't panic and keep everything in order and don't break the UI's responsiveness, this's damage control
If we can even find a way to make work with the job the program is supposed to do, that's better.
The invalid state however once introduced it won't be gone, you may have done damage control you may have carried on, but it will always reflect back on, either they want you to confirm the email address later, or the video player shows artifacts
We have come a long way
As a developer, to be mindful of how everyone feels, has to, or suffer in chaos caused by unmindfulness, people will, therefore not by running away but face it we shall
Beta Was this translation helpful? Give feedback.
All reactions