@fristi@56k.dile-up.nl null isn’t an integer, and neither is false!
-
@fristi@56k.dile-up.nl null isn’t an integer, and neither is false! How can you differentiate between false/null-that-is-there-on-purpose and the coincidental “not found” null? This lets you do that
In fact, procedural languages tend to emulate this, think about the typescript ?. for example, or the C# Nullable (both of which are kind of nerfed functors)What FP is good about is about making the flow of the program closely correspond to the way you think / would explain the flow
For example, you could do something like this:
makePrimes x = x # (2^x)-1 is likely-ish to be prime |> map(pow(2)) # raise 2^x |> map(-1) # -1 |> filter(prime?)In a procedural language you would need to have a much bigger comment block at the top that explains the approach, and then hope that it stays up to date over time.
In an OO language you kind of just lose track of “how you even get to the right answer”.
In FP if done right it’s self evident and present there, and you can immediately skip to thinking about the thing you’re actually trying to do and potential improvements to the algorithm, rather than fighting with the language to get the result at all -
@fristi@56k.dile-up.nl null isn’t an integer, and neither is false! How can you differentiate between false/null-that-is-there-on-purpose and the coincidental “not found” null? This lets you do that
In fact, procedural languages tend to emulate this, think about the typescript ?. for example, or the C# Nullable (both of which are kind of nerfed functors)What FP is good about is about making the flow of the program closely correspond to the way you think / would explain the flow
For example, you could do something like this:
makePrimes x = x # (2^x)-1 is likely-ish to be prime |> map(pow(2)) # raise 2^x |> map(-1) # -1 |> filter(prime?)In a procedural language you would need to have a much bigger comment block at the top that explains the approach, and then hope that it stays up to date over time.
In an OO language you kind of just lose track of “how you even get to the right answer”.
In FP if done right it’s self evident and present there, and you can immediately skip to thinking about the thing you’re actually trying to do and potential improvements to the algorithm, rather than fighting with the language to get the result at all@toast @fristi JavaScript's Promises are also a good example of "kinda monads" which even get a special syntax similar to Haskell's
doblocks: async/await. This feature also exists in other languages such as C#.
It's pretty good evidence of the usefulness of monads because asynchronous operations used to be a nightmare with callbacks upon callbacks, but Promises and async/await allow us to concentrate on the actual functionality at hand.
