On 10/8/13 1:41 PM, Dicebot wrote:
On Tuesday, 8 October 2013 at 19:52:32 UTC, Brad Roberts wrote:
On 10/8/13 10:00 AM, Dicebot wrote:
proper performance
I apologize for picking out your post, Dicebot, as the illustrative example,
but I see this pop up
in various discussion and I've been meaning to comment on it for a while.
Please stop using words like 'proper', 'real', and other similar terms to
describe a requirement.
It's a horrible specifier and adds no useful detail.
It tends to needlessly setup the convarsation as confrontational or adversarial
and implies that
anyone that disagrees is wrong or not working on a real system. There's lots
of cases where
pushing to the very edge of bleeding isn't actually required.
Thanks,
Brad
What wording would you suggest to use? For me "proper" is pretty much equal to
"meeting requirements
/ expectations as defined by similar projects written in C". It has nothing do with
"real" vs "toy"
projects, just implies that in some domains such expectations are more
restrictive.
Looking at the context you used it in, defining the performance of vibe and requiring that it never
allocate during page processing to get 'proper performance'. Would you agree that at least in this
case and with that definition that it's an over-reach at least? That there's likely to be far more
applications where allocation is perfectly acceptable and quite possibly even required to achieve
the goals of the applications than not? Yes, there are some where the performance or latency
requirements are so high that the allocations have to be avoided to achieve them, but that's more
the exception than the rule? For those applications 'proper performance' allows a far greater
lattitude of implementation choices.
It's applying your, unspecified, requirements as the definition of valid.
The biggest place it irks me isn't actually this type of case but rather when applied to docs or the
language spec.
