I'm not going to argue with you about my choice of tool, enough bits have been spent arguing the pros and cons of various languages without getting anywhere.<p>But here's a challenge for you:<p>I've spent, start to finish less than 10 hour to code that, having the idea (life cells that track time independently by counting generations) was 5 minutes, building it including breaks for dinner and a movie and a nightly session to work out the kinks was 10 hours.<p>Clone it, in any other language that you care about, as long as the following conditions are still met:<p><pre><code>  - no fixed size world

  - uses the same principles

  - produces correct output (easy enough to verify, the
    'end' stable state of the f-pentomino minus the ejected
    gliders is easily checked)
</code></pre>
You have this code for a reference, so you really only have to make a port, or you can decide not to look at it and build it from scratch.<p>Report back how long it took and show the source. That way we can all learn something because I'm really curious to see other implementations in other languages.<p>edit: to make this clear, my 'hangup' had to do with the bit that creates new cells on the fly, I was making them one generation older than the current one, that was a tricky mistake, it seemed like the right thing to do, after all then they could 'catch up' with the current crop and things would continue.<p>The reason that strategy backfires is that you potentially create a cell that is older than the 2 generation 'window' that you can accommodate in this scheme (because you only hold the state for the current and previous generations in a cell).<p>It took me a long time to figure that out because I was very much convinced the problem was elsewhere.<p>If I had chosen to use a statically allocated array of cells (more in line with a hardware simulation) that would have never happened, so as always, premature optimization is the root of all evil.