Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2016-09-23 16:04:47

On Sep 23, 2016, at 11:50 AM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> 
> 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%20-%20Howard%20Hinnant%20-%20CppCon%202016.pdf
</shameless plug>

Howard