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

On Fri, 18 Sep 2020 at 11:35, Mathias Gaunard wrote:

On Fri, 18 Sep 2020 at 09:18, Richard Hodges via Boost 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

...

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

push 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@gmail.com office: +442032898513 home: +376841522 mobile: +376380212