[erlang-questions] New project: ZJ - A tiny JSON encoder/decoder

[zxq9@REDACTED]

On 2018年6月28日木曜日 14時49分49秒 JST Dmitry Belyaev wrote:
> Anyway, what I'd actually greet as a serious improvement in handling of
> JSON in our small Erlang world would be an introduction of "SAX JSON"
> parser (similar to what jsx does) as part of the standard Erlang
> distribution and implemented in C. That way we would have parsing separated
> from construction of the representation, and anyone would be able to use
> whatever representation they like.

We've discussed that more than a few times. The problem is that there is
no "right" mapping because JSON, lacking almost all useful types, is
extremely lossy.

JSX handles objects as proplists in encoding and decoding, but can
decode them as maps if you tell it to.

ZJ handles maps objects to Erlang maps directly, and tuples to lists,
meaning you a proplist encoded to JSON becomes a list of ordered pairs.

Which one is right?

They both are, technically speaking, but one or the other is going to
suit a given project better than the other -- and as a library author
there is no way to know which way will suit project X better ahead of
time.

zj:encode/1 and zj:decode/1 are list-based -- which leaves some ambiguity
but works better in *most* cases. zj:binary_encode/1 and zj:binary_decode/1
is strict about strings being binaries and lists being lists, closer to
the way JSX works.

Which one is right?

That's not possible to know.

Fortunately we live in a world where using JSX or ZJ or Jiffy (if your
platform can build C, anyway) or writing your own isn't hard, so we
get more options this way. I think that's a LOT better situation than
burdening the core distribution team with trying to pick the "right"
way, that falling through and instead having to maintain a zillion
optional arguments for encode and decode, maintaining a portable C
codebase, and dealing with all the complaints that will inevitably
result from there ever having been a default chosen in advance (whatever
defaults are innocently chosen for encode/1 and decode/1 will surely
be wrong in the view of over half the users out there).

I really like that Erlang is a "batteries included" language, but thre
are clear limits. Consider how many projects can't use httpc, the
built-in web parsers, or similar tools. How much other work could be
done were the maintenance burden of those bits removed? Not to mention
backward compatibile maintenance being a tarbaby all its own...

-Craig