Thanks for the links to the talks. I enjoyed them.
In particular, in "Thinking in Data", Stuart discussed a way to isolate
side effects:
;; Bad
(defn complex-process [state]
(let [result (computation state)]
(if (condition? result)
(launch-missile)
(erase-hard-drive
;; Bet
Well, though your DB is side-effects, your functions that write to it don't
have to be aware of that. That's more a matter of dependency injection,
passing components around, and being careful to return a new object from
each operation.
Once you decouple your components from each other via some k
Following presentations may help
http://www.infoq.com/presentations/Clojure-Design-Patterns
http://www.infoq.com/presentations/Thinking-in-Data
JW
On Thu, Oct 31, 2013 at 3:42 AM, Ben Brinckerhoff
wrote:
> Clojure is the first functional programming language I've used for
> anything more than
Clojure is the first functional programming language I've used for anything
more than toy examples, so I'm learning functional programming in general
as well as Clojure specifically. I understand the value of creating pure
functions in theory, but when writing applications, I'm finding that logi
