Re: New JSON library from the maker of Beast!

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-10-22 22:12:56

On 10/22/19 2:49 PM, Emil Dotchevski via Boost wrote:
> You guys are overthinking it. You know how fast this JSON parser is, you
> like the API (or you don't), it works correctly => you use it (or you
> don't). If correctness is critical for you, wait a few months until the
> rate of commits declines. File bugs if you find them. Who cares _how_ it
> works?

With all due respect, this is exactly the wrong way of going about 
making a non-trivial program that one knows is bug free.  It's the 
plague of software development since it's inception.  It has been 
commented on extensively for 40 years.  Dykstra is famous for making the 
most strident case against it, closely followed by Hoare and many, many 
others.  These "theoreticians" have never gotten any respect from "real 
programmers" such as ourselves.  But they are right and we are wrong.

The problem is that they were never really to specify practical methods 
to implement their ideas of provable correctness - except for trivial 
toy like problems.  So here we are with programs of continuously 
increasing complexity and continuously decreasing reliability. What 
you're describing above is what a lot of people call "Agile" development 
- which effectively means pass your bugs on to your users and let them 
suffer the consequences. Then when they complain - tell them it's their 
fault for not sending a bug report.  (Or in the case of C++ - write a 
paper).  In my humble view, we've failed as a profession.  What if this 
approach were applied to thinks like flight computer with 100's of 
passengers on board?  Whoops it has been.

Now this particular case - providing a provable correct parser for a 
simple language - IS a toy problem.  Implementing a parser derived from 
a formal grammar CAN be done quite easily with boost spirit - if only 
for the the testing portion of the project.  (Of course if spirit were 
used in the main product, much less testing would be required!).

both Vinnies method and your method create huge amount of extra work for 
various persons involved in the process.  I'm not over thinking it, 
you're not thinking big enough.  It's not just use cranking up some code 
it's sucking in all the other participants to do our work for us.

Sorry I sort of got off on a tangent.

Robert Ramey