3 ms·

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

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 because I could reimplement it in Haskell, and run a binary version on the server, with a JS version in the browser. Very cool! Now if I could only convince my company to switch... By the way, on the "Try Haste" project, it would be nice to see the generated JS output, as they do on the "Try CoffeeScript" page. Even though it's not really meant to be looked at in javascript, it's informative for those who know a bit about both languages to see what kind of transformations are taking place.

pweissbrod 13y ago
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.
- ef4 13y ago
  If you're still suffering that pain you need to switch to better build tools. Source map support is pretty mainstream now. If I open Chrome Dev Tools on my production site, it automatically grabs source map files from my server (accessible only to me), and I see the whole source tree of original coffeescript files, with complete access to breakpoints and stack traces.
- thinkpad20 13y ago
  With the kind of guarantees that Haskell's type system provides, I'd imagine that wouldn't be much of an issue. It's certainly an issue in CoffeeScript because that language has barely any more safety than JavaScript. Once the Haskell were compiled, the generated JavaScript would be necessary to read in the same way that the generated object code is when using GHC - that is, essentially never. I never use the debugger in Haskell, anyway, and I don't think most do. The type system and a strong suite of tests will suffice for most things. Although I'd be concerned about laziness, especially in a language without Haskell's GC.

pweissbrod 13y ago

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.

ef4 13y ago
If you're still suffering that pain you need to switch to better build tools. Source map support is pretty mainstream now. If I open Chrome Dev Tools on my production site, it automatically grabs source map files from my server (accessible only to me), and I see the whole source tree of original coffeescript files, with complete access to breakpoints and stack traces.
thinkpad20 13y ago
With the kind of guarantees that Haskell's type system provides, I'd imagine that wouldn't be much of an issue. It's certainly an issue in CoffeeScript because that language has barely any more safety than JavaScript. Once the Haskell were compiled, the generated JavaScript would be necessary to read in the same way that the generated object code is when using GHC - that is, essentially never. I never use the debugger in Haskell, anyway, and I don't think most do. The type system and a strong suite of tests will suffice for most things. Although I'd be concerned about laziness, especially in a language without Haskell's GC.