that's rotating a matrix by one cell left, same, right: to make three matrices, then shifting those three up and down by one place to make nine with the 'surrounding squares' of each cell. Like so:
Quick, are their tuples correct or did I sneak in a mistake? Easier to eyeball ¯1 0 1 for correctness, right?
The whole APL expression is shorter than their line 14 to copy the board:
copy_board = [[board[row][col] for col in range(cols)] for row in range(rows)]
with its five variable names (easy to mistake col/cols and row/rows), four keywords, chained indexing inside a nested list comprehension. That's Followed by 12 more lines of code dense with 0s, 1s, <, >, >=, ==, row, rows, col, cols, neighbour, neighbours - quick are they all typo-free and all the comparison and boundary cases correct with no off-by-ones?
That leaves ∨.∧ as something weird, but it's short so you can try https://aplcart.info see if it's a known idiom or part of one, and if not it won't be much effort to type into a REPL like https://tryapl.org and play with. You can make some boolean arrays to try it in a few characters. What if you don't understand the Python code, how much more work is it to extract it into a test file and make test data and some print functions for it?
> "If understanding syntax is heaviest mental exercise in programming language it is unexcusably terrible. It should be considered torture to even require someone to read it"
The syntax is not the hard part, "how does this data transform solve the game of life" is the hard part, and hiding the data transform in a torrent of fluff like "(r < rows and r >= 0) and (c < cols and c >= 0) and (copy_board[r][c] == 1)" is inexcusably terrible. Details are what computers are good with, and what people are bad with. High level transforms is what people should focus on and tools should enable.
> "Nope, it should be burned in fire."
With a glance at it, things jump out:
that's rotating a matrix by one cell left, same, right: to make three matrices, then shifting those three up and down by one place to make nine with the 'surrounding squares' of each cell. Like so: How much work is that in Python? Compare with this Python Game of Life found on the internet[1]: https://gist.github.com/amankharwal/e04369de79c4060fb7edab5c... and see that this part overlaps with their line 8, finding the neighbours of a cell: Quick, are their tuples correct or did I sneak in a mistake? Easier to eyeball ¯1 0 1 for correctness, right?The whole APL expression is shorter than their line 14 to copy the board:
with its five variable names (easy to mistake col/cols and row/rows), four keywords, chained indexing inside a nested list comprehension. That's Followed by 12 more lines of code dense with 0s, 1s, <, >, >=, ==, row, rows, col, cols, neighbour, neighbours - quick are they all typo-free and all the comparison and boundary cases correct with no off-by-ones?That leaves ∨.∧ as something weird, but it's short so you can try https://aplcart.info see if it's a known idiom or part of one, and if not it won't be much effort to type into a REPL like https://tryapl.org and play with. You can make some boolean arrays to try it in a few characters. What if you don't understand the Python code, how much more work is it to extract it into a test file and make test data and some print functions for it?
> "If understanding syntax is heaviest mental exercise in programming language it is unexcusably terrible. It should be considered torture to even require someone to read it"
The syntax is not the hard part, "how does this data transform solve the game of life" is the hard part, and hiding the data transform in a torrent of fluff like "(r < rows and r >= 0) and (c < cols and c >= 0) and (copy_board[r][c] == 1)" is inexcusably terrible. Details are what computers are good with, and what people are bad with. High level transforms is what people should focus on and tools should enable.
[1] https://thecleverprogrammer.com/2020/12/25/game-of-life-with...