Re: A note on computing thugs and coding bums

spinoza1111 <spinoza1111@xxxxxxxxx> writes:

Randy Howard, Richard Heathfield, and Willem, either emulate him or
leave.

If you had misrepresented and abused me in the way you have done to
Richard Heathfield, I doubt I would be able to keep my head as he has
done.

Here's my response including a bug fix.

On Jan 11, 1:08 pm, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:
spinoza1111<spinoza1...@xxxxxxxxx> writes:

<snip>

This was a technical post describing my concern, with references, to
code presented as Beautiful which seemed to me Ugly because it didn't
even work for modern strings [...]

Fairer to say that it is "old" code.  Your C# "modern string" version
would not have been possible at the time.  Technology marches on and

The problem here is that the publication date of the book Beautiful
Code was 2007. It is intellectually dishonest to maintain that
something as pragmatic, as applied, as code can be beautiful, at least
without an explicit statement from Kernighan that "I ignore
international characters", a statement he did not make.

The error of this logic has been pointed out already (I think by
Richard Heathfield, in fact). The code is valid for any character set
at all. It does not work for certain encodings, but then neither does
yours. Most C systems have a narrow char, but that is not required.
It would handle international characters if the execution character
set included them and so you are criticising Kernighan for not making
a statement that would be false.

If you had said "I'd prefer the code to use wchar_t" then I could
agree with that, but it is a trivial change make and not a major
criticism.

There are important regex issues the relate to internationalisation
but you have not addressed these in you code.

American computer scientists and their fellow-travelers all over the
world insist on using C to talk about algorithms, and this is a
serious mistake, as exhibited by the ease in which I transliterated
the code and created thereby an out of bounds bug (immediately caught
by the runtime, as it would be in production) for the regex A*.

That is and extraordinary thing to say. You turned the correct, clear,
and simple:

if (regexp[1] == '*')
return matchstar(regexp[0], regexp+2, text);

into this buggy and unclear mess:

int index;
if ((index = regexIndex + 1) < regex.Length && regex[index] == '*')
{
regexIndex += 2;
return matchstar(regex[regexIndex], regex, ref regexIndex, text,
ref textIndex);
}

and you are blaming C for this?

Pike's code is bug-free, it appears (although I have no proof of this,
and haven't seen it run bug-free according to its own charter).

Of course you have no proof, and neither do I, but the code has the
merit of being short, clear, and concise *and *of having had many eyes
on it for many years. Unless you can show a bug, saying that you
"have not seen it run big-free" just sounds petty and somewhat snide.

It is bad teaching practice to teach, as good computer science, in a
notation that requires the student to know and remember (1) value
parameters can be written safely in C and

Eh? If you dislike it from a style point of view, so be it (I don't
like style arguments) but very few languages prevent it as a matter of
course. What language do you suggest from this point of view?

Interesting, both C and C++, *can* enforce this discipline,
but you did not use that assistance (declaring the parameter const).
This seems so odd that I think I have missed your point. If I have,
what is problem of these safely writable parameters? A code snippet
will be need to know what you are talking about.

(2) no sweat if you're off by one, Nul saves you.

In particular, the latter "feature" creates a coding bum who simply
doesn't worry about such errors.

Are you saying that is why you made the indexing error above? Has C
turned you into a "coding bum" (whatever that is)? My experience
(limited, I agree) is that C tends to make for very careful and
precise coders. I find it hard to believe that C has damaged your
coding to such an extent. If I am right about that, the error is a
simple slip-up caused by not thinking though what needs to happen at
this stage in the algorithm -- i.e. a plain old bug·

<snip>
Which means that in the Princeton CS program, the students have had to
acquire as a condition for success a set of tics that they will, as
undergraduates and beyond, confuse with knowledge, making them less
than they could be.

They will believe false propositions such as "runtime bounds checks
are unmanly and inefficient, for sissies and script kiddies and
girls", "don't worry about off by one", and "all my callers will send
me strings using English-language characters properly bound by Nul",
and "if they don't, call Homeland Security".

Has anyone bere, especially the author you originally criticised, ever
stated any of these silly points of view?

In all these long related threads, only two examples have appeared
that suggest a casual attitude to off-by-one errors: your C# code and
the Shildt function posted by RH. I say "suggest" because I am sure
you do care, but you can't have missed the irony.

<snip polemic>

I don't think is was C++.  I don't know the details but it looked like
something else -- I suggested C++/CLI elsethread -- but you probably
know and could tell us.

Visual C++ Express to generate a command line executable.

I meant what language was it. I does not go though a plain C++
compiler.

Yes, it appears I buttfucked

Let's not go there.

the typing-in of the Pike code

<snip>

Thanks for your contribution. I'll discount your smart remarks.

You are welcome. As you can see, I have discounted your polemical
remarks. I can't help being a smart Alec and I don't think you can
help being polemical. Let's continue to ignore the bits we don't like.

At this time, I stand by my original claim: a factor of five doesn't
justify presenting code that doesn't work for real, international
strings,

I am happy to make a simple type change and pay no penalty.

and calling a grepper a regular expression processor. The
"inefficiency" of Java and .Net is an Urban Legend.

--
Ben.
.