Earlier quoted context omitted.
[deleted]
What is a leaky abstraction? Inevitable, I think.
[deleted]
Haste language
51–60 of 78 posts
Re: Haste language
#52While a certain increase in code size over hand-rolled Javascript is unavoidable, an optimized but uncompressed Haste program is normally less than 3x the size of an equivalent hand-written program, making the latency penalty of using Haste minimal. A type safe environment is most useful for large(r) applications; you don't really need it for your 200 or 2000 SLOC jQuery script. But larger applications quickly grow q…
We use Fay at FP Complete, which produces similar sizes as Haste, and our 15K line Haskell codebase compiles down to 1.3MB plain text → 386K through uglifyjs → 36K gzip'd. Actually, Haste uses GHC's STG backend, which desugars and greatly simplifies, so it should output code even smaller (and more efficient) than Fay. It's true that parsing is heavier when you go above the 1MB range. When I open plus.google.com my br…
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 on large projects.
Re: Haste language
#53> 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…
Ocsigen does something similar:
http://ocsigen.org/tuto/manual/tutowidgets
Re: Haste language
#54> 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…
There are enough differences to warrant using different abstractions when appropriate. RAM never fails. Or, it never fails in a way that application code is expected to handle. RAM is cached, and cache is so fast that accessing small amounts of it is often negligible cost, and there's no need to count round trips. RAM is far less likely to be the connection point between different versions or implementations of an application. Are some examples.
Re: Haste language
#55> 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…
"As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it."
Except for when we don't, because the underlying abstractions sometimes do the wrong thing. Random paper on cache-optimizing and the hassles thereof: http://research.microsoft.com/en-us/um/people/trishulc/paper...
The challenge is that even the memory abstraction leaks a little, and the network is nowhere near as fast or reliable as the frontside bus: "abstracting away" a 100ms+ link latency and/or nontrivial packet loss means hitting that leak much sooner.
Re: Haste language
#56Earlier quoted context omitted.
We use Fay at FP Complete, which produces similar sizes as Haste, and our 15K line Haskell codebase compiles down to 1.3MB plain text → 386K through uglifyjs → 36K gzip'd. Actually, Haste uses GHC's STG backend, which desugars and greatly simplifies, so it should output code even smaller (and more efficient) than Fay. It's true that parsing is heavier when you go above the 1MB range. When I open plus.google.com my br…
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.
Re: Haste language
#57> 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…
I think the main feature haste is providing is Haskell to JavaScript compilation. That will increase your productivity by
1. Enabling you to lean on the compiler when refactoring.
2. Decreasing the time you spend debugging.
The fact that it will split your program into client and server side parts is scary though, and interesting. I'll have to investigate further.
Re: Haste language
#58I'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.
Re: Haste language
#59Haste is a great approach to compile Haskell to JS. But I yet have to play with it... I did play with an alternative approach Yesod+Fay; where Yesod is the webframework and Fay the compiler of Haskell to JS. This approach is a bit more traditional in sense that the server-side app and the client-side app are separate (with some code shared by both). I wrote a blog on how to get a Yesod+Fay example app setup on a rece…
In the example you posted it shows an HTML page which I guess would be an easy place to put your SEO content.
Re: Haste language
#60My 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?
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