Re: [JSON][review] Design: what is expected of a "JSON library"?

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-09-18 11:46:42

On Fri, 18 Sep 2020 at 11:35, Mathias Gaunard <mathias.gaunard_at_[hidden]>
wrote:

> On Fri, 18 Sep 2020 at 09:18, Richard Hodges via Boost
> <boost_at_[hidden]> wrote:
>
> > JSON is in the main used as a language and platform agnostic data
> > interchange format. The *de-facto* reality is that every other platform
> and
> > language implementation that I can think of limits real numbers to
> doubles
> > and integers to the range +-2^63, so it seems to me that going beyond
> that
> > will achieve little in terms of general utility.
> >
> > This is the situation today.
>
> That is just not true.
> There are many implementations of JSON under the sun, some quite
> low-key and homemade (it's pretty trivial after all), and quite a lot
> do it correctly.
>
> Also many people doing it wrong is not an argument.
>

I think it's fair to say that Boost.JSON's audience might be, as you put so
succinctly, "many people doing it wrong". In other words, the target users
would be people looking for easy interoperation with internet-facing
services and the like, rather than specialist applications.

>
> >
> > I understand the argument that this library could be an opportunity to
> push
> > the boundaries and lead other languages to better practice.
> >
> > On the other hand, this is not the stated intent of the library - it's
> > intent (in summary) is to meet the needs of the majority of C++
> programmers
> > who wish to interoperate with the world wide web today.
> >
> > Along with others here I am sure, I have significant experience in
> dealing
> > with financial and cryptocurrency data interchange using JSON. The
> *reality*
> > is that one learns *not to rely on the various interpretations of number
> > values at all*.
> > If you're sending an important value (such as a price) you very quickly
> > learn to encode it as a JSON string representing the exact value and
> > precision you want.
>
> Well I've been working in high-frequency trading for years, and I have
> the opposite experience.
> Representation of numbers is serious business, be them fixed- or
> float-precision, binary or decimal. If you can't even get that right
> and have to use strings, you're in for a lot of problems.
>

I think in my mind, HFT would come under the heading of "specialist
application", whereas say, distributing tick data to the millions of young
cryptocurrency enthusiasts connected by app, browser, python bot, etc (or
consuming said data) would come under the heading of "general use".

In the general case, representation of real numbers is by no means
standardised and cannot be relied upon. In this case, strings are often
chosen to represent numbers because then the actual precision of the price
of say, BTC/USDT is not in doubt.

I completely understand that this is suboptimal for HFT, but then in
fairness, so is the choice of JSON as an encoding format. For example, for
internal communication I might prefer FlatBuffers or even unadulterated
binary if performance were the major consideration.

Nevertheless, I take your point that there are some applications for which
Boost.JSON would not be suitable. I don't think the authors would argue
with that.

What I do think is that for me, Boost is the go-to repository of
functionality that is missing from the standard library. And with that in
mind, Boost.JSON fills a gaping hole in the Boost suite of libraries in
that it gives its consumers a tool that developers using other languages
have taken for granted for years. In that sense, for me, it would be a
major step forward.

-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]