Re: [review][JSON] Some thoughts on recent reviews

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-09-23 15:26:33

On Wed, 23 Sep 2020 at 15:14, Niall Douglas via Boost <boost_at_[hidden]>
wrote:

> On 23/09/2020 13:14, Vinnie Falco wrote:
> > On Wed, Sep 23, 2020 at 4:55 AM Niall Douglas via Boost
> > <boost_at_[hidden]> wrote:
> >> Me personally, if I were designing something like Boost.JSON, I'd
> >> implement it using a generator emitting design. I'd make the supply of
> >> input destructive gather buffer based
> >
> > So you would implement an orange instead of an apple. Note that the
> > C++ ecosystem already has the flavor of orange you are describing, it
> > is called SimdJSON and it is quite performant. As with your approach,
> > it produces a read-only document. Quite different from Boost.JSON.
> > There's nothing wrong with implementing a library that only offers a
> > parser and a read-only DOM, and there are certainly use-cases for it.
> > Personally I would not try to compete with SimdJSON myself but perhaps
> > you can do better than me, especially in the area of "parallel
> > execution utilising superscalar CPU concurrency."
>
> I never said what I'd do is comparable to what you've done. You're
> absolutely right it's an apple vs orange difference.
>
> What I was describing is the sort of design which would get me excited
> because it's novel and opens up all sorts of new opportunities not
> currently well served by existing solutions in the ecosystem.
>
> There was a larger point made though, regarding the tradeoff of optimal
> design vs getting it done. Historically you've favoured getting it done,
> and have not been a warm recipient to suggestions regarding alternative
> designs which would require you throwing most or all of what you've done
> away and starting again. Quite a few people have perceived this about
> you, and no longer bother to comment on anything you're doing or seeking
> advice upon.
>
>
> You asked off list what I meant by "personal retribution". I'd prefer to
> answer that on list. I am referring to you having, in the past, being
> perceived as harassing and persecuting individuals whose technical
> opinion you disagree with across multiple internet forums over multiple
> months, especially if they have ever publicly criticised a technical
> design that you personally believe doesn't deserve that criticism.
>

> That has caused those people, who perceive that about you, to not be
> willing to interact with anything you touch or are involved with,
> because they aren't willing to be followed all over the internet for the
> next few months by you.
>
> Now, personally speaking, I think it's more a case of you being rather
> enthusiastic and passionate in your beliefs and not thinking through
> other people's perception of you applying those beliefs, rather than you
> being malevolent. I have stated that opinion about you on several
> occasions when my opinion was privately sought. But you also need to
> accept that you reap what you sow in how you're perceived to treat
> people, just the same way as I knew I'd permanently make most of the
> technical Boost leadership hate me for life when I decided to go rattle
> their cages here so many years ago.
>
> You may take this reply personally. It was not meant as a personal
> attack. It was meant as a statement of facts to my best understanding,
> because I don't think many people tell you this stuff, and if nobody
> tells you, then there's no progress possible.
>

I think you highlight one of the problems plaguing C++ decision-making in
the present day.

Far too much concern over feelings, ruffled feathers, politics and imagined
thought crimes - and not enough technical discussions backed with facts and
benchmarks.

I have worked with Vinnie for the past 9 months. During that time he has
spoken to me directly concerning design and implementation choices I have
made. Often indicating strong disagreement in the most uncompromising
terms.

However, because I am an adult, able to draw upon my experience and not
immediately exhibiting an emotional reaction in response to being
challenged, I have been quite able to make my view quite firmly known and
understood. Without any fear whatsoever of "personal retribution".

I have not experienced "being followed all over the internet" in any way
whatsoever.

I am also often told by Peter in his deadpan way that, "I am wrong". I
actually find this quite humorous, for me the comedy is in expecting to
hear the reason, which never comes - presumably because he thinks I ought
to be bright enough to see why I am wrong without being told (I am often
not).

I think there have been some very valid observations made about the design
choices of Boost.JSON. I have made some myself, even going so far as to
push code to see if I could do better than the existing implementation. I
think everyone concerned in its development is quite open that the code is
a compromise between "correctness" and performance. In fact while
maintaining Boost.Beast, I have been reminded that even in 2020, sometimes
you have to break a few rules to get things to go fast. I have been an
advocate of "speed is a hardware problem, elegance is a software problem"
all my life - but with imperfect compilers sometimes brute force is
unfortunately the answer.

It seems to me that some of the more scathing criticisms of the library
have been made *without offering an alternate implementation.* This might
be material to the strength of resistance to these observations - I have
personally watched Boost.JSON evolve over the past six (more?) months. The
testing, writing, rewriting and retesting has consumed at least 18
man-months (this term used advisedly and unashamedly) of effort. That's 18
months of people's lives dedicated to producing the best possible tool for
the most common use-case of a JSON library. There has been an almost
messaianic effort made to match and exceed the performance of RapidJSON, so
that no-one can say that the Boost offering is anything other than best in
class where it matters, *at the point of use*.

If people are going to argue that the underlying design choices are wrong,
I think they are morally compelled to offer a demonstration of why -
preferably as a PR. Knowing Vinnie as I do, I am quite convinced that no
matter who submitted the code, if it improved the final result, it would be
*welcomed* and the author given full credit, regardless of any previous
crossed words spoken in the heat of the moment.

I think it's worth reminding everyone that most of us do what we do because
we are passionate about it. It is therefore natural for people to argue
strongly for what they believe to be right for the good of all. I
personally hope that people who are unwilling to contribute for fear of
hurt feelings can find it in themselves to speak up - they may end up
improving a useful library. Maybe even discovering that through their
shared interest in C++ that they can cross boundaries and find interesting
friends in unlikely places.

R

>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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