4 ms·

somewhat off topic but... this is a horrible fallacy: > "I wrote some code, re-implementing life quick-and-dirty, in - yes, yuck - PHP. It's the tool of choic

by diN0bot 17y ago

somewhat off topic but... this is a horrible fallacy: > "I wrote some code, re-implementing life quick-and-dirty, in - yes, yuck - PHP. It's the tool of choice because it is very close in syntax to C and I've programmed lots of code in it so I can whip out something small like this in a couple of hours." someone knows some dumb language and thinks he'll be more PRODUCTIVE in another similar dumb language. familiarity gains very little compared to the gains possible with a smart language, but which i mean one that makes the code readable, less buggy and less horrendous. as humans we're terrible at figuring out short and long term costs, as well as comparing non-linear curves....

pcc 17y ago
We also seem to have trouble acknowledging there's a toolbox full of tools, and determining when its worth acquiring a new tool vs using an existing one. (aka, there are scenarios where the dumbest language might in fact just be the smartest choice.) From an engineering judgement, seems he got precisely the result he wanted; which was to get from A to B in the shortest possible time, with gains beyond that (maintainability etc) very much a secondary concern. To me that seems to preclude acquiring a new language.
cmars232 17y ago
He used familiar tools to quickly create a working prototype. He made progress with his thought experiment. Don't hate!
jacquesm 17y ago
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. But here's a challenge for you: 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. Clone it, in any other language that you care about, as long as the following conditions are still met: - 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) 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. 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. 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. 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). It took me a long time to figure that out because I was very much convinced the problem was elsewhere. 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.
- jules 17y ago
  Here's my solution: http://pastebin.com/f75a9ee http://pastebin.com/f75a9ee Usage: run and click on the window to get next generation I used Jython with a Swing GUI. It took me about 1.5 hours in total half of which was spent getting the GUI right :S (I never used Swing before). The algorithm itself was fairly straightforward. It was buggy and gliders didn't work and I tried fixing the state management in the cells but in the end the bug turned out to be in the update rule of the game of life. I had "cell is alive in the next generation if it has 2 or 3 live neighbors". That should be "a cell is alive if (it is ALIVE and has 2 or 3 neighbors) OR (it is dead and has 3 neighbors)". I don't know if it's correct now, I only tested a glider. Features: - the world is created on the fly - dead cells are removed from the world, so gliders run in O(1) space - GUI :)
  - jacquesm 17y ago
    Neat ! A good test for 'correctness' is to run the F-pentomino both in some known good program and your own. It looks like this: xx xx x I's a really interesting little pattern that will expand quite a bit before stabilizing, it also fires off a bunch of gliders. edit: I've looked a bit more at your code, and it is almost correct for free-running instances of 'cell'. The problem is with the generation counter, you only have 1 bit for the generation. In a synchronous environment that would work, and because you propagate the 'update' signal from the first cell that is hit outward you will (probably) observe correct behaviour. But that is not the same as having cells completely independent. The connecting cells are all triggered from the first cell that gets hit. If multiple cells get triggered simultaneously (not possible in a single threaded program!) then as soon as there was a little bit of speed difference between any two cells things would go wrong. I figure the absolute minimum number of bits in the generation counter is 2, because then you have one 'dead' state in between the 3 possibilities that are current. A neighbour can be 'ahead', at the same generation or it can be 'behind' and what a cell does should be governed by the states of the neighbours. In your program you can never get in to the 'behind' state, but in a free-running hardware solution that is a definite possibility. I hope that's all clear :) Think of it this way, effectively you've made your cells globally clocked again. You also can't delete dead cells, two populations that were connected at some point in the past should stay connected or they will drift away from each other. If a 'cell' is run by a completely independent thread which runs at some arbitrary speed the whole thing should still work. Simulating asynchronous devices on synchronous devices is quite tricky!

by diN0bot 17y ago

pcc 17y ago

We also seem to have trouble acknowledging there's a toolbox full of tools, and determining when its worth acquiring a new tool vs using an existing one. (aka, there are scenarios where the dumbest language might in fact just be the smartest choice.) From an engineering judgement, seems he got precisely the result he wanted; which was to get from A to B in the shortest possible time, with gains beyond that (maintainability etc) very much a secondary concern. To me that seems to preclude acquiring a new language.

cmars232 17y ago

He used familiar tools to quickly create a working prototype. He made progress with his thought experiment. Don't hate!

jacquesm 17y ago

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. But here's a challenge for you: 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. Clone it, in any other language that you care about, as long as the following conditions are still met: - 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) 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. 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. 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. 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). It took me a long time to figure that out because I was very much convinced the problem was elsewhere. 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.

jules 17y ago
Here's my solution: http://pastebin.com/f75a9ee http://pastebin.com/f75a9ee Usage: run and click on the window to get next generation I used Jython with a Swing GUI. It took me about 1.5 hours in total half of which was spent getting the GUI right :S (I never used Swing before). The algorithm itself was fairly straightforward. It was buggy and gliders didn't work and I tried fixing the state management in the cells but in the end the bug turned out to be in the update rule of the game of life. I had "cell is alive in the next generation if it has 2 or 3 live neighbors". That should be "a cell is alive if (it is ALIVE and has 2 or 3 neighbors) OR (it is dead and has 3 neighbors)". I don't know if it's correct now, I only tested a glider. Features: - the world is created on the fly - dead cells are removed from the world, so gliders run in O(1) space - GUI :)
- jacquesm 17y ago
  Neat ! A good test for 'correctness' is to run the F-pentomino both in some known good program and your own. It looks like this: xx xx x I's a really interesting little pattern that will expand quite a bit before stabilizing, it also fires off a bunch of gliders. edit: I've looked a bit more at your code, and it is almost correct for free-running instances of 'cell'. The problem is with the generation counter, you only have 1 bit for the generation. In a synchronous environment that would work, and because you propagate the 'update' signal from the first cell that is hit outward you will (probably) observe correct behaviour. But that is not the same as having cells completely independent. The connecting cells are all triggered from the first cell that gets hit. If multiple cells get triggered simultaneously (not possible in a single threaded program!) then as soon as there was a little bit of speed difference between any two cells things would go wrong. I figure the absolute minimum number of bits in the generation counter is 2, because then you have one 'dead' state in between the 3 possibilities that are current. A neighbour can be 'ahead', at the same generation or it can be 'behind' and what a cell does should be governed by the states of the neighbours. In your program you can never get in to the 'behind' state, but in a free-running hardware solution that is a definite possibility. I hope that's all clear :) Think of it this way, effectively you've made your cells globally clocked again. You also can't delete dead cells, two populations that were connected at some point in the past should stay connected or they will drift away from each other. If a 'cell' is run by a completely independent thread which runs at some arbitrary speed the whole thing should still work. Simulating asynchronous devices on synchronous devices is quite tricky!