Elm on the frontend is kinda starting to make me feel the same way I feel about Go on the backend. It makes a lot of things really easy and the APIs are very nice. It always seems like a good choice right up until I find a huge wall caused by the intentional omission of some feature or another, and then I'm back to wondering if I actually like it or not.
I wish folks from these languages with great communities and APIs would work more on languages that are more powerful and expressive.
@b The problem with purescript & ghcjs both is that it seems like they introduce power, flexibility, and expressiveness but ultimately it's still just to draw widgets in a browser. I just don't care enough about frontend for the power to be worth the tradeoffs. Elm is nice because I can forget most of it every time I'm finished with a project, and have nice people, documentation, and novice-friendly APIs when I have to re-learn everything the next time I have to do a frontend project
@b I was thinking that type classes would make it easier to abstract a little bit of stuff out of the event model in a way that would be nice. Building some visualizations for a project mostly written in Haskell, and being able to reuse some of the abstractions I'd built would have been nice. This might be a good argument for GHCjs though I guess.
@cercerilla oh sure, that makes sense. Did you try an extensible record?
type alias Ordish = { inc : a -> a, dec : a -> a }
then you can accept only part of it in a func:
stringifyNext : { x | inc : a -> a } -> a -> String
@cercerilla I wanna talk more about what problems you ran into and what the language/community could do to better support your use case! But also Slack is down so faaaaail
@b when slack is up I can send you some code to give you an idea of what I was trying to do. There’s probably a decent workaround but TBH I didn’t spend too much time on it.
@cercerilla that makes sense! It's a lot of why I like it too 😄
What feature did you run into this time BTW?