4 ms·

IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrif

IMHO "functional scripters" with a penchant for fewer parens, braces etc and a tendency towards ML-style should seriously embrace PureScript, it's such a terrific project, just gets way too little hype. That's not to rain on ReasonML of course here, which I observed for a while as a very cool transpilation project and kudos to the devs! I'd take a reason project over JS/TS/Ecma any day still

christophilus 9y ago
I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no? That seems like a pretty big downside.
- dualogy 9y ago
  Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
  - christophilus 9y ago
    I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.
    - wereHamster 9y ago
      It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
      - christophilus 9y ago
        Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.
  - lewisl9029 9y ago
    > This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly. What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread. This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board. [1] http://ramdajs.com/ http://ramdajs.com/ [2] http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.
    - hellofunk 9y ago
      I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
      - lewisl9029 9y ago
        GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.
bjz_ 9y ago
When is Purescript going to get rid of the need for Bower? That's a pretty significant turn-off for most folks :(
- msvan 9y ago
  You can use psc-package instead of Bower.
  - bjz_ 9y ago
    Oh, this is great: https://github.com/purescript/psc-package https://github.com/purescript/psc-package Any word of when this will be supported/promoted officially? Just got this response from one of my former JS colleagues: https://twitter.com/keirasaid/status/924169973878046721 https://twitter.com/keirasaid/status/924169973878046721 - it's pretty hard to convince JS developers to use something that is still recommends using Bower for package management. :/
    - dualogy 9y ago
      "Officially" isn't really a thing here, I feel. I mean the `purs` (formerly `psc`) compiler just gets given a list of .purs files from your build setup (pulp, custom make files, a little custom program, whatever) and recompiles what changed to the given output paths. I think they just converged on bower by accident (whatever it professes to offer, the sub-set of features required here for PS apparenty just-worked sufficiently well) but really anyone can manage their packages however they like. psc-package does* very much look like it's going to be the "sanctioned/endorses/semi-official" tooling for pkg-mgmt one way or the other. This popped up just now in my feed reader: https://qiita.com/kimagure/items/0d9354900d7a7dbd3864 https://qiita.com/kimagure/items/0d9354900d7a7dbd3864
- paulyoung 9y ago
  As others have mentioned, psc-package can be used so there is no "need" for Bower. "Why the PureScript community uses Bower" explains why Bower was chosen: http://harry.garrood.me/blog/purescript-why-bower/ http://harry.garrood.me/blog/purescript-why-bower/ I don't understand why Bower is such a sticking point for people. It works perfectly fine for PureScript and (as the article explains) was the right tool for the job.

christophilus 9y ago

I really like PureScript. The one thing that kept me from deep diving into it was that it lacked efficient immutable data structures, unless I'm mistaken. It basically is immutable by doing full copies with variations, no? That seems like a pretty big downside.

dualogy 9y ago
Some truth to this possibly. This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. I mean PS arrays/records map to JS arrays/objects as far as passing/return them, but for those few cases where you really need to mutate inside-a-(no-longer-pure)-func, it's JS-FFI-hackery or (more likely often) a readily-available 3rd-party package offering the persistent or mutable data structure to serve the need at hand. Might not want to write your WebGL 3D game's game loop or a very mathy 2/3/x-dimensional "big array" re-calculation entirely in PS perhaps, sure enough. Depends on what apps you have in mind I guess. Typically in JS what's become more common recently is to map over the structure, extract the small sub-set you actually want to process (reduce/filter) and in the end these copies often turn out small and not so scary. But as always, "it depends". Truly the PureScript/Haskell/Elm family makes mutation harder than all other languages --- with the flip-side that they make immutable purely-functional expression vastly more ergonomic IMHO =)
- christophilus 9y ago
  I guess I'm thinking more along the lines of Clojure(Script) which has efficient immutable lists, vectors, and maps. It doesn't do a full copy every time you do a cons or assoc. It seems to me that PureScript would really benefit from having something similar baked in.
  - wereHamster 9y ago
    It does have efficient maps (purescript-maps) and listss (purescript-lists). Couldn't find any package which provides a Vector type that is not optimised specifically for math operations which always operate on the whole vector (multiply, add, dot product etc).
    - christophilus 9y ago
      Ah. Right. My impression was that most PureScript code just uses plain JS objects / arrays, though. Is that not correct? If the ecosystem isn't built around the efficient immutable data types, much of the advantage disappears.
- lewisl9029 9y ago
  > This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly. What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread. This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board. [1] http://ramdajs.com/ http://ramdajs.com/ [2] http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.
  - hellofunk 9y ago
    I thought that Reason implicitly used Immutable-Re and Bucklescript implicity used Immutable, similar to how Clojurescript implicitly uses its own library from these structures. That is, if you write wholly within the language, you get the benefits of these structures without thinking about it. Is that not true?
    - lewisl9029 9y ago
      GP was talking about PureScript, not Reason. To be honest, I have very little experience with either, but I just wanted to chime in re: the persistent data structures as a library topic with an anecdote from the JS side.

bjz_ 9y ago

When is Purescript going to get rid of the need for Bower? That's a pretty significant turn-off for most folks :(

msvan 9y ago
You can use psc-package instead of Bower.
- bjz_ 9y ago
  Oh, this is great: https://github.com/purescript/psc-package https://github.com/purescript/psc-package Any word of when this will be supported/promoted officially? Just got this response from one of my former JS colleagues: https://twitter.com/keirasaid/status/924169973878046721 https://twitter.com/keirasaid/status/924169973878046721 - it's pretty hard to convince JS developers to use something that is still recommends using Bower for package management. :/
  - dualogy 9y ago
    "Officially" isn't really a thing here, I feel. I mean the `purs` (formerly `psc`) compiler just gets given a list of .purs files from your build setup (pulp, custom make files, a little custom program, whatever) and recompiles what changed to the given output paths. I think they just converged on bower by accident (whatever it professes to offer, the sub-set of features required here for PS apparenty just-worked sufficiently well) but really anyone can manage their packages however they like. psc-package does* very much look like it's going to be the "sanctioned/endorses/semi-official" tooling for pkg-mgmt one way or the other. This popped up just now in my feed reader: https://qiita.com/kimagure/items/0d9354900d7a7dbd3864 https://qiita.com/kimagure/items/0d9354900d7a7dbd3864
paulyoung 9y ago
As others have mentioned, psc-package can be used so there is no "need" for Bower. "Why the PureScript community uses Bower" explains why Bower was chosen: http://harry.garrood.me/blog/purescript-why-bower/ http://harry.garrood.me/blog/purescript-why-bower/ I don't understand why Bower is such a sticking point for people. It works perfectly fine for PureScript and (as the article explains) was the right tool for the job.