4 ms·
Currying with map/reduce/filter can be hard to read, but list comprehensions are pretty nice: (defn get-imcomplete-task-summaries [membername] (.then
by jamii 12y ago
Currying with map/reduce/filter can be hard to read, but list comprehensions are pretty nice:
(defn get-imcomplete-task-summaries [membername]
(.then (fetch-data)
(fn [data]
(sort-by :time
(for [task (:tasks data)
:when (= membername (:username task))
:when (not (:complete task))]
task ;; immutable, no need to copy
)))))
It makes me a little sad that functional programming has come to mean map/reduce/filter for lots of people, rather than avoiding mutation which is far more interesting.
- skybrian 12y agoWell, avoiding mutation can be helpful but it's not a rule to be followed blindly either. A mutable local variable never hurt anyone, so long as it doesn't leak out of the function.
- daemonize 12y agoEven in a multiple-thread scenario?
- skybrian 12y agoIf it doesn't leak out of the function (though a closure or a pointer), how can another thread see it? It's only on one stack.
- twic 12y agoAs an aside, one of the really interesting ideas that's bubbling up from Rust is that it's not mutable state that's a problem, it's shared mutable state, and that you can make it safe by removing the sharing, rather than removing the mutability: http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ http://smallcultfollowing.com/babysteps/blog/2014/05/13/focu... I have no idea if this is true, but it's going to be really interesting to see that idea tried.
- CrossEye 12y agoJust to note, the copy wasn't meant to deal with mutability but to note a changed interface. The items that are emitted have only a subset of the properties of those ingested. We could as easily have added some new properties to them as well. Mutability wasn't the primary concern here (although in Javascript it's always a genuine concern.)