
Haste language - kruipen
http://haste-lang.org/
======
skrebbel
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".

~~~
seanmcdirmid
I don't know. I think language landing pages look better with a little bit of
code at least.

~~~
GhotiFish
well... I mean it's Haskell.

code samples can really only give you a feel for the language, any more and it
belongs in tutorials and API documents.

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

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

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?

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

------
octagonal
I don't exactly understand why Haste was made into a separate dialect when it
"just" has a different stdlib?

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

~~~
azernik
This is a definitional issue more than a technical one - if you follow the
link to the Haskell package documentation [1], the project actually consists
of aforementioned standard library, plus a Haskell-to-JS compiler. This is a
"dialect" of Haskell in the same way that we can speak of the GCC and Intel
dialects of C and C++ - both compilers support the same standard, but each
supports a different set of non-standard extensions. In this case, the Haste
front page notes that it supports _most_ , but not all, GHC extensions to the
Haskell standard.

[1] [http://hackage.haskell.org/package/haste-
compiler](http://hackage.haskell.org/package/haste-compiler)

------
mattgreenrocks
I'm a bit disappointed this is getting so little response here. It's clearly
trying to improve the state of the art of web app dev, and in a powerful
language, to boot.

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.

------
boothead
Haste is looking more and more awesome! However, we've taken the route of
clojurescript/om for building on top of a Haskell web app. cljs just seems a
bit more "there" as a compiles to js language. I would have loved to have used
something like Haste or Fay, but for right now (taking a deep breath and
giving up the type safety) I think the clojurescript eco-system looks the
stronger for functional programming in the browser. The browser repl from
emacs/lighttable is also a pretty impossible feature to beat!

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

~~~
pseudonom-
My impression is that Fay has been in (at least moderate) use the longest.
GHCJS seems to be getting a lot more viable lately. Elm (which is only
Haskellish rather than fully Haskell-compatible) isn't listed on that page,
but is getting quite nice.

~~~
tel
I usually hear that Haste produces the nicest target Javascript and GHCJS
perhaps the worst... but GHCJS will probably continue to get more momentum.

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

------
sanxiyn
[http://ocsigen.org/js_of_ocaml/](http://ocsigen.org/js_of_ocaml/) is a
similar project for OCaml.

------
icambron
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?

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

~~~
Groxx
But bugs happen everywhere, and I don't expect Haste to abstract and fix all
possible browser bugs. When <experimental feature X> changes subtly and you
get an exception, how do you track it down? How about when the browser just
freaks out and inserts a NaN in a place type safety says it can't?

~~~
quchen
Whatever the cause - code, compiler, browser - what you have is a NaN in the
wrong place, so the usual techniques apply: Test your code (which usually
consists of fairly small functions) using Haskell's excellent testsuites,
figure out error location with Debug.Trace, etc.

In the end, this is like asking what happens when the assembler "freaks out"
(inserts 0 at a random location), or your architecture is wrong (Pentium FDIV
bug): things may become difficult. (There is no type safety to help you on the
JS level, much like there is no type safety in machine code. When you insert a
wrong value, your code will misbehave in an unpredictable way.)

~~~
Groxx
Except that such things happen a lot more often on browsers. And "softer"
errors, like experimental features being subtly different because user X
toggled checkbox Y (which you don't know about and cannot reproduce) are _not_
going to be caught by test suites.

They _can_ be caught by client-side crash logging / reporting. But if they're
useless, you just lost the ability to fix bugs you don't see yourself in your
nice up-to-date dev environment. These bugs happen with surprising frequency
in any reasonably-used site.

------
ldubinets
This is interesting (and exciting). I would love to see an implementation of
TodoMVC ([http://todomvc.com/](http://todomvc.com/)) in Haste.

------
z3phyr
How is it more useful than Yesod
([http://www.yesodweb.com/](http://www.yesodweb.com/)) and other existing web
app frameworks in Haskell?

~~~
gamegoblin
Presumably because you can write in-browser apps that you would typically
write in JS, in Haskell. AFAIK Yesod is just another web framework a la rails,
django, etc.

------
cies
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 recent Ubuntu:

[http://www.hoppinger.com/blog/haskell-in-the-browser-
setting...](http://www.hoppinger.com/blog/haskell-in-the-browser-setting-up-
yesod-and-fay)

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...](https://github.com/valderman/haste-
compiler/blob/master/examples/sendfile/sendfile.hs)

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.

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

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

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

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

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

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

~~~
chrisdone
I have the same problem with Agda and Idris. ;-)

------
elwell
Should really have a link to the great examples:
[https://github.com/valderman/haste-
compiler/tree/master/exam...](https://github.com/valderman/haste-
compiler/tree/master/examples)

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

~~~
egeozcan
It looks like: [http://haste-lang.org/main.js](http://haste-lang.org/main.js)

...and yes, I tried disabling JavaScript and it doesn't work.

~~~
zeitg3ist
Also, predictably: [http://haste-lang.org/main.hs](http://haste-
lang.org/main.hs)

------
mtford
These layers upon layers just seem painful to me.

~~~
ef4
Then you may want to consider staying out of the software business. It's
layers all the way down.

The relevant question is only how leaky each layer of abstraction is.

------
BadassFractal
What exactly is the use-case for this? Can't quite get it from the site.

~~~
gamegoblin
Making a JavaScript app with type safety guarantees. Also the pleasure of
haskell in general. Same reason people use CoffeeScript. It compiles to JS,
but you get several advantages of not using JS directly. Either syntactical,
or abstraction of idioms.

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.

