I’ve sometimes wondered about the wisdom of running dojos in newer languages but this one worked quite well because Cam has been learning Groovy and he was able to point us in the right direction when we started writing Java-esque Groovy code. The particular syntax that I didn’t know about was that you can define and put items into a list in a much simpler way than in Java: I was starting to write code like this: _~groovy def frames = new List() frames.Add(frame) _~ Which Cam simplified down to: _~groovy def frames = [] frames << frame _~ I didn’t feel that I missed the static typing you get in Java although IntelliJ wasn’t quite as useful when it came to suggesting which methods you could call on a particular object. </li> I’m even more convinced that using various languages functional equivalent of the 'for each' loop, in this case 'eachWith' and 'eachWithIndex' is not the way to go and we could see our code becoming very complicated when trying to work out how to score strikes thanks to our use of it! I think we actually got further this time in terms of the implementation although we did slow down when it came to scoring strikes to try and work out exactly how we wanted to do it. Prior to this we had been following the idea of just getting the tests to pass and driving the design of the code that way but we at this stage it seemed foolish to keep doing that as the code would increased dramatically in complexity by doing so. The two approaches we were thinking of involved using the state pattern to determine what the current frame outcome was and then work out the cumulative score based on that by looking forward to future frames or an approach that would make use of functional collection parameters (not sure exactly which ones!) to calculate the score in a more function rather than OO way. </ul>

We’ll probably keep going with some more Groovy as it’s actually more interesting than I thought it would be. I’m also keen to do a coding dojo where we never make use of the if statement.