Fabio and I worked on the Scala solution to the problem and we were pretty much playing around with different ways to aggregate all the values in the list: _~scala 1.to(999).filter(x => x%3 == 0 || x%5 == 0).foldLeft(0)acc,x) => acc + x) 1.to(999).filter(x => x%3 == 0 || x%5 == 0)./:(0)((x,y) => x+y) 1.to(999).filter(x => x%3 == 0 || x%5 == 0).foldRight(0)(+) 1.to(999).filter(x => x%3 == 0 || x%5 == 0).reduceLeft(+) 1.to(999).filter(x => x%3 == 0 || x%5 == 0)./:(0)(+) _~ We decided to work through how 'foldLeft' and 'foldRight' work for summing a simpler collection of data, the numbers 1-5, which goes something like this: fold_left _~text (((((0 + 1) + 2) + 3) + 4) + 5) = 15 _~ fold_right _~right (1 + (2 + (3 + (4 + (5 + 0))) = 15 _~ When adding the numbers together it doesn’t make any different whether we fold the collection from the left or from the right. If we do subtraction we do get different answers though: fold_left _~text = 3 -> 5 - 0 = 5 -> 4 - 5 = -1 -> 3 - -1 = 4 -> 2 - 4 = -2 -> 1 - -2 = 3 _~ The other way of doing fold_left, '/:', is quite interesting although perhaps unintuitive when you first come across it. Liz showed me an interesting post by Ricky Clarkson where he talks about this method and the reason why it’s in the language. Liz and Dave Yeung worked on doing a solution to lambdaj to the problem but it ended up being quite verbose so we decided to play around with Scala for the rest of the session.

We spent a bit of time playing around with traits via a nice introductory article which effectively acts as a a cut down version of the Programming in Scala book. I particularly like the way that you can add a trait to an instance of an object and you get access to all the methods defined on that trait which seems quite similar to Ruby mixins. Liz and I were discussing an article written by Michael Norton comparing technical debt and making a mess so that’s where the trait name came from! _~scala trait Mess { def makeMess = print("tech debt is so funny") } class Liz { } _~ If you try to make use of the trait like this: _~scala val liz : Liz = new Liz with Mess _~ You don’t have access to the 'makeMess' method since you explicitly defined the type to be 'Liz' which doesn’t have the method: _~scala liz.makeMess > error: value makeMess is not a member of Liz liz.makeMess _~ If we let the compiler do its thing without trying to explicitly type the value it works much better: _~scala val liz = new Liz with Mess > Liz with Mess _{~ ~}scala liz.makeMess > tech debt is so funny _~ I really like having the ability to do this although I think I need to code a bit more Scala before I’ll appreciate where we really gain by having this feature. The conciseness of the language and the lack of '{}' while keeping the same expressiveness in the code is something which reminds me a lot of F# and from what I’ve seen so far I imagine it would be much more fun to code in Scala than in Java. It also seems more clear to me that when a static language has really good type inference then one of the main reasons that people prefer dynamic languages - you get to write less code for the same amount of features - is actually much less valid.

This was a very experimental dojo in nature although Liz has been playing around with Scala a bit so she was able to guide us a bit when we got stuck. I’m finding that sessions where everyone is fairly new to the language or technology aren’t necessarily as fruitless as I had previously imagined that they would be - I find that learning something together makes it more interesting as you can then draw on other people’s ideas and understanding of the language as well as your own. I think in the cases where everyone is a novice people need to be prepared to get involved and write some code despite that. If that’s the case then I think it’s certainly possible to gain a lot from these sessions.