6 ms·
Fay: a subset of Haskell that compiles to JavaScript
- dbaupp 14y agoThere is previous discussion here: http://news.ycombinator.com/item?id=4276625 http://news.ycombinator.com/item?id=4276625 (106 comments of discussion, in fact).
- GeZe 14y agoFor 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 http://livescript.net Functional Programming in JavaScript using LiveScript and prelude.ls: http://livescript.net/blog/functional-programming-in-javascript-using-livescript-and-prelude-ls.html http://livescript.net/blog/functional-programming-in-javascr...
- aaronblohowiak 14y agoWhat is unpragmatic about Fay?
- GeZe 14y agoLiveScript 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.
- batgaijin 14y agoThe toolchain and mapping are too difficult. They aimed high but made too many concessions from a web-developer point of view.
- epidemian 14y agoLiveScript 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.
- pilgrim689 14y agoI'm really curious about the article "http://www.yesodweb.com/blog/2012/10/yesod-fay-js 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).
- kybernetikos 14y agoFay 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/ http://roy.brianmckenna.org/.
- michael_miller 14y agoWhy 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/ http://uu-computerscience.github.com/uhc-js/) pretty easily.
- kybernetikos 14y agoThe 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.
- chimeracoder 14y ago> 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.
- kybernetikos 14y agoI 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.
- lucian303 14y agoAnother language that compiles to JS. Really? Just learn Javascript already.
- lucian303 14y agoIf 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.
- jjtheblunt 14y ago"Amen".
- gmac 14y agoAnd 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.
- lucian303 14y agoIt'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.
- clux 14y agoI'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 https://github.com/clux/autonomy - prelude like thing * https://github.com/clux/subset https://github.com/clux/subset - basically Data.List * https://github.com/clux/operators https://github.com/clux/operators - currying helpers * https://github.com/clux/interlude 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.
- lucian303 14y agoAbsolutely. 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.
- lucian1900 14y agoIts 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.