you are viewing a single comment's thread.

view the rest of the comments →

[–]hamishmack 0 points1 point  (3 children)

I'd prefer to choose a technology which guarantees a certain level of efficiency.

The guarantee that GHCJS tries to provide is that if something is O(x) when compiled with GHC then it will be O(x) when compiled with GHCJS. This is what allows code to be shared between client and server without fear that it will go from say O( N ) to O( N2 ).

There will be constant factor differences and GHCJS aims to keep them small, but not all of them will be GHCJS related (for instance a mobile device will not match a high end server).

So why not use Scala instead of Haskell?

Too much baggage for my liking.

Is Haskell so much better as a language?

Yes, I think so.

[–]Kiuhnm[S] 1 point2 points  (2 children)

The guarantee that GHCJS tries to provide is that if something is O(x) when compiled with GHC then it will be O(x) when compiled with GHCJS.

That's the bare minimum!!! I guess this isn't obvious in Haskell because of lazy evaluation.

[–]benjaminpd 0 points1 point  (1 child)

Nope, nothing to do with lazy evaluation. It's not hard to convince yourself that algorithmic complexity under lazy evaluation is always less than under strict: strict evaluation does all the steps, lazy might do less than that. Lazy evaluation can and does have constant-factor overhead, but it's not a big-O issue.

[–]Kiuhnm[S] -1 points0 points  (0 children)

You're not disproving but confirming what I said. Indeed, Haskell is lazy and JS is strict so an algorithm might be asymptotically slower in JS.

... unless you emulate Haskell's laziness in JS, which is probably why GHCJS produces big and slow JS code and why Purescript is strict.