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. Why don't we have similar abstractions for when a client-side program (CPU) needs to access something on the server (RAM)?
Does anyone know of other tools trying to accomplish this? I'm not a Haskeller but am tempted to dive in just for this feature.
It is possible, somewhat, but you get very ugly web api's, because they are 'implementation before contract' instead of designing an api first, and then letting both sides adhere to it.
The problem is that those ancient web api's were effectively javascript windows.forms emulators running on the client getting their calls from the server side. That, of course, sucks, because of the latency. Stuff that actually pulls your program apart into server and client pieces is beautiful.
The problem, of course, is that doing it the right way requires rewriting a compiler from scratch. Doing the "emulate the UI library and hang it behind an RPC" is easy, but sucks.
You get what you pay for.
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.
I'd love to find out more about how Haste manages the intersection between client and server since it is capable of existing as a client-side only app. Hopefully it has a well defined API and writing plugins for different sources of data is clear and simple.
(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.
For abstracting away CPU/RAM communications the answers are clearly yes/no. But what are the answers for the abstraction that the OP referred to?
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.
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.
Who knows, maybe Haste will be different, but I really don't think so.
Doesn't that kill one of the best aspects of the web: client independence?
While on the topic of the landing page, it doesn't scale well in chrome on linux. I use two windows side by side and the navigation bar breaks around 938px width, which is just short for me.
The text itself is well written and clearly thought through though, with the right amount of detail.
code samples can really only give you a feel for the language, any more and it belongs in tutorials and API documents.
It's not useful information regarding the usefulness of this but I am curious.
[1]: https://prezi.com/
...and yes, I tried disabling JavaScript and it doesn't work.
Makes me not want to use it professionally.
Haste of course goes WAY further than CoffeeScript. But the rationale is the same. I enjoy writing Haskell much more than JS. If I can write Haskell and convert it to JS, I'll do it every time.
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.
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.
Haste is not "more useful"; but it's approach is quite different.
Read my other comment on this page for more info on the differences.
Yesod is server side, it has Julius, but that's just JS with safe inserts from the outside.
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 recent Ubuntu:
http://www.hoppinger.com/blog/haskell-in-the-browser-setting...
With Haste the server-side and client-side code live side-by-side in the same files. I "got it" by reading this code:
https://github.com/valderman/haste-compiler/blob/master/exam...
For what I understand Haste does client-sever communication over websockets and yields webapps that are full-JS (therefore difficult to do SEO).
I often read the people are afraid of debugging with compiled JS; I must say that since I need a lot less debugging when using when compiling Haskell to JS. So far all my debugging needs are fulfilled with simple print/alert/console.log statements.
While 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.
But larger applications quickly grow quite a bit, reaching a megabyte or multiple is not uncommon in the land of GMail and similar apps.
Growing your JavaScriot "binary" size by a factor of three might be a problem for such applications. It doesn't sound that much, but the difference between download, parsing, and running 1 MB of JS vs 3 MB of JS is several hundred milliseconds on a very good connection and a beefy desktop machine.
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.
> with a different set of standard libraries
Is there a technical reason why it would be ill advised to just make Haste itself into a separate library that can be included into the regular Haskell ecosystem? Doesn't this type of fragmentation cause huge delays in the progress of a language, ultimately?
Hopefully it's obvious that I'm entirely not knowledgeable about these things and that I'd love for someone to explain this to me.
The relevant question is only how leaky each layer of abstraction is.
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.