[gu]

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 can be expressed in Haskell, compared to many other languages.

[taeric]

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 off how nicely the logic can be expressed, with no regard to the dirtiness of implementation, free text wins. A simple paragraph describing the game is much more understandable than even the haskel. Especially if you allow examples.

Edit: Also, I'm curious if you could reproduce the UI of the original with just a library in Haskel. That is, sure, most of the code is done though a library. Does that really change much? If so, you should be able to achieve the same fluid and pleasant UI with "just a library" in Haskel, right? (Genuine question.)

[gu]

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.

[taeric]

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.

[gu]

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

[taeric]

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.)

[taeric]

:) 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.