| Rich Townsend 2005-08-21, 6:57 pm |
| William M. Klein wrote:
> In answer to your question,
> "How come I have the fastest timing in the reduce_blanks benchmark,"
>
> There are a few reasons that you (D.F-wit) win the "challenges" that you post
> (in any comp.lang newsgroup ... or combination of newsgroups):
>
> A) You do not know how to (or certainly give no evidence of knowing how to)
> write a programming specification
>
> B) Any time you do try and write a spec (for your challenges) you constantly
> CHANGE the specification as you go along (usually changing the spec to meet your
> program, rather than your program to meet the original spec)
>
> C) You create challenges that are NOT "real-world" application requirements (or
> are not sufficiently useful - as you design them - to solicit careful
> implementation effort)
>
> D) Your "correct" solutions (to your OWN challenges) are rarely the first (or
> second, or ...) one provided. Normally, your "performance" tests are based on
> sample data that allows YOUR solution to "pass" regardless of whether they
> actually meet the original (or recent) specification.
>
> E) Any post (or "challenge") from you solicits minimal response, because you are
> certainly held in "zero" respect by other newsgroups.
>
Nice summary.
> ***
>
> The reason that I am *intentionally* cross-posting this note, is that I (and I
> think several others in the PL/I newsgroup) are actually interested in hearing
> if (as I suspect) D.F. is held in the same "low regard" by the Fortran newsgroup
> as he is by the PL/I newsgroup. As someone who does NOT participate in the
> Fortran newsgroup, I think that this is "useful" information for all concerned.
> (Although his initial "solutions" are usually wrong, it certainly MIGHT be
> possible that his "normal" contributions to comp.lang.fortran are useful. I
> just doubt it.)
My previous responses to DF should make it clear that I share a similar
opinion of him as you. I can't speak for the rest of c.l.f, but I know
I'm not alone in this. DF challenges are no different than pissing
contests, and further ones in which DF can change the rules as he goes
along to cover his own lack of competence.
>
> FYI,
> to meet a "programming" challenge, one need not actually know multiple
> languages. However, to write a programming challenge one must actually know how
> to write a specification that is not worded as:
>
> "In your programming Language A, create a program that does the same thing as
> this code in Language B"
> Neither is it valid to say:
> "Given input-X, create a program that will produce Output-Y"
> (as such specifications, unless the input and output are EXTENSIVE, don't
> really tell what is needed/wanted)
>
> Until (and unless) D.F. actually learns how (and demonstrates the ability) to
> write such a specification, he is (and will continue to be) the only person who
> draws "conclusions" from NEGATIVE "solutions" (better solutions) to his
> challenges. (In general, I think that most programmers are sufficiently well
> aware of the rules of logic, to know what can and cannot accurately be concluded
> from the statements:
> Here is an example of A
> I have looked for (even asked for an example of B)
> I have not SEEN an example of B
>
> i.e. there is NOTHING that one can correctly assume about the existence (or lack
> thereof) of "B".
>
> P.S. Also interested in Fortran answers.
> As someone who is used to "business" applications rather than
> number-crunching or scientific applications, are the types of "specs" that D.F.
> produces actually COMMON among Fortran "analysts" (those who create programming
> specs)? I find this hard to believe, but am more than willing to admit that my
> personal lack of experience in the area may prejudice what I would expect.
Nope, his challenges are designed with only one purpose in mind: so that
he can win them. That he has to move the goalposts so often is testament
to the fact that his ability is wholly eclipsed by that of the others
who -- perhaps in a spirit of humourous masochism -- enjoy participating
in the challenges.
His challenges have no relevance whatsoever to scientific programming,
except as a cautionary example of buggy, ill-tested, poorly-benchmarked,
non-standard and difficult-to-maintain code.
cheers,
Rich
|