Live data from Hacker News

Haskell as a JavaScript MVC framework

tonyday567.github.io

11–20 of 26 posts

Re: Haskell as a JavaScript MVC framework

#11
post #8

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…

This article doesn't really do justice to Haskell's type system, but the main benefit I achieve is that with a properly defined type, it is often impossible to put the internal state of the program in a inconsistent state, eliminating a large class of bugs and crashes.

Re: Haskell as a JavaScript MVC framework

#12
post #9
post #8

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…

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.

Yep, was thinking the same exact thing when I saw "actions".

Re: Haskell as a JavaScript MVC framework

#13
post #8

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…

Really, the author is in favour of polynomial types (sums of products); the emphasis on sums is probably because tuples/records/arrays/etc. are already quite well known.

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

#14
I 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.

Re: Haskell as a JavaScript MVC framework

#15

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

I've explored ghcjs. I had a reasonable react based site down to ~400k after dead code removal and minification. Still biggish, but not multi-megabyte.

The raw unoptimized code was in the several megabyte range though.

Re: Haskell as a JavaScript MVC framework

#16

Yikes, 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

#17
post #4
post #3

I'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…

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.

Re: Haskell as a JavaScript MVC framework

#19

Yikes, 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.

Purescript (while not quite Haskell) also has very small output and is strict by default. There's also the very fun, informative, and productive "Purescript By Example"[0] book.

0: https://leanpub.com/purescript/read

Re: Haskell as a JavaScript MVC framework

#20
post #4

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

Can you list some ways/reasons Purescript is too unstable for you? Maybe a link to the JS Array type mistake? I've used purescript for some semi-serious stuff before and didn't notice anything unstable.
Post reply on HN