40 ms·

My big worry here is debugging. With, say, CoffeeScript, my code translates trivially and it's easy to map my JS back to the source. But it seems like it'd be a

My big worry here is debugging. With, say, CoffeeScript, my code translates trivially and it's easy to map my JS back to the source. But it seems like it'd be a lot more complicated here. I'd love to hear the perspective of someone who's used this for real -- was that an issue?

pseudonom- 13y ago
I've used Elm a fair bit which is, in many ways, similar (compile-to-JS, statically typed, purely fuctional language). Between expressive types, a REPL, etc., I have never felt compelled to try to debug the generated Javascript.
quchen 13y ago
It's important to stress that JS is really just the target language "instead of ASM" for Haskell-to-JS compilers, not just a convenient preprocessor. Development happens in Haskell (or Core, an intermediate representation, "the final human-readable step before compilation") land, and very rarely in the JS (or ASM).
- Groxx 13y ago
  But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When <experimental feature X> changes subtly and you get an exception, how do you track it down? How about when the browser just freaks out and inserts a NaN in a place type safety says it can't?
  - quchen 13y ago
    Whatever the cause - code, compiler, browser - what you have is a NaN in the wrong place, so the usual techniques apply: Test your code (which usually consists of fairly small functions) using Haskell's excellent testsuites, figure out error location with Debug.Trace, etc. In the end, this is like asking what happens when the assembler "freaks out" (inserts 0 at a random location), or your architecture is wrong (Pentium FDIV bug): things may become difficult. (There is no type safety to help you on the JS level, much like there is no type safety in machine code. When you insert a wrong value, your code will misbehave in an unpredictable way.)
    - Groxx 13y ago
      Except that such things happen a lot more often on browsers. And "softer" errors, like experimental features being subtly different because user X toggled checkbox Y (which you don't know about and cannot reproduce) are not going to be caught by test suites. They can be caught by client-side crash logging / reporting. But if they're useless, you just lost the ability to fix bugs you don't see yourself in your nice up-to-date dev environment. These bugs happen with surprising frequency in any reasonably-used site.
      - deleted 13y ago
        [deleted]
carterschonwald 13y ago
Well, ghcjs, a "competitor" to haste that has even better ghc compatibility, is slated to have 2-3 student projects this summer to write some pretty amazing profiling / debugging tools
ef4 13y ago
Yeah, I'm all in favor of compiling better languages into Javascript, but it requires a degree of maturity and completeness from the surrounding toolchain.

pseudonom- 13y ago

I've used Elm a fair bit which is, in many ways, similar (compile-to-JS, statically typed, purely fuctional language). Between expressive types, a REPL, etc., I have never felt compelled to try to debug the generated Javascript.

quchen 13y ago

It's important to stress that JS is really just the target language "instead of ASM" for Haskell-to-JS compilers, not just a convenient preprocessor. Development happens in Haskell (or Core, an intermediate representation, "the final human-readable step before compilation") land, and very rarely in the JS (or ASM).

Groxx 13y ago
But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When <experimental feature X> changes subtly and you get an exception, how do you track it down? How about when the browser just freaks out and inserts a NaN in a place type safety says it can't?
- quchen 13y ago
  Whatever the cause - code, compiler, browser - what you have is a NaN in the wrong place, so the usual techniques apply: Test your code (which usually consists of fairly small functions) using Haskell's excellent testsuites, figure out error location with Debug.Trace, etc. In the end, this is like asking what happens when the assembler "freaks out" (inserts 0 at a random location), or your architecture is wrong (Pentium FDIV bug): things may become difficult. (There is no type safety to help you on the JS level, much like there is no type safety in machine code. When you insert a wrong value, your code will misbehave in an unpredictable way.)
  - Groxx 13y ago
    Except that such things happen a lot more often on browsers. And "softer" errors, like experimental features being subtly different because user X toggled checkbox Y (which you don't know about and cannot reproduce) are not going to be caught by test suites. They can be caught by client-side crash logging / reporting. But if they're useless, you just lost the ability to fix bugs you don't see yourself in your nice up-to-date dev environment. These bugs happen with surprising frequency in any reasonably-used site.
    - deleted 13y ago
      [deleted]

carterschonwald 13y ago

Well, ghcjs, a "competitor" to haste that has even better ghc compatibility, is slated to have 2-3 student projects this summer to write some pretty amazing profiling / debugging tools

ef4 13y ago

Yeah, I'm all in favor of compiling better languages into Javascript, but it requires a degree of maturity and completeness from the surrounding toolchain.