Re:Folly: An open-source C++ library developed and used at F...
by samhw on Saturday January 08, 2022 @09:12PM
(#29859154)
> the opposite from practical is general
No, it's certainly not at all. Those are completely unrelated spectrums. Something can easily be practical and general, or impractical and specific.
> the opposite of efficient can for example be trade off for [...]
And if they stated what trade-offs they made, then that paragraph would actually start to say something useful. Unfortunately, they don't.
Also, if you're developing documentation for libraries, I really would recommend finding a better source of inspiration. Take Redis, in the very first paragraph:
> What this means is that Redis provides access to mutable data structures via a set of commands, which are sent using a server-client model with TCP sockets and a simple protocol. So different processes can query and modify the same data structures in a shared way.
That's all you need to do: before anything else, tell the user what the thing does. Then you can give some basic details about implementation: "written in Go", "runs on Linux & macOS", "uses GC, so not suitable for RT applications", etc. After that you can get into trade-offs, real narrow implementation details, setup, handwaving abstract adjectives, etc. But lead with what the hell it actually does.
No, it's certainly not at all. Those are completely unrelated spectrums. Something can easily be practical and general, or impractical and specific.
> the opposite of efficient can for example be trade off for [...]
And if they stated what trade-offs they made, then that paragraph would actually start to say something useful. Unfortunately, they don't.
Also, if you're developing documentation for libraries, I really would recommend finding a better source of inspiration. Take Redis, in the very first paragraph:
> What this means is that Redis provides access to mutable data structures via a set of commands, which are sent using a server-client model with TCP sockets and a simple protocol. So different processes can query and modify the same data structures in a shared way.
That's all you need to do: before anything else, tell the user what the thing does. Then you can give some basic details about implementation: "written in Go", "runs on Linux & macOS", "uses GC, so not suitable for RT applications", etc. After that you can get into trade-offs, real narrow implementation details, setup, handwaving abstract adjectives, etc. But lead with what the hell it actually does.