«

Kenny McCormack wrote:
> In article <>,
> Antoninus Twink <> wrote:
> >On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
> >> - any performance problems are more likely to be a consequence of the
> >> solution (i.e. your program isn't written as efficiently as it might
> >> be) than of the translation.
> >
> >You'd know /all/ about that.
> >
> >> In any case, correctness is far more important than speed.
> >
> >False dichotomy. You seem to take the foolish approach that speed
> >doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
> >algorithm is available and in fact simpler and clearer doesn't bother
> >you in the least. Why? Because you've turned "portability" into an
> >obsession, and nothing else matters.
>
> Yes. I think that whatever you may think of Heathfield's ideas and
> posting style, even the most die-hard sycophants will have to admit that
> he really put his foot in it this time.
>
> You simply have to realize that in the real world, customers pay the
> bills *and* customers don't give a darn about "how ya did it". They
> care that it works and works well.

So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".

> ... No real world customer is going to
> prefer a "100% portable"

Who was talking about "portable"? He said "correct". If "portable" is
one of the requirements for a program (as it should be, to varying
degrees, for most programs), then it's relevant to "correctness".
However, he was making a much more general statement. Consider a
program with no portability requirements whatsoever: there is only one
machine anywhere in the entire world that it needs to run on. However,
it is required to calculate a particular value with a specified
accuracy. Richard Heathfield's point was that designing an algorithm
that actually calculates that number to the required accuracy is more
important than one which calculates a number that doesn't, no matter
how fast the algorithm is that calculates the wrong number.

In article <efc414f8-7a8e-4595-874f->,
<> wrote:
....
>So, how does creating incorrect code quickly meet that need? Incorrect
>means "it does not work".
>
>> ... No real world customer is going to
>> prefer a "100% portable"
>
>Who was talking about "portable"? He said "correct". If "portable" is

You're making a ridiculous point. Of course it has to be correct in
terms of producing the right answer (and whatever else is actually
required). That's just man-of-straw.

In this newsgroup, "correct" has a very different and much larger
meaning. If you stick around for awhile, you will see.

