On Sep 23, 2016, at 11:50 AM, Niall Douglas
As I was saying to David Sankel and Roland Bock yesterday when we were discussing HTTP and BEAST, I really wouldn't care if you stuck O(N^N) complexity loops into your implementation and throw in a pointless sleep(500ms) for good measure in an initial implementation. *I don't care about the quality of the implementation*. I only care, for now, about the solid design of the top level API. Once we have a working implementation of that which has passed Boost peer review, everything else will follow naturally.
Fwiw, I have observed many examples of this purely “top-down” design over the decades. I have even seen some of them result in reasonably functional software. All too often, not even that. The result nearly always works, but often the top-level API dictates an inefficient implementation, and the top-level API gets locked-in by issues such as backwards compatibility and/or resource constraints. These are not hypothetical concerns. When a 2GHz 4-core dedicated computer can’t keep up with my wife’s typing speed, something has gone horribly wrong in many places up and down the software stack. I am not alone in recognizing these shortcomings and many people have gravitated towards a “bottom-up” approach: Build a solid low-level foundation first which emphasizes performance. Higher-level software layers can add functionality. I have personally participated in several low-level projects with this “bottom-up” view: unique_ptr, mutex, condition_variable, thread, and more recently low-level date algorithms: http://howardhinnant.github.io/date_algorithms.html I’ve had considerable success with this approach, but it is not perfect. As I add the higher-level API I sometimes find a missing brick in the foundation. There is nothing like real-world testing of low-level foundation software to find missing or poorly specified functionality, and building that higher-level API upon the lower-level *is* that real-world testing. If that higher-level testing can be done prior to setting the lower-level API in stone, one can achieve a valuable feedback loop where the lower-level level API can be improved while the high-level API is under development. I have also found that a high-performance low-level API usually guides the higher-level design. It encourages the high-level API to not do things that are gratuitously inefficient, as long as the low-level API stands its ground on delegating expensive fancy features to the higher-level. In the end, the very most important thing for software to be is correct. However, the next most important thing is run time performance: http://howardhinnant.github.io/coding_guidelines.html Correctness can be achieved with top-down or bottom-up. But bottom-up combined with early feedback from the top-down lends itself towards a software stack that is both fully functional and high performance. <shameless plug> This is the philosophy I have followed for the software stack discussed in this Cppcon 2016 talk: http://schd.ws/hosted_files/cppcon2016/0f/Welcome%20To%20The%20Time%20Zone%2... Howard