Developing Games in Elm | Hacker News Reader

Developing Games in Elm

gelatindesign.co.uk

67 pointslelf17 comments

There is nothing about developing games in this article! I do not understand why they put such title at all.

Clickbait

Hi, author here. The reason is because I am using elm to develop games and this is the first in a series I'll be writing as I learn about doing that. It's largely just me collecting my thoughts as I learn.

The title should be "Useful Elm code which could be useful if you decide to code a game in Elm", not "Developing Games in Elm".

This is typical for functional languages:

1) build a functional language with lots of features but having a really weird ML-style syntax (because 'succinct' and "you don't need those braces")

2) create a try[lang name].com website

3) ?

4) Profit!

http://en.wikipedia.org/wiki/Gnomes_(South_Park)

ML syntax is only weird if you consider C/ALGOL style the one true normal. if nothing else, the fact that so many languages use it should remove it from the "weird" category; it's simply the style that matches ML-style programming most pleasantly.

"most pleasantly" - that is also very subjective.

I'd love to see an actual game code using FP. Like a snake or something. Is there any performance advantage?

Check "Nikki and the Robots".

It was done in Haskell and available on Steam.

John Carmack also did a port of Wolf3D to Haskell, during his FP experiments.

https://twitter.com/id_aa_carmack/status/331918309916295168

That's what I'm hoping to do over this year. I'm not expecting any particular performance improvement due to it being functional, I just find it more beneficial as a coding style personally.

Stupidly enough, right before clicking on the article I thought that Elm (http://en.wikipedia.org/wiki/Elm_%28email_client%29) had somehow reached a level of complexity comparable to EMACS...

Loved the explanation of Composition.

> An often better alternative to chaining is composition

It's not explained, but one of the reasons why is that function composition refactors more easily than chained code. The first operand (i.e. the value) in the chained code alters the semantics of all the subsequent chained code. You cannot replace parts of the chain as easy as you can with vanilla function composition; you always have that first value to worry about, and this reduces reusability slightly (compared to composition)

Same, but I feel like I'm missing something with one of the examples.

squareIsOdd = square >> isEven >> not -- `not` is a built-in function that inverts booleans

squareIsOdd 3 == True squareIsOdd 7 == False <-- huh?

Yeah I didn't get that either, shouldn't that be False both times? 3^2 = 9 and 7^2 = 49, both odd.

Hah, woops. Author here, I switched between odd and even and forgot to update the numbers... I'll fix it.

Thanks :)

Reply on news.ycombinator.com