Functional programming explained in Clojure with a terminal-based game

Clojure tends to view mutability as a concurrency problem, and the tools it provides to deal with mutability, such as atoms, refs, agents, channels and so forth, are not mechanisms to avoid mutation, as to provide various guarantees that restrict it in some fashion.

It might be that in the cases where I'd use a state monad in Haskell, in Clojure I might instead use an atom. They're in no way equivalent, but they have some overlapping use-cases.

  (-> state 
      (assoc :a val) 
      (update-in [:b :c] f args) 
      (dissoc :d)
      (some-other-fn args))

Or you could use monads in much the same way as you would in Haskell; there are libs for that.

Or you could write a new macro (or maybe even function) that does exactly what you want. I did that for a game. It looked like this:

  (call-update-fns game-state hook
    (update-monster-positions)
    (update-monster-ai)
    (let-characters-attack)
    (some-other-stuff))

I think most people coming from an imperative background are surprised by how infrequently mutation is actually required. It's worthwhile to explore how far pure functions will take you.

[1] https://www.youtube.com/watch?v=iQwQXVM6oiY

Second, the point of the point of the chapter is to show how much can be accomplished without mutating data structures. I think that's something valuable to focus on. Saying "You can do a lot with pure functions and immutable data structures" is not the same as saying "You'll never need to mutate anything" and as the author, I apologize if my writing suggests otherwise :(

Lastly, Clojure definitely places a huge emphasis on limiting mutability by using pure functions and immutable data structures. I think Rich Hickey even describes pure functions as stable bricks or stable atoms in one of his talks. My impression is that it's definitely not the love child of common lisp and java. Clojure is pragmatic, but that doesn't mean it doesn't place an emphasis on functional programming. I agree that it's "not bogged down in a theory of pure anything", but that doesn't mean it wasn't intentionally designed to support and encourage programming with pure functions and immutable data structures.

In any given Clojure code base, you'll be dealing with pure functions 95% to 100% of the time. Most of the libraries I've written are completely pure, not out of idealism, but because side-effects are simply not necessary.

Yes, Clojure provides tools to limit and constrain mutability, but if you've only recently come from an imperative language, you may be surprised at how little these tools are actually used. Most of the time you're dealing almost exclusively with pure functions, so tools to manage mutability are not necessary.

Discussion of pure functions is certainly idiomatic Clojure, because you'll be dealing them most of the time. Just because Clojure doesn't enforce purity through its type system, doesn't mean you shouldn't prefer pure functions the vast majority of the time.

But obviously summing over a list can be done in one line of code in any decent language even without pattern matching.

    (defn sum-acc
      ([xs] (sum-acc xs 0))
      ([[x & xs] acc]
        (if (nil? x)
          acc
          (recur xs (+ x acc)))))

BTW there should be a macro that adds argument with default value.

On the other hand, viewed as a DSL for the JVM implemented as a Java library or as an evolutionary step in Lisp, Clojure's syntax makes a lot more sense.

Summing over a collection is a one liner in Clojure (as in many other languages):

    => (reduce + (range 10))
    45