Hacker News Reader

Comment by jasonkester | Hacker News Reader

Oh dear.

I read the first half of this article watching him take the simple OO game loop and iteratively make it worse and worse, leaving it nearly unreadable and impossible to follow the logic or know what the state would be at any given moment. Then I came to this line:

Let’s take a moment to appreciate a few of the things we’ve gained by rewriting this code in a functional style

He actually thinks that he has improved the program. By piling functions up six deep and replacing pos.x += 3 with four lines of object accessor code (using strings for property names). Oh dear.

The second half of the article, where he realizes that he has not actually gained anything by ruining his game is just the icing on the cake.

I don't feel as though I've been sold on the benefits of Immutability today.

View on HN

In their defense, while the syntactic structure of the program may have had hash made out of it, the specific problem they described is indeed something that you could experience with a game engine with that design. I haven't quite seen that exact problem pop up for someone on /r/haskell, because that usually gets posts about how to design the loop in the first place, but the loop he describes has certainly been laid out there.

The only quibble is that usually when you do the "every entity declares its desired action and the core loop harmonizes it", you do it more symbolically. The player character does not issue a symbolic "I wish to move to position 38" command, it issues an "I wish to move 3 units to the right" symbolic result, and the enemy issues the "I wish to push the player two units to the left" symbolic result, generally with both results carrying their source info too, and then, when the loop goes to harmonize these things, it has more information with which to do it than opaque closures or something that the harmonization code can't understand.

I swear someday someone will write a blog post titled: "Controlled mutation of state variables in a purely functional paradigm: a syntactic approach."

And just after that we will rediscover GOTO.

You're joking, but "Goto" is coming back into fashion again. It's in Swift, for example. There are few things more self-destructive than taking any of these programming memes too seriously.

Immutable data structures look awful in mutable languages; also, the performance is worse.

Still, don't confuse syntactic overhead with the general usability of an idea. Writing a['x'] += 3; would be godawful in pure assembler, but we still use hashmaps, references, variables and operators daily when it's easy enough to do so.

Unless they're representing date/time or strings, then immutability is an excellent feature.

Wait, I'm confused. Date/time and strings are the two things that I ALWAYS want to be immutable.

I often end up writing an immutable wrapper for date/time in different programming languages.

My theory is that he thinks that variables are an imperative language feature - so he tries to avoid using them to make it all functional.

He is partially right - variables are imperative. What he does not know is that he can use his variables in a way that directly translates into purely functional 'value binding' and leave them readable.

I wish they would still use Scheme in intro computer science. It's so obvious in that language what is and isn't pure functional.

They still do at some universities. https://www.rose-hulman.edu/Users/faculty/young/CS-Classes/c...

We use it at Berkeley for the first CS class, CS61a. The final project is writing a scheme interpreter in python!

I'm with you. Why is it that the immutability path always requires endless amount of streaming-here, streaming-there, parsing-this, generating-that, &etc. Methinks there is a cargo cult factor going on .. at least in this case.

Reply on news.ycombinator.com