71–78 of 78 posts
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?
These layers upon layers just seem painful to me.
The relevant question is only how leaky each layer of abstraction is.
Earlier quoted context omitted.
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).
But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When 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?
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.)
Earlier quoted context omitted.
But bugs happen everywhere, and I don't expect Haste to abstract and fix all possible browser bugs. When 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?
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 (Pent…
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.
Meta-comment: this is an excellently written landing page. All the comments about the explanation prose you usually see on HN when a language or library is introduced could be rewritten as "Make it more like Haste's landing page".
I don't know. I think language landing pages look better with a little bit of code at least.
code samples can really only give you a feel for the language, any more and it belongs in tutorials and API documents.
Earlier quoted context omitted.
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 (Pent…
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…
Was the Haste site made with Haste? The top links do nothing when viewing it on my (somewhat older) phone so I'm curious how well sites degrade in different browsers and devices.
It looks like: http://haste-lang.org/main.js ...and yes, I tried disabling JavaScript and it doesn't work.
I've been thinking for a while about reimplementing a large CoffeeScript (horrible language) project that we have at my work in Haskell, just to see if it could work, how easy it would be, how much smaller it would be, and if I could get the same or better performance out of it without going crazy. One of the demands of the existing software is that it both run in the browser, and server-side. This project is awesome…
Youre probably well aware of this but I do gather that: One of the biggest problems with coffeescript is that when you are troubleshooting production code you need to decipher the generated JS back to what was actually written in coffee. It strongly suggests haste will present the exact same problem perhaps in greater scale.