Hello,
See here:
www.open-std.org/.../C99RationaleV5.10.pdf
Is it possible that "Jack Sprat", the staunch defender of the C standard as the ultimate reference when writing programs, missed the following statement?
C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler”: the ability to write machine- 35 specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program (§4).
this is precisely what Per Westermark has been saying. Exactly what Erik Malund has been saying. Remember: Jack Sprat claims often that writing a program that complies with the C standard is a GUARANTEE for its correct functioning.
"Too generic will quickly explode into unmaintainable, large and inefficient solutions."
because being unmaintainable, large and inefficient is how you define something to be too generic. so the above sentence is meaningless.
there is always a degree of "optimization" or compromise here. the fact that an approach, when pushed to an extreme, can be unmaintainable, large and inefficient doesn't mean that that approach is unmaintainable, large and inefficient.
it only means that you have made a poor compromise. so in that case, blame the person(s) pushing that approach to be unmaintainable, large and inefficient, not that approach.
"Too generic will quickly explode into unmaintainable, large and inefficient solutions." because being unmaintainable, large and inefficient is how you define something to be too generic. so the above sentence is meaningless.
You just turned the direction on an implication arrow, or upgraded a one-way relation into a two-way equivalence.
A too general solution gets unmaintainable, large and inefficient.
But a unmaintainable code block need not be too general, or even general at all. A large code block need not be too general, or even general at all. A inefficient block need not be too general, or even general at all.
So, in short, your summary that the above sentence is meaningless is based on erroneous logic.
=> does not imply <= or <=>
because being unmaintainable, large and inefficient is how you define something to be too generic
Well well, this is a rather artistic license to define "too generic". Why "unmaintainable" ? Why "inefficient" ? And why "large"?
None of the above _necessarily_ true.
"A too general solution gets unmaintainable, large and inefficient."
I am not sure what a too "general" solution is: I thought we were talking about code being too "generic" (not "general").
if you object to my approach, then what do you mean by "too generic"?