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