Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at