Not the author, but I've implemented my own snake game and this bug is fairly easy to kill.
(1) - You can only change directions that will change your axis, if you're going left your possible changes are up and down, ....
(2) - You should be only able to consume one direction change per game tick, what is happening here is that rule (1) is working but you can change into the other axis, and then back to the other axis again before the game loop computes another frame. Direction change can be read asynchronously but the actual change should be tied by each tick.
Maybe it makes it too easy, but I would enjoy the mechanic that quickly pressing UP LEFT when moving right would make the snake head move one square up then turn left and continue left. I suppose that would require some special casing, and you wouldn't want to support longer queued direction changes. Maybe a nice implementation would be that for inputs queued within a single game tick, execute the first input for one square of movement, then the last input for the next tick.
I attended a two day Elm workshop a while back. There is a lot there to love, I just think it's Haskell inspired syntax is a major impediment to it's mainstream adoption. I however would love to be proven wrong as the webs reliability would be so remarkably improved.
Here's a challenge for you: what syntax would be better? I don't mean that in a derogatory way. I think you are right that the syntax (being very foreign to people) does provide an impediment, but puzzling out how to implement the same functionality with a more familiar syntax would be extremely difficult (though potentially very fun).
You can do it in Python as you have, but it becomes second nature with Haskell (I can't speak to Elm directly). You might not even realize you're doing it.
Add 5 to each num in a list (using a pretend function called `add` in both languages to be fair):
Sorry, but there is nothing more explicit about using lambdas as you have done, it's simply redundant (notice the repetition of sublist and num arguments).
Redux follows the same pattern with your more "familiar" syntax.
Typed functional programming offers wins that forces more safety and modularity onto the code. These are all long term wins. Ultimately I would argue that elm's syntax is better suited for extremely complex projects that have low tolerance for bugs.
Right but the underlying design pattern is the same. This is all I'm saying. Redux can almost be thought of as an Elm pattern implementation with "familiar" imperative syntax.
Elm has been personally an inspiration too. Nice set of decisions and tradeoffs for what they're trying to achieve, though yeah, mainstream syntax might not be one of them, but that's fine.
reply