wizao
Re:Kotlin: The Problem with null
on Friday January 12, 2018 @10:19PM (#16138108)
I know you have got a TON of replies demonstrating better ways to check if a value is null or not.
I believe they are all missing the point. In a language with monads, Option's should not be part of the function signature unless it is important to the logic of that function. Your given example should look like:
func1(a: i32, z: i32) -> i32 {
return a + z
}
I know it's not 1 to 1, but the idea is there. You would then use a tiny bit of glue code to combine all the stuff you have to get what you want. For example, if you have 2 nullabes as parameters, you use liftM2; if you have 1 nullable, you use liftM; or perhaps you just want reduce a structure, so you reach for foldM. etc. If your monadic code has to constantly figure out what monad it is, you aren't buying yourself much and I could see why you don't find them valuable. And if the function explicitly needs an Option, then it must be important and must be taken into consideration by the caller. I just don't think they should force the caller to consider them where not needed.I wanted to mention I often see similar statements with almost the identical code comparison that you made. I believe it has to do with retraining oneself to think functionally instead of imperatively. I'm curious about your background.
For good measure, here's another example in Haskell:
func1 a b = fromMaybe 0 (liftM2 (+) a b)
And an uglier, but fun, point-free version: func1 = (fromMaybe 0 .) . liftM2 (+)
I believe real-world examples would hold up better because the glue code would only be where needed.
Re:The False Trade-Off Between Security and Liberty
on Monday October 26, 2015 @02:42PM (#10453467)
These security measures can backfire too:
http://time.com/3760424/germanwings-plane-crash-locked-cockp...
Re:Currying in JavaScript
on Sunday July 19, 2015 @10:53PM (#9913796)
Re:Lodash v3.0.0
on Tuesday January 27, 2015 @10:53AM (#8953664)
There is an excellent talk called "Underscore, you're doing it wrong!". The talk explains how well designed param order with currying leads to very short and expressive code -- and how underscore missed the boat. This aspect of it should be interesting as it's related to this post. It's well worth the watch.