61–70 of 78 posts
How is it more useful than Yesod ( http://www.yesodweb.com/ ) and other existing web app frameworks in Haskell?
Yesod is server side, it has Julius, but that's just JS with safe inserts from the outside.
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.
Makes me not want to use it professionally.
Do you really think we're going to be writing raw JS the whole time? The trajectory of computing has always been to build higher levels of abstraction, especially when the implementation technology is kludgy.
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?
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).
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…
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.
Earlier quoted context omitted.
Thanks Chris, that is interesting. BTW, I am a happy customer of FP Complete. I have bought four Haskell books in the past, but Haskell has never really clicked for me (but studying Haskell has helped using Clojure). Whenever I get some free time I use your IDE and online lessons. My hope is that by the time my one year subscription is up, that I will be comfortable sometimes using Haskell instead of Clojure or Java…
Hi, Mark. I'm curious at what point Haskell lost you, if you can identify that. I'm asking, because I'm also learning Haskell at the moment, but because I'm also interested in teaching and I'm thinking about how certain topics could be taught better.
> In essence, Haste lets you write your client-server web application as a single, type-safe program, rather than two separate programs that just happen to talk to each other over some web API as is traditional. I've been thinking about this same idea recently and find it very attractive. As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it. Wh…
I think it comes down to two questions: (a) Does the abstraction actually lead to productivity gains in the long run, including time spent on debugging a possibly leaky abstraction? (b) Does controlling these things manually enable you to provide a user experience that is sufficiently better to at least cover the costs of any lost productivity? For any particular abstraction to be viable the answers need to be yes/no…
It does if you're able to share libraries between client and server. Writing one module for a particular data structure and using it on both client and server is a huge boon.
Earlier quoted context omitted.
Hi, Mark. I'm curious at what point Haskell lost you, if you can identify that. I'm asking, because I'm also learning Haskell at the moment, but because I'm also interested in teaching and I'm thinking about how certain topics could be taught better.
The "problem" I have had has been not setting aside enough time to use Haskell exclusively for a while. I need to do one reasonably large project in Haskell, which is a problem in setting aside the time.
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.
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.