4 ms·

I tried Elm with much enthusiasm, but ended up putting it aside it for now (0.17) after being bored by JSON decoding (of big, deeply nested API response objects

I tried Elm with much enthusiasm, but ended up putting it aside it for now (0.17) after being bored by JSON decoding (of big, deeply nested API response objects). Could there be a way to more succinctly (declaratively?) express my data types and keep Elm's awesome typing/compiler guarantees, but avoiding the painful construction of repetitive, nested, boring decoders? noredink's json-decode-pipeline [1] seems better than what Elm offers out of the box, but it still feels like a lot of ceremony for something mundane. People building webapps [2] to help users generate boilerplate code seems like a hint something's wrong, isn't it? [1] https://github.com/NoRedInk/elm-decode-pipeline https://github.com/NoRedInk/elm-decode-pipeline [2] http://noredink.github.io/json-to-elm/ http://noredink.github.io/json-to-elm/

nilkn 10y ago
I agree that this is a great example of Elm's shortcomings. I'm not an Elm expert but I don't know anything better than json-decode-pipeline.
- ronjouch 10y ago
  If you (or other passersby) have experience in how JSON decoding is achieved in Haskell (or other statically-typed functional languages), I'd be curious to read some sort of comparison with Elm. A quick Googling suggests Data.Aeson [1] is the popular library in Haskell land. Does it rank better on what I was hoping for (succinctness, ease of use)? If yes, would it be reachable within Elm, or are some Haskell constructs missing in Elm to achieve a similar experience? [1] https://hackage.haskell.org/package/aeson-0.6.1.0/docs/Data-Aeson.html https://hackage.haskell.org/package/aeson-0.6.1.0/docs/Data-...
  - nilkn 10y ago
    Current version: https://hackage.haskell.org/package/aeson-1.1.0.0/docs/Data-Aeson.html https://hackage.haskell.org/package/aeson-1.1.0.0/docs/Data-... The key difference with Aeson is this line: > deriving (Generic, Show) Because of this, it's not necessary in that example to even write the JSON decoder manually. The compiler can generate it on its own. I don't personally know of any way to achieve this in Elm, as Elm doesn't have typeclasses and what's effectively happening here is that an instance of the FromJSON typeclass is being computed by the compiler. A very similar trick is possible in PureScript: http://www.purescript.org/learn/generic/ http://www.purescript.org/learn/generic/
  - codygman 10y ago
    Wasn't quite ready to release this, but it seems relevant so see part two here: https://github.com/codygman/concise-json-parsing-in-haskell/blob/master/README.md https://github.com/codygman/concise-json-parsing-in-haskell/... Please give feedback if you don't mind. I'd also like to wait a bit before officially sharing with wider audiences then this comment gets. Keep in mind that part one is "haskell/lens as explicit as possible" which is why I suggested looking at part two to draw conclusions. Edit: just looked at elm decoder pipeline and it looks very similar to aeson.

nilkn 10y ago

I agree that this is a great example of Elm's shortcomings. I'm not an Elm expert but I don't know anything better than json-decode-pipeline.

ronjouch 10y ago
If you (or other passersby) have experience in how JSON decoding is achieved in Haskell (or other statically-typed functional languages), I'd be curious to read some sort of comparison with Elm. A quick Googling suggests Data.Aeson [1] is the popular library in Haskell land. Does it rank better on what I was hoping for (succinctness, ease of use)? If yes, would it be reachable within Elm, or are some Haskell constructs missing in Elm to achieve a similar experience? [1] https://hackage.haskell.org/package/aeson-0.6.1.0/docs/Data-Aeson.html https://hackage.haskell.org/package/aeson-0.6.1.0/docs/Data-...
- nilkn 10y ago
  Current version: https://hackage.haskell.org/package/aeson-1.1.0.0/docs/Data-Aeson.html https://hackage.haskell.org/package/aeson-1.1.0.0/docs/Data-... The key difference with Aeson is this line: > deriving (Generic, Show) Because of this, it's not necessary in that example to even write the JSON decoder manually. The compiler can generate it on its own. I don't personally know of any way to achieve this in Elm, as Elm doesn't have typeclasses and what's effectively happening here is that an instance of the FromJSON typeclass is being computed by the compiler. A very similar trick is possible in PureScript: http://www.purescript.org/learn/generic/ http://www.purescript.org/learn/generic/
- codygman 10y ago
  Wasn't quite ready to release this, but it seems relevant so see part two here: https://github.com/codygman/concise-json-parsing-in-haskell/blob/master/README.md https://github.com/codygman/concise-json-parsing-in-haskell/... Please give feedback if you don't mind. I'd also like to wait a bit before officially sharing with wider audiences then this comment gets. Keep in mind that part one is "haskell/lens as explicit as possible" which is why I suggested looking at part two to draw conclusions. Edit: just looked at elm decoder pipeline and it looks very similar to aeson.