The "no gc" crowd
Brad Roberts
braddr at puremagic.com
Tue Oct 8 16:50:24 PDT 2013
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.
More information about the Digitalmars-d
mailing list