Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing 2048 in 90 lines of Haskell

gregorulm.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Implementing 2048 in 90 lines of Haskell

#21

Post by gu »

taeric wrote: post #20
gu wrote: post #19

Earlier quoted context omitted.

Who knows, maybe my comment made some "full stack" developers feel insecure. Just look at the code base of the original, and you'll see that the animation is done through API calls. Regarding the point you brought up: you are conflating two issues. One is whether the UI is appealing, and the other whether the underlying code is of a high quality. The point of my article was merely to show how nicely the game logic ca…

I'm not necessarily conflating them, though. That is, can you, through interaction with the original app, show that the code is of "low quality"? Even relaxing it, can you show it is of "lower quality" than the Haskel solution? Because, just using the app, I'd say the original app is much higher quality than this derivative. One I would consider playing for a bit, the other is just kind of neat. If we are just going…

I think we're completely talking past each other. Yes, you can express the game logic succinctly in Haskell. Yes, you will need many more lines in Python or JavaScript. Anything else is conjecture on your part. "Free text" is not executable, so your claim does not seem to be particularly relevant.

Feel free to use the UI as the sole measure of quality, but if that is your stance, you should probably seek a different audience.

Re: Implementing 2048 in 90 lines of Haskell

#22

Post by taeric »

gu wrote: post #21
taeric wrote: post #20

Earlier quoted context omitted.

I'm not necessarily conflating them, though. That is, can you, through interaction with the original app, show that the code is of "low quality"? Even relaxing it, can you show it is of "lower quality" than the Haskel solution? Because, just using the app, I'd say the original app is much higher quality than this derivative. One I would consider playing for a bit, the other is just kind of neat. If we are just going…

I think we're completely talking past each other. Yes, you can express the game logic succinctly in Haskell. Yes, you will need many more lines in Python or JavaScript. Anything else is conjecture on your part. "Free text" is not executable, so your claim does not seem to be particularly relevant. Feel free to use the UI as the sole measure of quality, but if that is your stance, you should probably seek a different…

I'm not entirely sure you would necessarily need more lines of code to express it in python or Javascript, to be honest. I'll see if I can give it a shot this weekend. Curious to really know. You could certainly use more, but the same could be said of Haskel, as well.

But I'm not necessarily trying to make a claim that it can't be done in Haskel. More that I have not seen it done. You can claim that the final polish of the original is irrelevant, but I find that claim hard to believe. Especially since I have yet to see an example that has said polish.

Sadly, I don't know how you would really go about proving that one way or the other.

Re: Implementing 2048 in 90 lines of Haskell

#23

Post by gu »

taeric wrote: post #22
gu wrote: post #21

Earlier quoted context omitted.

I think we're completely talking past each other. Yes, you can express the game logic succinctly in Haskell. Yes, you will need many more lines in Python or JavaScript. Anything else is conjecture on your part. "Free text" is not executable, so your claim does not seem to be particularly relevant. Feel free to use the UI as the sole measure of quality, but if that is your stance, you should probably seek a different…

I'm not entirely sure you would necessarily need more lines of code to express it in python or Javascript, to be honest. I'll see if I can give it a shot this weekend. Curious to really know. You could certainly use more, but the same could be said of Haskel, as well. But I'm not necessarily trying to make a claim that it can't be done in Haskel. More that I have not seen it done. You can claim that the final polish…

I never claimed that the polish of the UI in the original was irrelevant.

Re: Implementing 2048 in 90 lines of Haskell

#24

Post by taeric »

gu wrote: post #23
taeric wrote: post #22

Earlier quoted context omitted.

I'm not entirely sure you would necessarily need more lines of code to express it in python or Javascript, to be honest. I'll see if I can give it a shot this weekend. Curious to really know. You could certainly use more, but the same could be said of Haskel, as well. But I'm not necessarily trying to make a claim that it can't be done in Haskel. More that I have not seen it done. You can claim that the final polish…

I never claimed that the polish of the UI in the original was irrelevant.

:) Then I am continuing to talk right past you. Apologies.

I'll hopefully have more to add to the conversation after I try this game in a language. At face value, I am not at all clear on how this will take 90 lines of javascript. That just seems extreme.

Re: Implementing 2048 in 90 lines of Haskell

#25

Post by taeric »

gu wrote: post #23
taeric wrote: post #22

Earlier quoted context omitted.

I'm not entirely sure you would necessarily need more lines of code to express it in python or Javascript, to be honest. I'll see if I can give it a shot this weekend. Curious to really know. You could certainly use more, but the same could be said of Haskel, as well. But I'm not necessarily trying to make a claim that it can't be done in Haskel. More that I have not seen it done. You can claim that the final polish…

I never claimed that the polish of the UI in the original was irrelevant.

So, I realize the odds are rather low you will see this. I took a stab at implementing 2048 in javascript. Depending on what you mean by "many more lines," I'm not sure I agree still. For a hardcoded 4x4 grid, I'm only at 100 lines of code in javascript. (For arbitrary rectangular boards, I'm at 130.)

I'm not going to claim that the code alone is as "pretty" as the Haskel version, but I see no reason it should have exploded to be much larger. I may have to take a look at how other folks are doing this.

(Code is currently at https://github.com/taeric/2048-Explorations. Will try to prettify and publish the org file that accompanies it.)

Post reply on HN