Fay: a subset of Haskell that compiles to JavaScript | Hacker News Reader

Fay: a subset of Haskell that compiles to JavaScript

fay-lang.org

74 pointssadiq27 comments

I'm really curious about the article "http://www.yesodweb.com/blog/2012/10/yesod-fay-js " that is linked to in the "Fay in the Wild" section.

Does anyone know how hard it would be to integrate AngularJS with Fay as described? Sounds like it would be a great way to build large client-side applications entirely in Haskell (Fay).

There is previous discussion here: http://news.ycombinator.com/item?id=4276625 (106 comments of discussion, in fact).

For those interested in functional programming, but with a desire for something a bit more pragmatic (and highly compatabile with CoffeeScript), you can check out LiveScript http://livescript.net

Functional Programming in JavaScript using LiveScript and prelude.ls: http://livescript.net/blog/functional-programming-in-javascr...

What is unpragmatic about Fay?

LiveScript compiles almost 1 to 1 to JavaScript and has no runtime, making it easier to debug and comprehend for JavaScript programmers. You can access and use any JavaScript library without having to resort to a special syntax. For JavaScript programmers, it may be easier to use LiveScript. For Haskell programmers, it may be easier to use Fay.

I think many JavaScript programmers are looking for JavaScript (CoffeeScript) + functional programming rather than something purely functional as it allows them to use all that they've learned and mastered from JavaScript (often in an enhanced way) while using functional concepts as they learn them.

The toolchain and mapping are too difficult.

They aimed high but made too many concessions from a web-developer point of view.

LiveScript is more like a functional sugar coat over JS, so it preserves most JS core semantics. Especially strict evaluation and duck typing. Because of that, i think it is much easier to do the conversion from the JS world to LiveScript, and viceversa.

Introducing Laziness, pureness and static typing into the JS world is a much bigger challenge. I'd love to see some of these efforts take off; especially Elm, which is even more ambitious, as it not only provides a safer alternative to JS, but also to the DOM model and HTML altogether.

The biggest problem i see these projects facing is the abstraction gap. As the abstraction over JS/DOM that they provide is much bigger than, say, CoffeeScript of LiveScript, when that abstraction breaks and you have to dig into the generated JS/DOM world, it's very painful. And this is a necessary pain every time things don't work as expected and you need to debug in the browser. I think that for these projects to be successful efforts like source maps are crucially important. But for projects as ambitious as Fay or Elm, i think we need even better debugging tools; some environment where we can debug entirely within the abstraction layer that these languages provide, and make the cases where you have to resort back to JS much more uncommon.

I'm not big on the glaringly inefficient transpilers that Haskell has come up with. You can replicate a lot of Haskell's functionality in JavaScript very elegantly.

See for instance:

* https://github.com/clux/autonomy - prelude like thing

* https://github.com/clux/subset - basically Data.List

* https://github.com/clux/operators - currying helpers

* https://github.com/clux/interlude - a collection of the above 3

It has made my JavaScript development very enjoyable. JavaScript really doesn't suck have to suck. You can write very elegant code in it. It's just not as elegant as Haskell.

Absolutely. I hate JS as much as the next person, but I hated the for lack of a better word, fuckedupedness, of dozens of languages and yet I still programmed in them. coughPerlcough

Elegance is never the primary concern of code. Readability is. And they are not the same thing. Even Perl can be made readable.

Its semantics are still silly and extremely error-prone.

Also, that's not the point. There's already Roy and Elm for simpler compilation and decent semantics with interesting features. Fay lets you share code between server and client.

Fay has to be compiled using a compiler that can't run in the browser, which is a disadvantage from my point of view.

Personally, I quite like roy http://roy.brianmckenna.org/.

Why do you see that has a disadvantage? From a production perspective, I don't think it would matter much, since you'd most likely compile your app to JS ahead of time no matter what, for performance reasons. From a development perspective, I guess it could be annoying from the compile-debug-refresh cycle. But I could also imagine a tool to watch your app for any changes, recompiling on demand.

Anyway, if you really wanted to run Fay in the browser, you could probably get it to work using UHC (http://uu-computerscience.github.com/uhc-js/) pretty easily.

The compile-debug-refresh cycle is exactly the problem. Tools that watch the file system are no substitute for servers that can guarantee you get the latest version when you hit f5.

Quickly and reliably seeing your code in action is one of the more important things you do when coding, and anything that messes with that makes your life less fun, more painful and less productive.

> Tools that watch the file system are no substitute for servers that can guarantee you get the latest version when you hit f5.

How are these mutually exclusive? If you want a server that automatically runs the most recent (working) build of a piece of code, it's rather straightforward to implement.

I don't want the most recent (working) build of a piece of code, I want to see in my browser exactly what I have on my disk, and I want to see it every time without worrying about caching or whether my build loop has finished or not.

Again, all problems that are pretty easy to solve with existing server-side build tools.

ClojureScript is not yet self-hosting. That is, the compiler does not run in the browser, although quite a few people want it to, so it's being worked on a bit.

That said, I haven't found it to have any serious impact on my development experience. There is no compile-debug-refresh cycle because I can evaluate forms against the browser REPL remotely. Compilation occurs server side and the JavaScript code is eval-ed on the client.

More details here: http://blog.fogus.me/tag/clj-compilation/

Yes, when you can update parts of the code on the page with a streaming connection it's a little bit different. I guess I'll give ClojureScript a pass on that one, but it's not a feature that nonlisp systems seem very keen on integrating so far.

Ought to be easy to serve the code from a script that compiles on demand. I assume you'd want a cache, but a simple modification date check will ensure that it's always up to date. Of course, having to build this is worse than not having to.

That is why debugging JS that was written in some ridiculous language that compiles to JS becomes quite difficult. The other problem is trying to figure out the fix in the original language which may not be obvious. But this is not a popular opinion. Not that I care that today's programmers would rather require that a web app be written in 10 languages rather than 4 (Serverside, JS, CSS, HTML).

Adding complexity is the opposite of the software development goal. Too bad most people don't get this. Other than shipping your software on time and sometimes even above that goal, is reducing complexity. Too bad most people go the other way because it's "cool."

They shall pay the price.

Source maps go some way to making debugging code written in another language less painful. I more or less agree on the language side though. For real web development anything other than javascript should be providing you with a massive benefit to offset the disadvantages of adding a build step to your workflow and having to debug in a language different to the language you're coding in. I've not found anything that I think gives me a big enough benefit yet to make it worth it.

It's missing the whole point of interpreted languages. I hate JS as much as the next person, but in the end, if you don't know JS well, these languages will only hinder your progress.

If you want a different browser scripting language, start hacking on Firefox and Chromium and start a campaign to get it adopted. Otherwise, you are adding unnecessary complexity to apps that are already unnecessarily complex in the first place. Coffeescript, Fay, whatever. Build it right or stop with this bullshit.

"Amen".

And you think you'll get your new language adopted by Chrome, Firefox, IE and mobile devices? It's not happening.

I don't really see this extra complexity. You might almost as well dismiss all software development that isn't done in raw machine code. Plus, JS these days is blisteringly fast — if it helps, think of it as the web's assembly language.

It's highly unlikely, but it's the path to pursue. JS is not the web's assembly language except to people who can't program in it. The added complexity is another (3rd, 4th++) language. If you can't see that, you're blind.

Another language that compiles to JS. Really? Just learn Javascript already.

Reply on news.ycombinator.com