Re: New JSON library from the maker of Beast!

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-10-23 03:38:56

On 10/22/19 3:42 PM, Emil Dotchevski via Boost wrote:

> I get your point that it's easier to reason about correctness if you can
> trust the individual components.
Right.
> This reflects a "white box testing"
> mentality. 
I have heard the term - but I never knew what it meant
> But if Spirit is bug-free, logically it does not follow that a
> library that uses it has better chance of being bug-free, compared to a
> library that does not. 

> Either way, you ought to test, ignoring any and all knowledge of its internals.
I don't think anyone has suggested otherwise.  But some approaches 
require much more testing than others.
> 
> Consider also even if using tested components can get you to bug-free
> implementation quicker (which isn't proven in this case), 

Hmmm - it's proven to my satisfaction.  This is the key point.  Using 
spirit to generate parser is a fundamentally different task than 
crafting a sequential procedure to parse arbitrary text to invoke events 
when grammatical elements are recognized.  It's very different than what 
one is used to so it takes more time to learn than one would think.  BUT 
it reduces the job to specifying the grammar and specifying the actions. 
  There is no coding in the sense that writing a hand rolled parser is. 
It's totally static - there is no notion of changing state when 
specifying the parser. So it's inherently verifiable - unlike code which 
changes state as the instruction pointer passes over the code.

This is why I believe that this approach will get one to a bug free 
implementation faster and that one will be able to verify the that the 
implementation is correct.  I realize that not everyone buys this, but 
it's what I believe.

Of course the question is raised about compile time/runtime efficiency. 
The above says nothing about these questions.  But I would like these 
questions to be considered separately from those of correctness.  But in 
many instances - correctness cannot be compromised and compile/run time 
efficiency has to be second priority.

> on balance it is better if you don't depend on another library. 

Also I disagree with this. All things being equal, I'd rather depend on 
someone else's work than my own. I want to focus on only those things 
that are unique to my situation.  And I get no satisfaction from doing 
something that someone else has already done better.

Of course the rub is "all things being equal" which of course is an 
idealization.  Some times it's mostly true while other times it not. We 
get to decide - that's why we make the big bucks.

As time goes on, the problem of C++ code dependencies have become bigger 
issue.  Part of this is that there is a whole generation of programmers 
who don't need to know about linkers and libraries and that header only 
works fine for them.  An header only is more convenient.  But it does 
prejudice code reuse - which has it's own downsides.  I would very much 
like to see C++ make progress toward making better use of linkers, 
separate compilation, better support of control of visibility etc.  But 
we're stuck here.

Robert Ramey