sweet!
having fun deserializing!!
<Icfp_boulder:0x40448 @x_pos="-220.00", @opaque=true, @radius="12.000", @y_pos="750.00">
<Icfp_alien:0x40394 @x_pos="-240.000", @angle="90.0", @opaque=false, @radius=0.4, @y_pos="812.000", @velocity="9.100">
Plans for today
Saturday is coming to a close. A perfect storm of big life events are whirling this weekend, especially today. So it's been really hard to focus today. But the skeleton code is starting to look somewhat lifelike, which is encouraging.
My goals for today are to have a client which can make the rover go right. That's it, just go right until the timer expires or Martians or craters take it out.
code at last
Wow, my Ruby skills are much rustier than I expected. Grails would provide a better test experience (with some annoying startup time), but I still feel like Ruby was the best overall choice. I've put out some skeleton code for the board entities (aliens, craters, ...). I'm planning to have some abstraction around the network exchanges, some of that has been laid out too. This phase of the work is straightforward, leaning towards the tedious. But a nice clean job here will make the hard part, the navigation heuristics, much easier to write.
Picking a language
I was pretty tired last night so I crashed early with some progress made but many big open questions. For some reason it's really hard to pick a language. The final candidates are C++, Ruby, and Groovy. They all have
- C++: this is where I cut my programmer teeth. The Boost libraries made C++ a final contender, no time to work with the default APIs or learn something like NSPR. Still, the skills are rusty.
- Ruby: Every time I use Ruby I like it a lot. Skills not quite as strong as...
- Groovy: I've spent way too much time around javac lately. It would be easy to use Grails as a REPL and test harness. However, an expensive IDE is an unspoken requirement in the Grails community. I reject that entirely, even if it means submitting a half-baked groovy mode for emacs.
I would love to misuse Grails as REPL and test harness, but I am afraid of problems migrating the code into a standalone JAR file. Developing the controller code as a JAR from the start leaves some of the benefits on the table. Rejecting the expensive IDEs leaves me with printf debugging and mediocre indenting / syntax highlighting.
C++ has great support within Emacs and GDB. I'm pretty sure I've forgotten many important C++ coding rules and would hate to get bitten by them during development. Not the least of which is manual memory management... I admit to being spoiled here now.
Ruby isn't my strongest language, but the design of the language is very comfortable to me. Combine that with good IDE support and I think that makes it the best overall option.
That took entirely way too long. Not a good omen ![]()


