[nilkn]

I've been in a pretty similar situation.

I think for many folks Haskell is too big of a gulp all at once. It's not that it's too hard (I think that's a bit of a myth). It's that it's just too different. It's hard for an experienced Java programmer to go from being highly productive to seriously struggling to even solve FizzBuzz in Haskell, let alone dealing with lazy IO and various terms and concepts that don't show up anywhere else like monad transformer stacks.

In my experience, this is where languages like Elm come in and are extremely valuable. This is also why I think Elm is much more important than PureScript. I've recently had a lot of success advocating for and using Elm for an internal tool at work. We've now got several thousand lines of pure Elm code, and for the most part everybody has been incredibly impressed with the overall Elm development experience. I'll also say that the tool ended up being a lot more powerful and feature-rich than originally planned because Elm made it so easy to keep expanding and improving the application.

Java -> Elm -> Haskell/PureScript is a much more enjoyable path for many than Java -> Haskell. It also feels a lot more motivated. Use Elm for a while, and you see many of the strengths of Haskell, but you also see many of the weaknesses of Elm. Once you've seen those weaknesses, you'll be happy to find that Haskell solves most of them. Now you have a concrete reason to look at Haskell, and that can make a big difference.

[ronjouch]

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

[2] http://noredink.github.io/json-to-elm/

[nilkn]

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]

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-...

[codygman]

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/...

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]

Current version: 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/

[eliasbagley]

An even smaller first step is Java -> RxJava, to start thinking in streams of data and transformations of that data.

[weberc2]

This is the case for me. I simply don't have the time to invest in a technology that I keep hearing great things about, but from which I don't see many interesting things being built. I don't mean to knock on Haskell; I'd like to learn it, I just can't justify the time. I'm hoping to get there eventually, perhaps by pursuing Rust more or checking out Reason/OCaml, but I don't have many applications that could benefit from functional languages (at least not functional languages that are markedly slower than the languages I'm building things with today).