Thanks for the suggestion! I haven't looked deeply at PureScript. Although it sounds like a scary place right now. :) I also don't get as much into the Haskell-y stuff like HKTs and so forth. But I will check it out!
It's really not that bad/complicated to learn (HKT's and PureScript) - but you gain some incredible cool powers ;)
To give you a small glimpse: if you understand what comparable is about in Elm you basically understood type-classes. But instead of have a fixed set of them that only works with a predefined subset you can add you own types to them (it's called making your type an instance of it) and you can even define your own type-classes if you want, but that is rarely needed.
If you understood what Cmd is about you are ready to talk about effect system - but again you can do it on a level where you are in more control of the runtime and where you are allowed to use effects (still everything is pure).
this framework is very Elm-inspired and you should get a good idea (normally I would advise PUX but right now the documentation was not updated for purescript-0.12 and so this might confuse you too much)
My original plan for An Outsider's Guide to Statically Typed Functional Programming was to transition from Elm to PureScript. The free sample of the current draft has most of the PureScript text. I motivate type classes in a couple of the Elm chapters (also included), which I think makes them less imposing.
Spork seemed to me the best PureScript implementation of The Elm Architecture.
However, I'd only put PureScript into production if I had people with Haskell experience and a good amount of time to become contributors. The community is friendly to beginners, but there's a vast amount of background that isn't explained in a systematic way, and the community standards for documentation and infrastructure just aren't up to the level we've come to expect from systems like Elm or Elixir or even Clojure. This is not seen by the opinion leaders as a problem - I hope it eventually will - but it makes PureScript something best suited for technology enthusiasts or visionaries.
That leaves me without a second half of the book. I will probably continue to work on it because things like type classes and effects are intellectually interesting. But my original hope - learning it well by describing it well, then using it for real work - isn't going to come to pass. I'm thinking of trying ReasonML from the F#/OCaml line of hybrid FP tools. I think it would be an easier transition from Elm than PureScript would be.
Disclaimer: I was too strident in claiming that PureScript needs documentation and infrastructure up to the modern standard. Many PureScript people think I'm a jerk and also biased. I don't think so (at least about the bias), but they could be right.
Agreed with the Purescript documentation, I takes a long time to become at home in that. Lot's of stuff is folklore and/or Haskell derived knowledge.
Still less frustrating than Elm.
Regarding ReasonML: it is like the saner brother of Elm, with a normal type system and mature tooling behaviour; in this way it's easier and better than Purescript, IMHO.
Both are highly recommended. FWIW, we are moving our code away from Elm to Purescript, Haskell, Idris and ReasonML.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the suggestion! I haven't looked deeply at PureScript. Although it sounds like a scary place right now. :) I also don't get as much into the Haskell-y stuff like HKTs and so forth. But I will check it out!
It's really not that bad/complicated to learn (HKT's and PureScript) - but you gain some incredible cool powers ;)
To give you a small glimpse: if you understand what
comparableis about in Elm you basically understood type-classes. But instead of have a fixed set of them that only works with a predefined subset you can add you own types to them (it's called making your type an instance of it) and you can even define your own type-classes if you want, but that is rarely needed.If you understood what
Cmdis about you are ready to talk about effect system - but again you can do it on a level where you are in more control of the runtime and where you are allowed to use effects (still everything is pure).If you want to try it out this might be a good start: github.com/utkarshkukreti/purescri...
this framework is very Elm-inspired and you should get a good idea (normally I would advise PUX but right now the documentation was not updated for purescript-0.12 and so this might confuse you too much)
My original plan for An Outsider's Guide to Statically Typed Functional Programming was to transition from Elm to PureScript. The free sample of the current draft has most of the PureScript text. I motivate type classes in a couple of the Elm chapters (also included), which I think makes them less imposing.
Spork seemed to me the best PureScript implementation of The Elm Architecture.
However, I'd only put PureScript into production if I had people with Haskell experience and a good amount of time to become contributors. The community is friendly to beginners, but there's a vast amount of background that isn't explained in a systematic way, and the community standards for documentation and infrastructure just aren't up to the level we've come to expect from systems like Elm or Elixir or even Clojure. This is not seen by the opinion leaders as a problem - I hope it eventually will - but it makes PureScript something best suited for technology enthusiasts or visionaries.
That leaves me without a second half of the book. I will probably continue to work on it because things like type classes and effects are intellectually interesting. But my original hope - learning it well by describing it well, then using it for real work - isn't going to come to pass. I'm thinking of trying ReasonML from the F#/OCaml line of hybrid FP tools. I think it would be an easier transition from Elm than PureScript would be.
Disclaimer: I was too strident in claiming that PureScript needs documentation and infrastructure up to the modern standard. Many PureScript people think I'm a jerk and also biased. I don't think so (at least about the bias), but they could be right.
Agreed with the Purescript documentation, I takes a long time to become at home in that. Lot's of stuff is folklore and/or Haskell derived knowledge.
Still less frustrating than Elm.
Regarding ReasonML: it is like the saner brother of Elm, with a normal type system and mature tooling behaviour; in this way it's easier and better than Purescript, IMHO.
Both are highly recommended. FWIW, we are moving our code away from Elm to Purescript, Haskell, Idris and ReasonML.