Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The New Turing Omnibus Chapter 44 Cellular Automata
Clone this wiki locally
First we talked through what cellular automata are and why they are interesting to give everyone a introduction to the topic if they hadn't read the chapter. During this we mentioned the "Simulating the World (In Emoji)" blog post by Nicky Case and the recent discovery of a new kind of "spaceship".
We then set ourselves a time-limit of 20? minutes to build a game of life as a mob. Murray did the typing while the rest of the group provided the implementation. We decided to use ruby and proceed without tests and managed to get it working just as the bell rang. We spent some time afterwards going through what we'd done to explain any tricks and what the trade-offs might be. For example we used a single dimensional array instead of a nested one to hold the "grid" which would make bounds checking harder, but because we had ruby's negative array indices it didn't matter (although that does give us a slightly odd wrap around).
Our implementation can be found at https://github.com/computationclub/game-of-life/tree/master/the-club
After this we broke up into pairs to build another implementation but this time choosing a constraint to challenge us. At a full-day code retreat you build game of life a couple of times with no constraints to give you a familiarity with the game then for the rest of the day you build it again each time with a new constraint. The constraints allow you to break out of your comfort zone and explore new ways of programming, new tools, new ways of collaborating; each time you focus just on the constraint as by this stage you know how to build game of life pretty well.
We looked at the list of suggested constraints before breaking up into our pairs, but ultimately left it up to each pair to choose their own constraint.
After 20 minutes of typing it was clear each pair was invested in getting further in their implementation so instead of stopping we opted to check-in after another 10 minutes. These 10 minutes flew past but we were all "really close, can we just have another 10 minutes please?" so we agreed to keep going. In a traditional code retreat the 20 minutes per session is a hard limit as the goal is not to complete the implementation, just to explore the constraint. We weren't going to have time to run another session allowing exploring another constraint so running one long session allowed us some small sense of victory over our chosen constraints.
As we were close to the end of the meeting we decided 40 minutes for the session was enough so we stopped the coding and let each pair describe their implementation and constraint. As it turns out most pairs chose a programming constraint, either "no arrays" or "no conditionals". Hearing about the different approaches each team took to working around the same constraints gave us plenty of food for thought.
You can find our implementations in this repo.
We also had time for a quick retro about the code retreat process. Many pairs found that they spent a lot of time getting the infrastructure of the game out of the way before they could focus on the logic of the game where they could really embrace (or avoid) their constraint. We wondered if a test harness or incomplete implementation would have helped, or if these would have just acted as external constraints (e.g. that you had to use tests, or had to use the language they were written in).
Thanks as ever to Leo and Geckoboard for providing the venue and fetching the drinks.