Groovy-licious!
So, Groovy 1.0 is finally here! If you asked me a year ago, I would have said that I was just not interested in Groovy. I thought it was a dead language, and I had better things to focus on. It seemed like a great idea, but just not going anywhere. But, thanks to the committed team of developers, it has finally shaken off the vapors.
Scott Hickey, lead developer of the Groovy Eclipse plugin, has been gently pushing me to learn the language for a long time now. And, it has piqued my interest a few times, but never to the point of actually writing some code.
At our January OJUG meeting earlier this week, we had a group discussion about Groovy and how far it has come. I made a mental note to sit down and give it a go-around… kick the tires so to speak. And, yesterday I had the chance to sit down with Scott for lunch, and he went through the Groovy Eclipse Plugin with me. He showed me where things are at, and what I can do to help out.
And finally last night I sat down and wrote some Groovy. As with most languages, I started out with my favorite little program: Pegs. If you are not familiar with the game, it is basically a triangular board with fifteen holes in it, also in the shape of a triangle:
*
* *
* * *
* * * *
* * * * *
You start the game with one empty hole, and the rest filled with pegs. The object of the game is to jump a peg over another peg into an empty hole, repeating until there are no more moves left. Obviously the goal is to get down to just one peg.
Here is the code for the Board object (Board.groovy):
-
package pegs;
-
-
class Board {
-
private EMPTY = 0
-
private SET = 1
-
-
/*
-
pegs are set as follows (last row is 10 - 14)
-
0
-
1 2
-
3 4 5
-
6 7 8 9
-
0 1 2 3 4
-
*/
-
-
private pegs = [SET,
-
SET,SET,
-
SET,SET,SET,
-
SET,SET,SET,SET,
-
SET,SET,SET,SET,SET]
-
-
Board(starting_peg = 0) { pegs[starting_peg] = EMPTY }
-
-
-
return board
-
}
-
-
-
“””
-
${pegs[0]}
-
${pegs[1]} ${pegs[2]}
-
${pegs[3]} ${pegs[4]} ${pegs[5]}
-
${pegs[6]} ${pegs[7]} ${pegs[8]} ${pegs[9]}
-
${pegs[10]} ${pegs[11]} ${pegs[12]} ${pegs[13]} ${pegs[14]}
-
““”
-
}
-
-
-
]
-
-
-
}
-
-
}
-
}
-
-
}
-
-
class Move {
-
-
protected from;
-
protected to;
-
protected over;
-
-
Move(_from, _to, _over) {
-
from = _from;
-
to = _to;
-
over = _over;
-
}
-
-
}
This code hits a ton of features that differentiate Groovy from Java:
- Lines 4,5: Right away we see something strange. Where did the type go?
- Line 16: Whats going on here? Not only are we not giving a type for the variable, but we also are assigning it what looks like a list…. huh.
- Line 22: This must be the constructor for the Board class… but look! the method argument doesn’t have a type! and it allows you to set default value!
- Line 24: Ok, so where did the return statement go?
- Lines 25,26: Ok, Stop! Whats going on here? This is where it all starts to become gravy. So far we’ve see how Groovy simplifies our Java by getting rid of types here and there, and allows us easier creation of Lists, and the ability to ignore return statements. Now, we are seeing the Lisp nature of Groovy:
This method is returning the number of empty pegs on the board… but how? It is passing a closure to the findAll() method, which then iterates the list of pegs and calls the closure on each. The closure must (in this case) return a predicate (boolean), and only the positives are added to a list which is returned, only to have the size property actually returned to the caller.
- Line 31: Whats with the def keyword? Thats needed inside the methods to def a method scoped variable… I think there is more to it than that, but that is what I know so far.
- Line 32: Whats with the 0..14 business? Thats a Range. Like Python, Ruby, et al.
- Line 37: Yay! We have joins!
- Line 40: Three quotes? wtf?!?! This is the demarcation of a multiline string. Something I have wished and prayed for (and man I do not pray for a lot) since I first experienced XML. This alone makes me quiver. Yes, I said quiver.
- Line 41: ${pegs[0]}…. I see… its doing text replacement with the value from the pegs list… sweetness!
Everything else is pretty much either been discussed by the above, or is straight forward enough to not require too much more explanation.
In case you were interested, here is the test code. Groovy makes testing so much nicer than Java. This is not a great example, but imagine what the triple-quote feature can do for you…
-
package pegs;
-
-
-
}
-
-
}
-
-
board.makeMove(board.availableMoves()[0])
-
}
-
-
-
-
board.makeMove(board.availableMoves()[0])
-
-
board2.makeMove(board2.availableMoves()[0])
-
}
-
-
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
board.makeMove(board.availableMoves()[0])
-
-
}
-
-
}
The Board class does not really do much for you. It’s really just a state object: It gives you all of the information you need, but needs an external object to tell it whats going on. So, part of this project always entails writing a Solver to figure out all of the different winners and board states. Its a really simple Game Theory system that looks at all of the possible states of the board. So, finally, here is Solver.groovy:
-
package pegs;
-
-
winners = 0
-
boardCount = 0
-
-
println “\nStarting board(${peg})”
-
walkAvailableMoves(board)
-
}
-
-
-
-
boards[board.hash()] = board
-
boardCount++
-
moves = board.availableMoves()
-
winners++
-
}
-
-
moves.each { move ->
-
newBoard = board.copy()
-
newBoard.makeMove(move)
-
walkAvailableMoves(newBoard)
-
}
-
}
-
-
println “”
-
println “boards: ${boardCount}”
-
println “winners: ${winners}”
A little recursion to set the heart a-flight. Ooookay. As you can see, this is, as Bob Ross would say “just a happy little Groovy script”. (Sorry, we don’t have cable, so we are pretty much left with PBS). The only thing that may stick out a little more, and something that I did not mention above, is that there is not one semicolon in this whole script. This is typically the case with Groovy. The only time it is necessary is when you are putting multiple code statements on the same line.
Some thoughts
As indicated above, I was not a big fan of Groovy, and instead decided to go the Ruby Way. However, I think I have found the language I was looking for when I went to Ruby, and its called Scheme. Oops.. I um… Ah crap.
Seriously, Groovy is a great addition to the JDK. I was surprised to see many of the Rubyisms that I have come to love expressed in the VM that has inhabited my career for the last 7 years. I am really excited by the possibilities that adding Groovy to my repertoire will provide.
If you haven’t already, I suggest you go out and get the Groovy in Action book, and while you are at it, download the Getting Started in Grails book from InfoQ.
I have already decided what my first Grails project will be… I just hope I have enough time this weekend to get the ball rolling on it.