(I could write volumes more on this - to get you to see what is meant -
but I don't have that kind of time)

On 24 Aug 2008 at 13:10, wrote:
> Kenny McCormack wrote:
>> ... No real world customer is going to prefer a "100% portable"
>
> Who was talking about "portable"? He said "correct".

I believe Kenny was referencing my post, where I pointed out that
Heathfield has turned portability into such an idol that for him speed
(and even correctness) play second-fiddle to this golden calf.

On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
> For example, the claim that I don't care about speed is patently
> foolish, and it would seem likely that the basis (such as it is) for
> that claim is based on a single program in which I missed a single
> optimisation that would have taken longer to implement and test than
> it could have conceivably saved in a million years of running the
> program.

It's based on your posting history observed over many years.

Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?

Antoninus Twink wrote:

> On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
>> For example, the claim that I don't care about speed is patently
>> foolish, and it would seem likely that the basis (such as it is) for
>> that claim is based on a single program in which I missed a single
>> optimisation that would have taken longer to implement and test than
>> it could have conceivably saved in a million years of running the
>> program.
>
> It's based on your posting history observed over many years.
>
> Do you deny advising someone to call time() in a busy loop for
> portability, rather than using sleep(3) or whatever other mechanism is
> provided on his platform?

Er, I think I did that, though I wouldn't call it "advising" anyone. It
was merely mentioned (and admitted to) as a poor implementation of
sleep.

writes:
> Keith Thompson wrote:
[...]
>> You're both right. Sometimes speed is simply part of the
>> requirements. (And sometimes it isn't.)
>>
>> *Sometimes* getting the right answers too late isn't much better than
>> getting wrong answers.
>
> Can you give any example of a situation where it's BETTER to get a
> wrong answer early than to get the right answer late? By wrong, I
> don't mean an inaccurate answer that is acceptably close to the true
> value; I mean an answer which is unacceptably far away from the true
> value.

Perhaps under some bizarre circumstances. But my point was just that
in *some* circumstances, late answers are no better than wrong
answers, not that wrong answers are acceptable.

(You wrote "unacceptably far away"; it's difficult to argue that that
would be acceptable.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <>,
Antoninus Twink <> wrote:
>On 24 Aug 2008 at 13:10, wrote:
>> Kenny McCormack wrote:
>>> ... No real world customer is going to prefer a "100% portable"
>>
>> Who was talking about "portable"? He said "correct".
>
>I believe Kenny was referencing my post, where I pointed out that
>Heathfield has turned portability into such an idol that for him speed
>(and even correctness) play second-fiddle to this golden calf.
>

Yes, and also that, in the lingo of this newsgroup, "correct" means
"100% portable". This statement is not argumentation; it is cold, hard
fact.

The problem is that, by redefining most of the standard concepts that
most of us know and use in our lives as programmers, they (the CLC regs)
have painted themselves into a corner. They can no longer use ordinary
terms like "correct" in their ordinary sense, since they have gone to
such lengths to make everything means something else (in the CLC frame
of reference).

I am reminded of how, on the old "What's My Line?" program, they redefined
the term "animal" to mean, essentially, "2 or 4 footed mammals". Which
is obviously limiting, in terms of what we know to really be animals.
Much like the CLC regs have defined "C" to be a tiny subset of what we
know to really be the "C" language.

In article <>,
Antoninus Twink <> wrote:
>On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
>> For example, the claim that I don't care about speed is patently
>> foolish, and it would seem likely that the basis (such as it is) for
>> that claim is based on a single program in which I missed a single
>> optimisation that would have taken longer to implement and test than
>> it could have conceivably saved in a million years of running the
>> program.
>
>It's based on your posting history observed over many years.

Yes. As I've posted in my other response, they've redefined the terms,
so that "correct" doesn't mean what it normally means (to us normal
people).

>Do you deny advising someone to call time() in a busy loop for
>portability, rather than using sleep(3) or whatever other mechanism is
>provided on his platform?

They don't really explicitly "recommend" it - but they describe it in
terms designed to make the newbie think that it is somehow immoral to use
*any* "system specific" functionalities (*). And, of course, you all know
why I put "system specific" in quotes...

(*) And that it is somehow morally superior to do the stupid thing (the
busy loop) rather than taint their mortal soul with "system specific"
functionalities.

(Kenny McCormack) writes:

> In article <>,
> Antoninus Twink <> wrote:
>>On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
>>> - any performance problems are more likely to be a consequence of the
>>> solution (i.e. your program isn't written as efficiently as it might
>>> be) than of the translation.
>>
>>You'd know /all/ about that.
>>
>>> In any case, correctness is far more important than speed.
>>
>>False dichotomy. You seem to take the foolish approach that speed
>>doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
>>algorithm is available and in fact simpler and clearer doesn't bother
>>you in the least. Why? Because you've turned "portability" into an
>>obsession, and nothing else matters.
>
> Yes. I think that whatever you may think of Heathfield's ideas and
> posting style, even the most die-hard sycophants will have to admit that
> he really put his foot in it this time.
>
> You simply have to realize that in the real world, customers pay the
> bills *and* customers don't give a darn about "how ya did it". They
> care that it works and works well. No real world customer is going to
> prefer a "100% portable" solution that is so slow that, for all
> practical purposes, it can be said to simply not work. Nor is any real
> world customer going to answer in anything other than the obvious way
> when asked "So, Mr. Customer who is paying my bills, I can make this
> code run faster - making you look better to your bosses - but at the
> cost of making it not quite so aesthetically pleasing to the denizens of
> this Usenet newsgroup called (amazingly enough) 'comp.lang.c'. Whaddya
> think? Should I do it?"
>
> Mind you, all of the above is spoken as one who really does take pride
> in my work, likes to make my code aesthetically pleasing, and is
> actually somewhat miffed to find that my customers really don't give a
> darn about "how ya did it". But that's reality - a domain in which few
> clc regulars have had to function in, in decades.

Extremely well said.

>
> Maybe AT should re-post his little dialog between CBF and his
> hypothetical customer. Was quite illuminating.
>

--

In article <g8sh8j$mtb$>,
Richard <> wrote:
....
>> Mind you, all of the above is spoken as one who really does take pride
>> in my work, likes to make my code aesthetically pleasing, and is
>> actually somewhat miffed to find that my customers really don't give a
>> darn about "how ya did it". But that's reality - a domain in which few
>> clc regulars have had to function in, in decades.
>
>Extremely well said.

Elvis: Thank you very much!