Functional programming explained in Clojure with a terminal-based game

http://www.braveclojure.com/functional-programming/?again

by yawz • 12 years ago

100 30 12 years ago

platz• 12 years ago

I'm sure this is great walkthrough. Although I'd like it if there weren't headlines like "FP explained".

I realize this may be pedantic, but If I've learned anything about FP, the term means different things things to different people, and a statement which makes universal claim about FP In General then will misrepresent the other flavors of FP.

At least qualify it somehow. Actually, why not just say something like "Terminal-Based Game Walkthrough in Clojure"?

phren0logy• 12 years ago

Maybe I'm a "glass is half full" kind of guy, but explaining one kind of FP (rather than all of them) still counts as "FP explained" in my book.

ch4s3• 12 years ago

I agree. I think of it like 'x' explained (from 'y' perspective or with reference to 'y'). e.g. 'Woodworking Explained, master the lathe"

coffeeyesplease• 12 years ago

This site is an amazing resource. Higly recommend it if you want to learn Clojure

rabino• 12 years ago

Thanks! This was awesome to visualize some abstract concepts I've read about but never implemented.

brudgers7• 12 years ago

I've started diving into Clojure...or rather drinking it's Joy from the firehose due to a birthday Barnes and Nobel gift card used for Fogus in the first edition [I'm cheap]. To me, this discussion of pure functions is distinctly not Clojuresque. Clojure is the Love Child of Common Lisp and Java™ both of which are distinctly pragmatic languages and neither of which is bogged down in a theory of pure anything.

Clojure is structured to limit mutability to allow for reasoning about state in an environment with concurrent processes, but it expects this reasoning to be done in the context of professional programming, not the ivory tower of academics. It's idea of functional programming is in the history of Common Lisp, and a good description of it is given by Graham in chapter 3 of On Lisp:

http://unintelligible.org/onlisp/onlisp.html#SEC23 or http://www.paulgraham.com/onlisptext.html

Essentially, the idea is to isolate mutation - just like Haskell and for exactly the same reasons but without an explicit proliferation of types.

So long as we have von Neumann machines, we're going to have mutation. The goal is to abstract as much of it away as possible to facilitate the management of state. But it never goes away, and we shouldn't imagine or try to convince ourselves that that it does...nor that it should, completely.

Polemic over; still a good article and worth a read. Certainly got me thinking.

prospero• 12 years ago

All true (I gave a talk on this subject just recently [1]), but the easiest and most provable way to isolate mutation is to not use it at all.

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

brudgers7• 12 years ago

From farmer's pen to plate, now I know where sausage comes from. I enjoyed the presentation, thanks.

While I have found it improved my understanding of functional idioms when I explained them to others, I believe I am more helpful if I point people directly toward Hickey and Graham and PLT. I can paraphrase The Value of Values but it's better watched without translation.

nonrecursive5• 12 years ago

I think you may be misunderstanding a few things, and I hope I can clear them up :) First, the term "pure function" does not imply "ivory tower" any more than "recursion" does. Pure functions are tools that allow you to "isolate mutation". In fact, Paul Graham mentions that experienced lisp programmers "try to segregate side-effects in a few functions, allowing the greater part of the program to be written in a purely functional style" (http://unintelligible.org/onlisp/onlisp.html#SEC27). So - don't let the terminology throw you :)

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.

brudgers7• 12 years ago

The article well written. It didn't throw me or make me confused. I simply was bothered by the lack of nuance in regard to mutation. Trillions of pixels have been burned describing pure functions and giving small examples of immutability and recursion. Trees have even been killed.

What makes Chapter 3 of On Lisp or SICP useful is they're Third Acts. They go deeper than pure functions. They're pivotal because that's where we start talking about the messy world where mutation is necessary. It's where we admit that there's a rationale for the way Java works even if it's implementation could stand improvement.

What makes Clojure interesting is the way in which it implements that depth. Lisp went on a journey to Java and was transformed by the experience. Clojure is not just another Lisp - that side of the family has always had shared structure and a propensity for functions. There's `is` and 'testing` and agents and vars and `.` and `..`. JavaScript the good parts is a book. Java the good parts are in Clojure. Clojure is an Act V not an Act I.

weavejester2• 12 years ago

I've been developing in Clojure for a while now, and I think your characterisation of the role of pure functions in Clojure is somewhat inaccurate.

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.

thinkpad20• 12 years ago

How does Clojure handle piping state through a series of functions? Is there anything like monads in Haskell to abstract it away? Haskell makes immutable data a little bit more tenable because you don't need to explicitly thread your state. How does Clojure handle this? Does it provide escape hatches for mutable state, perhaps restricted to using Java libraries?

weavejester2• 12 years ago

Clojure has libraries that implement monads, but these aren't often used for threading state. I can't quite place my finger on why, but in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell.

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.

oskarkv2• 12 years ago

For very simple cases there are the threading macros, `->` et al., that you can use like this:

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

where :a - :d are keys.

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))

It would thread the game-state (immutable) through all the functions, and call hook (a function) in between all the functions to send network messages and stuff (to minimize latency), and also collect and return new events that the functions created that I needed to handle (e.g. someone died when the characters attacked). It's almost like the state monad but not quite.

muhuk• 12 years ago

And there's synthread[1] for more complex cases:

   (-> {:a 1 :b 2}
     (->/assoc :a inc)
     (->/as {:keys [b]}             
       (->/when (> b 10)
         (->/assoc :large-b true))))

1: https://github.com/LonoCloud/synthread

sgeisenh• 12 years ago

Does anyone else find Clojure's syntax a bit obtuse? I feel like basic recursive definitions are much clearer in Haskell and ML. To sum over a list using an accumulator shouldn't take more than two or three trivial lines of code.

LordQuas3000• 12 years ago

Nobody would actually implement an accumulator that way. He gave a super simplistic example to illustrate recursion.

technomancy• 12 years ago

It's definitely unfortunate that Clojure doesn't ship with pattern matching out of the box, but there's a library that implements pattern matching macros.

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

oskarkv2• 12 years ago

No. I love it. It's so simple. Even if Haskell has pretty nice syntax, I found myself resenting it because I needed to remember operator precedence.

ajuc• 12 years ago

Pattern matching would be nice, but destructuring helps.

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

Could you show Haskell equivalent?

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

malisper• 12 years ago

I believe it should be something along the lines of:

  sumacc xs = summer xs 0
    where summer [] n = n
          summer (x:xs) n = summer xs (x+n)

I'm sure there are macros in some library somewhere that implement pattern matching in lisp (regardless of dialect).

brudgers7• 12 years ago

Yes, and no. Viewed as a Lisp, it trades some simplicity for practicality, e.g. vectors rather than lists as the container for arguments to a function. Neither than `lambda` template for Common Lisp's `defun` macro or the "usage" template for Scheme's `define` are consistent with the overall language syntax because the list should be quoted or executed.

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

Clojure's dynamic typing trades simplicity of syntax for the static typing safety harness required in ML or Haskell.

Functional programming explained in Clojure with a terminal-based game

Related Stories