[dmitriid]

> making very heavy use of Ajax calls to a JSON-based RESTful API

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

[Albert_Camus]

Author here. As I posted in a different reply:

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.

[dmitriid]

Yeah, it will typecheck it if you're not bored out of your mind writing all the boilerplate and don't introduce subtle bugs https://medium.com/@eeue56/json-decoding-in-elm-is-still-dif...

[maxiepoo]

Can you not do the same thing as JSON.parse() in Elm by parsing into an unstructured JSON type?

[mjaniczek]

Parsing into Json.Encode.Value gives you that Value but no way to work with it except, at later time, using Json.Decode.decodeValue on it. And you're back to specifying decoders...

[maxiepoo]

Seems like you could easily make a library that just parses into some Union type that represents JSON values.

It's likely a design decision to force people that otherwise wouldn't to represent their data in a more structured way.

[amimetic]

In exchange you get incredible validation of your JSON and precise error messages about missing fields etc.

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.

[dmitriid]

Yup. There are a bazillion libraries now trying to pretend to make it look like it's easy to deal with JSON in Elm.

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"

[dmitriid]

For god's sake, Elm is the only language I know that has _an entire book written on how to handle JSON_: https://www.brianthicks.com/post/2017/01/06/announcing-the-j...

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

[Skinney]

And Go has an entire book on how to use the database/sql package. Does that mean the database/sql package is hard? Is React difficult because there is online courses? Is Bootstrap? Of course not.

[enalicho]

It is no different from using a code generator for anything. Json2elm is designed to _help you_ write decoders, not replace decoders. Once you know how to write them, json2elm is mostly useful for generating boilerplate.

[dmitriid]

If you need a code generator to generate boilerplate... something's wrong with your language

[ch4s3]

I suppose you start every new project with mkdir and a few touch commands?

In all seriousness, ever language has boilerplate. In js it might be error handling and state management. In Elm, its decoding json.

[dmitriid]

> I suppose you start every new project with mkdir and a few touch commands?

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

[KirinDave]

So... you don't use yo/yeoman? At all?

[mrkgnao]

The solution isn't more "pragmatism", it's an actual "incredibly powerful type system" like Haskell's. In my projects JSON decoding is just

    instance FromJSON Foo

and that's it.

[Ar-Curunir]

It's the same with `rust` and `serde`; it's a great feeling!

[mrkgnao]

I can imagine :) I think over in Rust-land it's something like

   #[derive(FromJSON)]

isn't it?

[steveklabnik]

  #[derive(Serialize, Deserialize)]

but yeah, same difference.

[mrkgnao]

Ah. That derives both "ToJSON" and "FromJSON", as Aeson calls them. Cool!

[steveklabnik]

Yeah, and it's actually more general than that: it describes how to serialize and deserialize them generally, so you could use, say, serde_json to get json, or serde_yaml to get yaml.

[dmitriid]

Nope. The solution is actually "more pragmatism", not "here's a thing that requires a PhD in type theory to understand".

[mrkgnao]

Type classes are basically interfaces from Java. I'm guessing from your other comments that you know Java (and have read LYAH), so this is actually trolling. The majority of people writing the goddamned Haskell compiler don't have PhDs, they're people using it in industry.

[dmitriid]

"People using something in industry" is rarely an indicator of anything, really.

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

[mrkgnao]

> Haskell is used by Chase Bank.

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?

[dmitriid]

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

Why don't you make a good-faith effort to assume that your opponent has actually done some good-faith efforts?

[Ar-Curunir]

99% of Rust programmers don't have PhDs, I'm sure, and yet they use typeclasses (called traits in Rust) just fine...

[tome]

At this point you just sound like a troll.

[dmitriid]

Nope. It's a genuine feeling.

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 :)

[dragonwriter]

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

Souunds like one of the many strong dynamic languages with optional static typing/typechecking.

[dmitriid]

Yeah. I like approaches taken by OCaml/ReasonML and Typescript. But they are not without their warts :)

[tome]

> Nope. It's a genuine feeling.

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

[dmitriid]

I strongly believe Haskell is very very far from being a "pragmatically typed" language.

This reminds me, I need to write a blog post (which is tangentially about Haskell, but mostly about statically typed languages)