Uncle Bob, JSPS: Learing Clojure

Posted by Uncle Bob on 07/19/2009

(JSPS: Just Some Poor Schmuck)

I’m trying to learn Clojure, and I’m finding the effort challenging. Perhaps you can help me.

Programming in Clojure (A derivative of Lisp) requires a certain “inside-out” thinking. I’m finding the combination of the shift in thought process and TDD quite difficult to resolve. So I thought I’d ask for your help.

Below is the Bowling Game written in Clojure complete with unit tests. I’m not at all pleased with the result. The tests, especially, look bizzare and backwards to me.

Please post your own solutions to this so that we can all compare and contrast them.

Tests

(ns bowling-game) (use 'clojure.contrib.test-is) (use 'bowling-game)  (defn roll-list [game list]   (if (empty? list)     game     (roll-list (roll game (first list)) (rest list))     ))  (defn roll-many [game n pins]   (loop [i n g game]     (if (zero? i)       g       (recur (dec i) (roll g pins)))))  (defn gutter-game [game] (roll-many game 20 0))  (deftest can-create-game   (is (not (nil? (new-game)))))  (deftest gutter-game-should-score-0   (is (= 0 (score (gutter-game (new-game))))))  (deftest all-ones-should-score-20   (is (= 20 (score (roll-many (new-game) 20 1)))))  (deftest one-spare   (is (= 16 (score     (roll-many       (roll-list (new-game) [5 5 3])       17 0)))))  (deftest one_strike   (is (= 24 (score     (roll-many       (roll-list (new-game) [10 3 4])       16 0)))))  (deftest perfect-game   (is (= 300 (score (roll-many (new-game) 12 10)))))  (run-tests 'bowling-game)

Code

(ns bowling-game) (defn new-game [] [])  (defn next-two-balls [rolls]   (+ (rolls 0) (rolls 1)))  (defn score-strike [rolls]   [1 (+ 10 (+ (rolls 1) (rolls 2)))])  (defn score-spare [rolls]   [2 (+ 10 (rolls 2))])  (defn score-no-mark [rolls]   [2 (next-two-balls rolls)])  (defn score-next-frame [rolls]   (if (= 10 (first rolls))     (score-strike rolls)     (if (= 10 (next-two-balls rolls))       (score-spare rolls)       (score-no-mark rolls))))  (defn score [game]   (loop [frame 1 rolls game score 0]     (if (> frame 10)       score       (let [frame-score (score-next-frame rolls)]         (recur (inc frame) (subvec rolls (frame-score 0)) (+ score (frame-score 1)))))))  (defn roll [game pins]   (conj game pins))

Comments

Leave a response

• • Jason about 2 hours later:

    • • I think it would probably be more beneficial to focus on clojure tha language and not get hung up on the testing aspect of it at first. You may hate this advise but it will ultimately make more sense in the long run. Functional programming is different and you shouldfocus on that. Testing will follow and make much more sense in time.

  • Auramo about 4 hours later:

    • • One thing you could do is use the let construct more in the tests to name your return values you are asserting against.

  • Auramo about 6 hours later:

    • • After thinking about my previous comment for a while I realize that my advice on let would just introduce clutter unless you extract the actual contents of the original tests to a separate function. Doing that might be overkill.

      • The test-is library IMHO would benefit from xUnit-like functions/macros: is-equal, is-not etc. These are of course trivial to write, but it’s always better to have them in the framework. I quess test-is doesn’t have those because it tries to be as minimal as possible (?)

  • Chris about 6 hours later:

    • • I am also having a bit of a challenge w/ Clojure. I will say that the prag prog Programming Clojure book has been a useful assistant. I have not been able to vocalize specific challenge with it but I believe ‘inside out thinking’ is pretty accurate.

      • Test first is simply the way I think and I perhaps have a more challenging time expressing the idealized API of the code under test. This could simply be a language newb issue, or it could be something else. It could easily be that I can’t really see the cross programming paradigm fp/oo first principles…

      • I think that is likely it; I am having trouble sorting out is precisely what ‘first principles’ are applicable in non-oo languages. These principles are even more difficult to pull out in hybridized oo/ fp languages. In a way I have had an easier time in Haskell than in Scala, F# and Clojure.

      • DRY, small, intention revealing, factored – more cross paradigm rules???

  • Michael Harrison about 11 hours later:

    • • Bob, it’s great to hear you’re interested in Clojure! I hope you enjoy your journey.

      • That “inside-out” feeling you’re having is probably the cause of your unease about the tests you’re writing. Clojure, like Lisps in general, is more about the application of functions to the results of other applications of functions: (roll-list (roll-many (new game).... You may find that in time you get used to these nested parenthetical function applications, and it becomes much faster to parse them mentally. But here are some thoughts on making the test definitions less bizarre.

      • You’re doing what I would do in your tests, creating helpful functions like roll-list, roll-many, and gutter-game so actual deftest expressions are as terse as possible.

      • You could experiment with doing more “setup” work in the defns, or even just making them value definitions:

      • (def gutter-game-score (score (roll-many (new-game) 20 0)))

      • (deftest gutter-game-should-score-0

      • (is (= 0 gutter-game-score)))

      • This might be appropriate if you can’t think of tests that require you to pass an argument other than a new game, and if you’re only focused on scores produced by your code. I think (= 0 gutter-game-score) is a very tidy assertion.

      • As Auramo suggested, you can use let to define values in your tests, to make the actual assertion terser:

      • (deftest one-spare

      • (let [one-spare-score (score (roll-many

      • (roll-list (new-game) [5 5 3]) 17 0))]

      • (is (= 16 one-spare-score))))

      • It’s also likely that test frameworks in Clojure will improve and develop: it’s still early in the game.

      • One other tip for you. I noticed you named ‘one-spare’ with a hyphen and ‘one_strike’ with an underscore. Both are legal names, but you’ll save yourself some trouble deciding on one standard. I mixed the two symbols liberally early in my FP days, and misery briefly ensued as I confronted errors about missing functions.

      • Happy coding!

  • http://twitter.com/arwagner about 12 hours later:

    • • Uncle Bob, I would just make two comments: one, the first two functions in your test code look like classic reduce and map functions, respectively. E.g., something roughly like this: (defn roll-list [game list] (reduce roll (conj game list))) and (defn roll-many [game n pins] (nth (iterate #(roll % pins) game) n))

  • Dave about 12 hours later:

    • • Have you considered using Clojure’s -> macro? It lets you sequence together calls in a way which lets you get rid of the deep, back-to-front function call nesting.

      • Eg:

      • (deftest one-spare   (is (= 16     (-> (new-game) (roll-list [5 5 3]) (roll-many 17 0) score))))

  • Micah Martin about 13 hours later:

    • • A couple guys at 8th Light, including myself, went through this same exercise. My solution is posted athttp://blog.8thlight.com/articles/2009/7/20/bowling-in-clojure

      • I look forward to learning ways to write better clojure.

  • Kjetil Valstadsve about 13 hours later:

    • • Non-OO programming can get “inside-out” if you’re too deeply embedded in OO thinking. Your first warning sign is learning Smalltalk.

      • As for first principles, look for the ground rules for ADT’s. In traditional message-sending-model OO such as Smalltalk and Java, ADT’s are types in hierarchies. They get decorated with methods and their instances send each other messages to get stuff done. In Scheme or Lisp, you define some list structure, and create the ADT by writing the functions that interpret it.

      • Then there is the multiple-dispatch we find in CLOS, and that we find in Clojure too. Message-sending OO is single-dispatch, meaning that each message has a single receiver, used to dispatch to actual methods. Multiple-dispatch means the method is resolved based on more instances. This step from single to multiple basically inverts the whole way you build abstractions. Instead of just thinking about your instances in a hierarchy, you must think of your methods in a hierarchy as well, and it runs off into multiple dimensions very quickly. This means Lispers have infinitely more potential for messing up, but I think they like to stick to the Lisp/Scheme way outlined above.

      • It will be interesting to see which best practices surface in the Clojure community over the next few years, it should be a common ground for many different schools of thought.

  • Stuart Halloway about 13 hours later:

    • • Hi Uncle Bob, glad to see you are looking at Clojure. I am working on my solution over at http://github.com/stuarthalloway/clojure-bowling, and I will post in more detail when I am happy with it.

      • There’s already some pretty interesting stuff there—most importantly, thinking in terms of a sequence of scores instead of just a total.

  • Jim Oly about 14 hours later:

    • • First, I agree with Michael Harrison that the test functions look better if you define values to test and then use them in the test function. I would likely do it this way:

      • This can be done with the other game tests as well, and makes it easier if you want to test different functions over the same game.

• • • roll-many would benefit from the built-in repeat or replicate functions:

      • (defn (defn roll-many [game n pins]   (roll-list game (replicate n pins)))

    • reduce was mentioned earlier as a way to build up a result from a collection. I used it to simplify roll-list, since each call to roll takes a game and a move to make a new game. It’s much nicer than a manual loop and recur when applicable.

      • (defn roll-list [game list]   (reduce roll game list))

      • In fact, I would be tempted to add this functionality into new-game. The zero argument case would return the empty vector as normal, and the single argument case would act as roll-list on a new game:

      • (declare roll) (defn new-game   ([] [])   ([rs] (reduce roll [] rs)))

      • This would subsume some roll-list calls, though roll-list would still be needed for defining the single spare and strike games. You could create the game from any sequence, so both (new-game '(1 2 3)) and (new-game [1 2 3]) would work.

      • (Note: the initial declare is needed since roll is defined later. Moving rollearlier would eliminate the need, but having new-game precede it seems nicer.)

      • I’m still working on the main body of the code, but here are a few other changes I like. In score, instead of using let to hold the result of a score-next-frame call and pick out the pieces later, we can use destructuring to directly pull out and name them. frame-score becomes [rolls-used single-score], and we can use rolls-used and single-score instead of (frame-score 0), etc. Here’s my resulting score:

      • (defn score [game]   (loop [frame 1 rolls game score 0]     (if (> frame 10)       score       (let [[rolls-used single-score] (score-next-frame rolls)]         (recur (inc frame) (subvec rolls rolls-used) (+ score single-score))))))

      • And lastly, I like the style of using cond for multiple condition statements, so I replaced the nested ifs in score-next-frame. I think this is up to the individual programmer, but having all the cases lined up looks nicer to me.

      • (defn score-next-frame [rolls]   (cond (= 10 (first rolls)) (score-strike rolls)         (= 10 (next-two-balls rolls)) (score-spare rolls)         :else (score-no-mark rolls)))

• • Stuart Halloway about 14 hours later:

    • • Ok, I am up to a solution I like reasonably well athttp://github.com/stuarthalloway/clojure-bowling. Here’s the key bits: