Live data from Hacker News

Haskell as a JavaScript MVC framework

tonyday567.github.io

21–26 of 26 posts

Re: Haskell as a JavaScript MVC framework

#21
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…

> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

That intermediary representation can enforce that your input is valid. Then you can create functions based on that intermediary representation and act as if your data is valid because it is.

The intermediary representation can also ensure you cover all cases if your states are encoded with sum/product types thanks to exhaustiveness checking in supported languages.

> I'm not trying to shoot down Haskell here, I really wish someone will point to something I'm missing and make it click. But right now it just looks like over-engineering that JS could do but chooses not to.

JS can't turn runtime errors into compile time errors because it doesn't have a compiler or a powerful type system. In fact it has a very weak/dynamic type system.

Re: Haskell as a JavaScript MVC framework

#22

Earlier quoted context omitted.

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.

The next minor version of PureScript is changing everything. That's scary.

Re: Haskell as a JavaScript MVC framework

#23

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.

I think it would be worth sharing that on a blog post submitted to HN. Sounds like a lot of work, maybe there are ways to automate that with a shell script or a Haskell program. 400KB is absolutely okay I think.

Re: Haskell as a JavaScript MVC framework

#24

Earlier quoted context omitted.

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.

The next minor version of PureScript is changing everything. That's scary.

s/minor/major

Re: Haskell as a JavaScript MVC framework

#25

Earlier quoted context omitted.

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.

I think it would be worth sharing that on a blog post submitted to HN. Sounds like a lot of work, maybe there are ways to automate that with a shell script or a Haskell program. 400KB is absolutely okay I think.

I agree, that would be awesome to study/emulate. Possibly use some of the techniques to make GHCJS programs smaller.

Re: Haskell as a JavaScript MVC framework

#26
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…

It's about encoding the specific problem in the safest way possible. Typos and missing cases represent a very large set of trivial bugs which crop up in many situations like teams, changing requirements, scale, and reuse. The JS function will continually suffer from all of these and your apply function is oversimplified solution. If the bug can be detected and encoded by the computer, why not utilize that?
Post reply on HN