Open srid opened 7 years ago
@HappyAndHarmless any first hand accounts from your side about Elm or Purescript?
@saurabhnanda Not yet. First getting a hang of Haskell. I imagine it would take a while before I get my hands dirty on PureScript.
In the process of writing a mancala game in Elm I came across two pain points with the language and community that makes me consider just using PureScript for personal projects henceforth:
The lack of type classes can become annoying once the project becomes sufficiently big (more on this; ref).
The Elm culture is mostly geared toward converting JavaScript developers, and as such much of the language decisions do not appeal to me. elm-format
is one such example (for example, see the discussion on tab size; ref), and the lack of where
clause is another (ref).
More discussion on this at HN; ref
It seems to me that Purescript is better than Elm for several reasons: Pros:
Cons:
Not sure if pro/con:
I think that a more interesting discussion would be between Purescript and GHCJS
The lack of type classes can become annoying once the project becomes sufficiently big (more on this; ref).
Any first hand example that you can share?
Any first hand example that you can share?
I can share two examples from the same project.
setSeeds : Int -> Int -> Board -> (Maybe Board)
setSeeds idx seeds board =
lookup idx board
`Maybe.andThen` (\pit -> Just <| Array.set idx { pit | seeds = seeds } board.pits )
`Maybe.andThen` (\newPits -> Just { board | pits = newPits })
validateF : (a -> Bool) -> a -> Maybe a
validateF f v = if f v then Just v else Nothing
sow : Player -> Int -> Board -> Maybe Board
sow player idx board =
let
spread seeds fromIdx board = Just board
in
lookup idx board
`Maybe.andThen` validateF (\pit -> player == pit.player)
`Maybe.andThen` (\pit -> setSeeds idx 0 board `Maybe.andThen` (\b -> Just (pit, b)))
`Maybe.andThen` (\(pit, b) -> Just b
Above all unlike the Haskell community I noticed behaviours of bumptious nature (one of which was ironically in the name of upholding couth) in the Elm community.
@nmdanny I think that a more interesting discussion would be between Purescript and GHCJS
I would be interested in that. A notable advantage of GHCJS for me is that you can use Haskell libraries, such as the Diagrams package (just need a new backend).
PureScript vs GHCJS: PureScript is currently lacking an higher order FRP library, and it might not change soon. PS works on top of JS runtime, and it's lacking weak references which are crucial for such implementation. Check sodium-typescript to see what workarounds were needed to implement it.
@BartAdv Can you explain about
PureScript is currently lacking an higher order FRP library
We are using PureScript Pux and Thermite is something we are exploring for Web. Thermite is working great for Mobile Development.
Yes, that's not like saying the lack of higher order FRP means your libaries are crippled, they will still work great, they will just offer different way of approaching things. I'll just link the similar question asked about the reflex-dom, as it is not that easy to explain both approaches and the differencies between them without actually trying both and seeing which one you're more comfortable with:
@BartAdv
Thermite is awesome for defining everything as Spec's and React is in the background. React has one of the highest performance and React Fiber is going to make things even better!
http://isfiberreadyyet.com/ as of now... 95.1% is done
Regarding Elm vs PureScript which is what this discussion all about.
Elm we need to write a lot more boiler plate code compared to PureScript. Especially JSON decode and encode. We have worked with Elm in a client Project and we were much more happy working with PureScript... so we ended up migrating to PureScript from Elm.
There are a lot of libraries for almost anything... and if there is anything missing then we will be happy to build those things which we need.
Also, We have RNX (https://github.com/atomicits/purescript-rnx) which is for developing React Native Applications. Which we are using for a client project.
For us PureScript is a Win-Win!
We loved Elm... but there are a few issues...
Especially... not being able to collaborate or communicate with Elm developers... they haven't been very friendly... and ofcourse... Evan will disappear for a few months and work on things while PR's will become stale. And developing custom packages with Native
code and contributing to Open Source with Elm... forget it...
PureScript contributors are super awesome! They are responsive and they really collaborate!
For those that arrive here late, one another option to consider is GHCJS.
Specifically Reflex.
One key advantage here is the ability to share types between the frontend and the backend. Furthermore reflex-platform provides tools the build Android and iOS apps out of the same frontend code base. Everything is in Haskell. This is already being used in production (eg: wrinkle uses it)
@srid
One key advantage here is the ability to share types between the frontend and the backend
If your Types.hs
is shared, yes., which means it has to be a monorepo for front and back. Which means that you're still stuck to GHC 8.6 for the front and the back, while GHC 9.1 is about to become LTS soon. In short, you need to accept that your backend uses a 3-years stale version of GHC if you want to benefit from type sharing.
Wow, this issue is nearly 5 years old. Back to this topic, you might be interested in my notes here.
Very interesting, thanks. The GHCJS devs seem to be all about 8.10 branch as of now, and I agree that more than a year of no update for master is not the best signal.
Have you ever tried Miso, the GHCJS framework? Looks quite well maintained from what I can see. Not sure if it answer your concerns about Obsidian Systems.
Some links to interesting discussions here: https://twitter.com/ravi_mohan/status/784246016555884544