JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object.
In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.
As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.
It's likely a design decision to force people that otherwise wouldn't to represent their data in a more structured way.
And you don't have to write that bit by hand:
http://eeue56.github.io/json-to-elm/
will generate the decoder for you for straightforward cases and give you a great starting point for more complex cases.
You also get proper ADTs to manage state: not asked/loading/loaded/error something that is tedious and error prone in Javascript.
An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what you’ll get with The JSON Survival Kit, a short ebook on JSON decoding in Elm."
Wut
In all seriousness, ever language has boilerplate. In js it might be error handling and state management. In Elm, its decoding json.
This is not a valid analogy (and no analogy is ever valid).
> In js it might be error handling and state management. In Elm, its decoding json.
Yeah, and Go has trouble with generics.
It doesn't mean it's a feature that has to be vigorously defended. Especially if it's basically the very first thing anyone will have to do in any web application in a language that is meant for client-side web programming
I'm not sure anyone is defending it. At least, I'm not. Basically Elm's compromise is safety, and less runtime complexity then Haskell. The trade off there is boilerplate. As with most things, there is no free lunch. I've stopped using Elm precisely because of these issues, but I understand why Evan made the choices he did.
instance FromJSON Foo
#[derive(FromJSON)]
#[derive(Serialize, Deserialize)]
Industry uses everything and anything. Heck, Javascript is (arguably) world's most popular programming language, used everywhere.
Haskell is used by Chase Bank. J and K are used by banks (J is used by SAP AFAIK). There are stories of Smalltalk running entire factories. There's Active Oberon in a nuclear plant in France. Excel is the world's most widely used FRP environment (unsurpassed, I might add, by anything anyone can offer).
For almost any programming language you name, I will probably find examples of people using it in an industry somewhere, no matter how good, or bad, or obscure, or popular, or well designed, or badly designed a language is.
"You need a PhD in type theory" is a hyperbole which I use to say "to proceed to any advanced level in Haskell you will need to dive quite deep into type theory as it's highly likely you will not even understand how most of the libraries you use work. Most of documentation and material around Haskell is riddled with incomprehensible jargon that often assumes the reader is already versed in any number of obscure Haskell things. Haskell has always been and remains a language designed to specifically test multiple theories of language and types design, and will remain such a language for a foreseeable future, no matter how people try to make it 'more approachable' or 'more pragmatic', and no matter how many people 'use it in the industry'."
Also a ton of other financial services companies: Morgan Stanley, Standard Chartered, and so on. Facebook has, in the recent past, hired a lot of well-known Haskellers. Bunch of hedge fund-ish things do too. Jane Street uses OCaml and does a lot of AdWords targeting at Haskell users :P
I don't know a shred of "type theory" (although I'm interested): you probably mean something else. Monad transformers aren't even categorical abstractions; they evolved from the needs of Haskell users.
> Haskell has always been and remains a language not opposed to testing multiple theories of language and types design
There, fixed that for you. Seriously, why don't you make a good-faith effort to dive into Haskell (as opposed to learning just enough of the jargon to be able to troll with apparent seriousness) before lambasting the things that make it a joy to work with?
Why don't you make a good-faith effort to assume that your opponent has actually done some good-faith efforts?
Basically, in an ideal world we would have a "pragmatically typed" programming language. Basically something in between "weak dynamic typing of Javascript" and "strong static typing of Haskell".
No such language currently exists, and this makes me sad. It's also hard to come up with a proper definition for such a language :)
Souunds like one of the many strong dynamic languages with optional static typing/typechecking.
That's not exclusive with being a troll.
> Basically, in an ideal world we would have a "pragmatically typed" programming language.
Yes, it's called Haskell. Or, if you don't like purity, either OCaml or F#.
This reminds me, I need to write a blog post (which is tangentially about Haskell, but mostly about statically typed languages)
and then
> Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone).
What a great pragmatic language