> you just cargo cult examples from the documentation

This mindset, and libraries that are basically only usable in that way if you don't want to invest months of your time are the bane of programming. Library writers, please:

1. Design the API by thinking about how it will be used, not how it will be implemented.

2. Make sure that your publicly exposed interface can be specified simply. If your specification is anywhere near as complex as the code implementing it you know you're doing something wrong; your library is not reducing complexity.

The complicated parts of boost where this is what you end up doing are really more like libraries for library writers. You'd almost certainly wrap something like Boost.Geometry for your specific needs. It's made with flexibility as the goal. So it's really not the problem you're presenting. The alternative is dozens of different half-baked libraries for specific use cases.

"Most of the time you just cargo cult examples from the documentation". Yes. This.

That's how any API is used 90% of the time.

Disagree. And, tip: don't say that at a job interview.

Tip: don't be a glib, smug prick on a date.

Please enunciate why something like asio is evil. You review the documentation and examples and the outlined primary use cases "just work". But you can dive in and do really complicated things.

I don't think any of Boost is "evil", and I haven't mentioned asio --- asio came out after I was done using Boost. But I agree with you that a lot of C++ code works because it's part of a cargo-cult culture, not because the interfaces themselves are particularly well- thought- out.