5 ms·

Very interesting! For those who are more involved in this field, how does PureScript compare to other functional programming languages that also compiles to jav

by xiamx 10y ago

Very interesting! For those who are more involved in this field, how does PureScript compare to other functional programming languages that also compiles to javascript?

seagreen 10y ago
PureScript emphasizes a solid theoretical foundation. Its closest competitor, Elm, emphasizes ease of learning and use. Both are very tastefully designed (so I've heard, I haven't used Elm myself). If you're coming from something like Haskell and really value correct abstractions go with PureScript. If you need something working right now and don't plan on pushing the boundaries of the language then Elm should be fine.
thelambentonion 10y ago
IMO, PureScript has some very interesting advantages in comparison to other functional languages targeting JavaScript. It has a very strong type system, a compiler that can produce optimized and human readable JavaScript, and dead simple FFI. It _also_ doesn't rely on a runtime like Elm or GHCJS do, so the resulting code size is typically much smaller. It's also been used to build some really interesting and unique takes on the frontend design problem (cf. Pux [0] and Halogen [1]). [0] https://github.com/alexmingoia/purescript-pux https://github.com/alexmingoia/purescript-pux [1] https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen
- hawkice 10y ago
  The Elm runtime does tend to bother me, despite it being smaller than jQuery (I've lived in a country with ~40kb/s internet... it's brutal out there if you pile on those kilobytes). But with dead code elimination plus a smarter inlining system I think this concern _could_ evaporate.
- sjrd 10y ago
  > and dead simple FFI That's very accurate. So dead simple that as soon as you want to manipulate something else than primitive values and functions from JS, you hit a dead end. How do you read a field from a JS object? How do you call a JS method? For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with. It's also striking to me that the documentation of PureScript FFI [1] has to teach you what the output of the compiler will be so that you can use the FFI. Am I really supposed to know about those `$`s? What if the compiler improves and changes its internals? I'm sorry if my comment is perceived as a rant, but I can never understand how people can call PureScript's FFI good. Compare it to interoperability in TypeScript, ClojureScript, or Scala.js, and it is way behind! [1] http://www.purescript.org/learn/ffi/ http://www.purescript.org/learn/ffi/
  - kika 10y ago
    It sounds like bashing. Here's my unfinished, but working code, interfacing Google Apps Script to Purescript https://github.com/kika/purescript-google-appsscript/tree/master/src/Google/AppsScript https://github.com/kika/purescript-google-appsscript/tree/ma... Please tell me what is so _dead_ in it. Though I'm pretty new to Purescript and to the Haskell world in general, it took me almost no effort to write this code once I figured out how Data.Function (renamed Data.Function.Uncurried in the latest Purescripts) works. Probably your issue with Purescript FFI was about not being aware of these helpers (which don't do much help per se, but remove ugly clutter of nested functions in JS code).
    - gilmi 10y ago
      I also had a pleasant experience and didn't hit a dead end. I documented my experience here: http://gilmi.xyz/post/2016/05/09/ld35 http://gilmi.xyz/post/2016/05/09/ld35
    - sjrd 10y ago
      I guess my comment qualifies as bashing. It still is what I think, though. Look at your own code from https://github.com/kika/purescript-google-appsscript/tree/master/src/Google/AppsScript https://github.com/kika/purescript-google-appsscript/tree/ma... There is more JS code than PureScript! Why? Because you need bridge JS code for pretty much every JS library you want to call. Which is precisely the point I make in the grand-parent: "For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with."
hawkice 10y ago
I like Elm a lot. It's much much simpler than PureScript, lacks some of the advanced features, but as an advanced user of Elm, I've found I don't really mind -- all the important stuff is there (structural types, tagged unions and polymorphism working with a type checker, for instance, is very good, even if you don't have typeclasses). I've made dozens of web apps with Elm, and I think it's fair to say that, when I started, I wanted the deep toolkit PureScript has. It turns out if I don't get it I spend more time writing code that delivers features. This is probably not true of everyone, but it is true of me. Edit: also, Elm has a community (hard to manage for smaller userbases, like PureScript), and they have only been kind and eager to help in my experiences.

