I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here? The highlight of the article is having a unique Action sum type instead of a myriad of separate functions. But the action still has to be processed by a myriad of separate equations (is that the correct Haskell term? Not familiar with the language): apply ClearCompleted tds = over todosItems (Map.filter (\x -> vie…
Haskell as a JavaScript MVC framework
11–20 of 26 posts
Re: Haskell as a JavaScript MVC framework
#12I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here? The highlight of the article is having a unique Action sum type instead of a myriad of separate functions. But the action still has to be processed by a myriad of separate equations (is that the correct Haskell term? Not familiar with the language): apply ClearCompleted tds = over todosItems (Map.filter (\x -> vie…
You're not missing anything. What you and the author are describing (in terms of pattern/architecture) has existed for quite a while but was widely popularized recently by Facebook's [Flux]( https://facebook.github.io/flux ). The author is either naive towards current state of the JavaScript landscape or their just being arrogant about what is actually unique to 'functional' programming.
Re: Haskell as a JavaScript MVC framework
#13I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here? The highlight of the article is having a unique Action sum type instead of a myriad of separate functions. But the action still has to be processed by a myriad of separate equations (is that the correct Haskell term? Not familiar with the language): apply ClearCompleted tds = over todosItems (Map.filter (\x -> vie…
To see the distinction, notice that many Actions have some associated data:
data Action a
= ClearCompleted
| DeleteItem ItemId
| EditItem ItemId
| EditItemCancel ItemId
| EditItemDone ItemId a
| Filter (Maybe ItemStatus)
| NewItem a
| NoAction
| Refresh
| Toggle ItemId
| ToggleAll
In your analogy, the `action` value is actually quite complicated: it's an object (record) containing a field called "type" containing a string; if the "type" field contains the string "DeleteItem" then the action object also contains a "todo" field, containing an item ID; if the "type" field contains the string "EditItem" then the action object also contains a "todo" field, containing an item ID; and so on.This is known as a "dependent record", and requires a much more elaborate type system than polymonial types. In fact, without careful consideration, dependent type checking can end up being undecidable!
Compare this to the polynomial type, where the parameters (item IDs, etc.) are right there in the value. We can never have an Action without the corresponding parameters (if we try, we'll end up with a function rather than an Action, thanks to Currying). We can never switch the type of an action while forgetting to change the parameters; etc. Plus, of course, we've denoted a finite set of actions, rather than relying on strings (AKA "stringly typed" programming).
Another point to note:
> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.
Of course it would be simpler, but the entire point of the exercise is to use MVC to separate concerns, even though it's clearly overkill. If we're going to do MVC anyway, then the Action type provides a very simple interface between the Controller and the Model: the Controller just spits out an Action, the Model just receives an Action; no need for any further coordination. Plus, it's all really easy to reason about and type check.
Re: Haskell as a JavaScript MVC framework
#14http://i.imgur.com/kPHl4L7.png
7834KB is way too large for just that, I'm afraid.
I've 120Mbit/s, that's why it still loads fast, but I remember how slow, but fascinating surfing with 56K modem was.
Re: Haskell as a JavaScript MVC framework
#15I start to like Haskell and would enjoy learning to use it for the Web, but look at the size of it: http://i.imgur.com/kPHl4L7.png 7834KB is way too large for just that, I'm afraid. I've 120Mbit/s, that's why it still loads fast, but I remember how slow, but fascinating surfing with 56K modem was.
The raw unoptimized code was in the several megabyte range though.
Re: Haskell as a JavaScript MVC framework
#16Yikes, 1,670KB for generated javascript alone, that's kind of a deal breaker. GHCJS has a ways to go methinks. Js_of_ocaml and Scala.js are far better suited for production use today as the type safety "tax" is much smaller (i.e. binary is at most 1/4 the size for equivalent functionality). EDIT: didn't realize you cannot yet call into Haskell from GHCJS, and even Haskell to GHCJS requires going through FFI[1] Meh, m…
Re: Haskell as a JavaScript MVC framework
#17I'm sure it's very clever, but the result ( http://tonyday567.github.io/static/index-auto.html ) didn't work for me in Chrome (but did in Firefox). I suppose the unfortunate problem with this is that delivering it with an issue like that would mean that approximately 99.99% of the web developers out there would have no idea how to fix it (the generated JS is utterly incomprehensible, of course).
That is something I was worried about, because afaik, ghcjs is still fairly experimental. But ability to use ghc's magic to produce javascript sounds aluring :-) I think, that if you could integrate source-map capabilities (haven't tried http://hackage.haskell.org/package/sourcemap yet) it might make the debug process more bearable. But if you would be looking for haskell-like-language with more comprehensible to-jav…
Re: Haskell as a JavaScript MVC framework
#18I have 100% faith in the Haskell community's ability to keep doing what they've been doing for years. ;)
Re: Haskell as a JavaScript MVC framework
#19Yikes, 1,670KB for generated javascript alone, that's kind of a deal breaker. GHCJS has a ways to go methinks. Js_of_ocaml and Scala.js are far better suited for production use today as the type safety "tax" is much smaller (i.e. binary is at most 1/4 the size for equivalent functionality). EDIT: didn't realize you cannot yet call into Haskell from GHCJS, and even Haskell to GHCJS requires going through FFI[1] Meh, m…
I quite like Haste for Haskell to JS compilation. Its output isn't too bloated.
Re: Haskell as a JavaScript MVC framework
#20Earlier quoted context omitted.
That is something I was worried about, because afaik, ghcjs is still fairly experimental. But ability to use ghc's magic to produce javascript sounds aluring :-) I think, that if you could integrate source-map capabilities (haven't tried http://hackage.haskell.org/package/sourcemap yet) it might make the debug process more bearable. But if you would be looking for haskell-like-language with more comprehensible to-jav…
I wanted to use PureScript, but the language is too unstable for me. They're getting rid of lists and pattern matching for them in the next version, for example, because they made the mistake of using JS's Array type.