Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haste language

haste-lang.org

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Haste language

#41

Post by waps »

thomasahle wrote: post #15
TheEzEzz wrote: post #12

> 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…

Isn't this exactly the idea of the big RPC suites from 10 years ago? 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.

I would argue that GWT is an example of how it can be done, and it's very hard to beat a well-written GWT app (for the client-server part it's bloody hard to beat a badly written GWT app too).

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.

Re: Haste language

#42

Post by mkohlmyr »

skrebbel wrote: post #10

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".

Personally I think it could definitely do with some small code examples in between paragraphs. Makes me more likely to read my way through the whole thing, but also gives me the option of scanning the examples for something interesting and reading that paragraph first.

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.

Re: Haste language

#43

Post by jeremyjh »

cies wrote: post #32

Haste 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…

This is one way to use Haste but you can also use it similar to how you are using Fay. It does not yet have plugins like Yesod and Snap do for Fay.

Re: Haste language

#44

Post by Nitramp » 

    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.
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 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.

Re: Haste language

#46

Post by chrisdone »

Nitramp wrote: post #44

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. 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 browser temporarily freezes, and I'm on a recent MacBook Pro. At least transfer-wise, generated code compresses well because it's the same repeated patterns over and over which gzip is good at. In the end, though, we prefer the issue of "our page loads a bit slowly, how can we compress or segment our .js files better?" is a much easier and isolated problem to solve than writing such a big codebase in plain JavaScript.

Re: Haste language

#47

Post by cdent »

TheEzEzz wrote: post #12

> 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…

Isn't the result of this class of solutions a service on the web that can _only_ (easily) be accessed by the client code that was specifically written to use that service (by virtue of being built out of the same lump)?

Doesn't that kill one of the best aspects of the web: client independence?

Re: Haste language

#48

Post by rjbwork »

TheEzEzz wrote: post #12

> 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…

Go play with ASP.NET WebForms, then do the same thing in any MVC equivalent. Abstracting away the way the browser and server and HTTP work just leads to painting yourself into a corner where changes that should be quick take waaayyy too long.

Who knows, maybe Haste will be different, but I really don't think so.

Re: Haste language

#49

Post by quchen »

icambron wrote: post #30

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).

Re: Haste language

#50

Post by quchen »

priyadarshy wrote: post #33
BadassFractal wrote: post #9

So out of all these options for Haskell ( http://www.haskell.org/haskellwiki/The_JavaScript_Problem ), what's currently got the most momentum behind it?

Does anyone know of any well-known applications that are using any of the various Haskell -> JS convertors? It's not useful information regarding the usefulness of this but I am curious.

Elm is a "Haskell-like" to JS compiler, and implemented in Haskell. It's used at Prezi [1], a company that was impressed enough by it to hire Elm's lead developer to work on the language there, and probably make use of it for their site.

[1]: https://prezi.com/

Post reply on HN