by xiamx 10y ago

Very interesting! For those who are more involved in this field, how does PureScript compare to other functional programming languages that also compiles to javascript?

seagreen 10y ago

PureScript emphasizes a solid theoretical foundation. Its closest competitor, Elm, emphasizes ease of learning and use. Both are very tastefully designed (so I've heard, I haven't used Elm myself). If you're coming from something like Haskell and really value correct abstractions go with PureScript. If you need something working right now and don't plan on pushing the boundaries of the language then Elm should be fine.

thelambentonion 10y ago

IMO, PureScript has some very interesting advantages in comparison to other functional languages targeting JavaScript. It has a very strong type system, a compiler that can produce optimized and human readable JavaScript, and dead simple FFI. It _also_ doesn't rely on a runtime like Elm or GHCJS do, so the resulting code size is typically much smaller. It's also been used to build some really interesting and unique takes on the frontend design problem (cf. Pux [0] and Halogen [1]). [0] https://github.com/alexmingoia/purescript-pux https://github.com/alexmingoia/purescript-pux [1] https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen

hawkice 10y ago
The Elm runtime does tend to bother me, despite it being smaller than jQuery (I've lived in a country with ~40kb/s internet... it's brutal out there if you pile on those kilobytes). But with dead code elimination plus a smarter inlining system I think this concern _could_ evaporate.
sjrd 10y ago
> and dead simple FFI That's very accurate. So dead simple that as soon as you want to manipulate something else than primitive values and functions from JS, you hit a dead end. How do you read a field from a JS object? How do you call a JS method? For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with. It's also striking to me that the documentation of PureScript FFI [1] has to teach you what the output of the compiler will be so that you can use the FFI. Am I really supposed to know about those `$`s? What if the compiler improves and changes its internals? I'm sorry if my comment is perceived as a rant, but I can never understand how people can call PureScript's FFI good. Compare it to interoperability in TypeScript, ClojureScript, or Scala.js, and it is way behind! [1] http://www.purescript.org/learn/ffi/ http://www.purescript.org/learn/ffi/
- kika 10y ago
  It sounds like bashing. Here's my unfinished, but working code, interfacing Google Apps Script to Purescript https://github.com/kika/purescript-google-appsscript/tree/master/src/Google/AppsScript https://github.com/kika/purescript-google-appsscript/tree/ma... Please tell me what is so _dead_ in it. Though I'm pretty new to Purescript and to the Haskell world in general, it took me almost no effort to write this code once I figured out how Data.Function (renamed Data.Function.Uncurried in the latest Purescripts) works. Probably your issue with Purescript FFI was about not being aware of these helpers (which don't do much help per se, but remove ugly clutter of nested functions in JS code).
  - gilmi 10y ago
    I also had a pleasant experience and didn't hit a dead end. I documented my experience here: http://gilmi.xyz/post/2016/05/09/ld35 http://gilmi.xyz/post/2016/05/09/ld35
  - sjrd 10y ago
    I guess my comment qualifies as bashing. It still is what I think, though. Look at your own code from https://github.com/kika/purescript-google-appsscript/tree/master/src/Google/AppsScript https://github.com/kika/purescript-google-appsscript/tree/ma... There is more JS code than PureScript! Why? Because you need bridge JS code for pretty much every JS library you want to call. Which is precisely the point I make in the grand-parent: "For all these things, you have to write "bridge" JS code that exposes JS libraries in a way that PureScript is happy with."

hawkice 10y ago

I like Elm a lot. It's much much simpler than PureScript, lacks some of the advanced features, but as an advanced user of Elm, I've found I don't really mind -- all the important stuff is there (structural types, tagged unions and polymorphism working with a type checker, for instance, is very good, even if you don't have typeclasses). I've made dozens of web apps with Elm, and I think it's fair to say that, when I started, I wanted the deep toolkit PureScript has. It turns out if I don't get it I spend more time writing code that delivers features. This is probably not true of everyone, but it is true of me. Edit: also, Elm has a community (hard to manage for smaller userbases, like PureScript), and they have only been kind and eager to help in my experiences.