Not entirely sure why you are getting voted down. (Well, unless you are wrong...) :(
I'll have to dig through the code again. The polish that the end product of the first version exhibited is well beyond that of any of the rewrites I've seen. To the point that it is, in fact, jarring. And makes it frustrating to read how much nicer the code looks in some of them.
Really brings home the point that intrinsic quality is nice, but pails in comparison to the final quality of the overall product. It isn't that I am convinced the sausage making process is always gross. Just that I have not seen that many examples where the clean versions are anything more than just sterilizations that have killed a lot of the original.
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.
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.)
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.
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.
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.
:) 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.
One of the benefits of Haskell is indeed that this language makes it possible to write very expressive code. The same is true for other functional languages as well. However, this won't happen automatically. In other words, it will take some practice. You can certainly write convoluted code in Haskell.
Yes, one of the worst mistakes I've seen people make is trying to write Haskell exactly like you write code in other languages like Python.
If you ignore the power of Haskell's type system, and write all your code imperatively in the IO Monad, and continue to write large functions that do many things instead of writing smaller functions that can be composed, you gain almost nothing from Haskell, and you might have been better off writing your code in another language.
> you gain almost nothing from Haskell, and you might have been better off writing your code in another language.
Don't know about that. Even if you write everything in the IO monad, Haskell is still a pretty great imperative language and many people say it may possibly one of the best imperative languages ever written.
If you only use IO, then yes, you no longer gain the ability to reify and isolate effects as values but all the other strengths of Haskell's type system mostly remain invariant and just as useful.
This could happen in the US as well, if I'm not mistaken. There is normally a requirement that you have to be in "good standing" during the first one or two years of your PhD when you're mostly doing course work.
Yes, I have a sneaking suspicion that an MPhil (= failed PhD in a lot of fields, so useless) is sometimes being sold as a PhD experience to people that are simply not good enough.
Maybe read the linked article to get some food for thought:
"These kinds of payments aren't inherently suspect in and of themselves. If the video makers disclosed that Microsoft was paying extra for these videos, and if they were allowed to say whatever they wanted in those videos, then the whole thing could be seen as merely an unorthodox way to increase exposure for the Xbox One on YouTube.
That's not the case, however. According to a leaked copy of the full legal agreement behind the promotion, video creators "may not say anything negative or disparaging about Machinima, Xbox One, or any of its Games" and must keep the details of the promotional agreement confidential in order to qualify for payment. In other words, to get the money, video makers have to speak positively (or at least neutrally) about the Xbox One, and they can't say they're being paid to do so."
I did read the article. I am not saying I agree with the practice or I see no negative aspects to the practice. I'm just surprised at the recent uproar over this when Microsoft is by no means the first company to do this. Sure their agreement states you can't say anything negative about the X1 but how is that different from publishers sending free games for people to review? Do you not think those people realize negative comments will most likely persuade publishers to stop sending them free games?
Why would I pay someone to trash talk my product or recommend another product? Coke would never have their polar bears drinking a Pepsi. Even Chevy ads don't talk about Cadillac.
I'm not sure whether you're joking or serious. Of course, a company won't praise a competitor in their ads. However, the money Microsoft hands out is for videos that are not presented as advertising at all. Instead they want regular users to do "stealth advertisement", when it is NOT clear to the viewer that those guys were paid by Microsoft. I would have no problem with Microsoft paying for ads that are clearly identified as such. You know, the stuff you see on the web or on TV.
The part I was highlighting is that Microsoft has a clause saying if you receive money from Microsoft, you can't talk bad about them. That's pretty natural, they don't want to pay detractors to keep disparaging them.
I don't get the appeal of an IDE in Haskell development. You can download the Haskell platform on haskell.org. In the case of Windows or OS X, it takes a few mouse clicks, and on Linux you launch a package manager to install it.
There may be some benefits of using whatever FP Complete offers, but if anyone is struggling with getting Haskell set up on his computer with the official releases, then that person might need to acquire some other skills first before delving into the world of pure functional programming.
Your post implies that the main reason people would use an IDE is because they are having trouble getting non-IDE tools for the language setup.
Of all the benefits I've heard ever used to sell IDEs, that's got to be the least common. Usually, things like syntax highlighting and error detection as you type, project management tools, version control integration, autocomplete, documentation/API tooltips, debugger integration, etc. are the advantages.
Some of those might be less relevant to Haskell than to, say, Java/C# style languages, but some of them would still be useful.
My impression is certainly that IDEs are aimed at beginners and users of more 'complex' languages like Java. (Case in point: Java has DrJava and other beginner IDEs, as well as IDEs for professionals like IntelliJ.)Indeed, I was referring to the the claim of the OP that "you don't need to mess with setting things up", which, to me, seemed to imply that it was a significant hurdle to get started with Haskell using an editor and ghci.
Syntax highlighting is part of any editor that is aimed at programmers, the interpreter does a great job highlighting errors, version control is done with git, and there is plethora of documentation on Haskell available too. Normally, ghci satisfies that need as well.
IDEs exist because they give you the full, bidirectional power of the compiler at your fingertips as you type, complete with annotations, jump-to-definitions and other code navigation, and syntax tree transformations (as opposed to just textual ones). If you think syntax highlighting, version control integration are top features you are sorely mistaken.
The fact is, you CAN do many of the things an IDE can do without one; its just generally harder, less discoverable, slower, takes longer to master, and for no real benefits. I would rather have a text box pop up saying exactly what types something has, and all the documentation about those types, and where it is defined in code, directly within my code in 0.1 seconds, then have to go and run some grep or hoogle search or whatever.
Scala is arguably part of the group of 'complex' languages I mentioned. Besides, the Scala worksheet functionality in Eclipse is really neat, which is another reason to consider using an IDE for it.
> I don't get the appeal of an IDE in Haskell development.
Code completion, syntax checking, looking up documentation, setting up projects and makefiles, code re-factoring, etc... Granted, Emacs and VIM will do most of this, and the language's tools will do the rest, but some people like having everything in one convenient package...
Installation hardly counts as a success when you're playing with a new language. An IDE that can make intelligent suggestions would make Haskell much, much more approachable.
That place is a café, and a fairly noisy one at that. Calling it a co-working space is quite a stretch. It's just that a lot of people with Apple laptops frequent it. I don't think anybody gets serious work done there, by a definition of "serious work" that does not include Facebook and Twitter.
Further, the animation code is only a miniscule fraction of that code base.