Article about Herb Schildt accepted at comp.risks

[spinoza1111]

http://catless.ncl.ac.uk/Risks/26.06.html#subj12

This shall shortly also be on the Digest, to where people may respond
to it. However, responses are competently moderated.

 

[Bill Reid]

The risk: Once you write a crap book, there is the risk that it won't
be forgotten even ten years later, because some people won't leave it
alone. Poor Schildt.
According to this "spinoza" guy there are no bad books, but some just
destroy your reputation forever.

Hmmmm, not entirely sure about that...after I downloaded
Microsoft Visual C++ Express I was forced to try to figure
out how it worked by reading the documentation about
Visual Studio on MSDN (it uses the modern documentation
strategy: no help, mostly ESP, and web pages).

Every lesson in the tutorials, HUNDREDS of them,
encouraged you to read HERB SCHILDT's book on C++
if you weren't familiar with the language...how
good is THAT book?

 

[Seebs]

Every lesson in the tutorials, HUNDREDS of them,
encouraged you to read HERB SCHILDT's book on C++
if you weren't familiar with the language...how
good is THAT book?

I've seen nothing to suggest that it's noticably better. MSDN, though,
is full of nonsense. They have a page claiming that parentheses allow
you to control order of evaluation.

-s

 

[spinoza1111]

I've seen nothing to suggest that it's noticably better.  MSDN, though,
is full of nonsense.  They have a page claiming that parentheses allow
you to control order of evaluation.

Which they do IN PRACTICE. Your vandalism ("sequence points") on
behalf of vendors can be safely ignored simply by not allowing
students to use preincrement and postincrement, which were poorly
thought out by Ritchie at a time when the distinction between value
and lValue was not clear.

You have a Fascistic hatred of knowledge and seek to replace it by
unprovable if unrefutable negative claims accompanied by an
adolescent's superior smirk, and your white skin privilege.

All generalizations outside of pure mathematics (which does not embed
computer science, computer science being a social praxis) have
exceptions. It is far, far more important that students learn that
order of evaluation is changed by parentheses than it is to learn the
mess you and your other misfit friends made of C.

 

[spinoza1111]

The risk: Once you write a crap book, there is the risk that it won't
be forgotten even ten years later, because some people won't leave it
alone. Poor Schildt.

"Crap book" is Nazi language. To a civilized person, there is no such
thing. Since truth is always partial outside of pure mathematics, even
a highly flawed book can be useful.

According to this "spinoza" guy there are no bad books, but some just
destroy your reputation forever.

....only with sniggering little assholes trying to show how superior
they are because they use Linux, even though they can't code worth
dick.

 

[Bill Reid]

I've seen nothing to suggest that it's noticably better.  MSDN, though,
is full of nonsense.  They have a page claiming that parentheses allow
you to control order of evaluation.

I liked the one where they completely run out of
steam on a particular very crucial topic, so they
give you the stunning advice: "Just experiment! Try
various tools to see how they work."

Hmmmm, yes, that IS kind of how I program anyway,
I just press the "any" key and see what happens,
but I'd never thought I'd see "documentation"
encouraging that idiotic behavior...

 

[Mark]

Which they do IN PRACTICE. Your vandalism ("sequence points") on
behalf of vendors can be safely ignored simply by not allowing
students to use preincrement and postincrement, which were poorly
thought out by Ritchie at a time when the distinction between value
and lValue was not clear.

This is a somewhat contrived example (and not a great one), but here is
an ugly and contrived bit of C which shows the problem with predicting
order when the programmer doesn't understand sequence points. No
preincrements or postincrements to be seen. In more subtle forms, I
have often had to handle students' confusion on this:

#include <stdio.h>

int main(int argc, char *argv[])
{
int i;

printf("%d\n", (i=1)+((i=2)*10)+((i=3)*100));
printf("%d\n", ((i=1)+((i=2)*10))+((i=3)*100));
printf("%d\n", (i=1)+(((i=2)*10)+((i=3)*100)));

return 0;
}

Now, given the advice that parentheses affects order of evaluation, a
student might expect that the order of evaluation leading to different
results...

Using gcc on Linux gives:

322
322
323

Hmm. Probably not what the student expected, but clearly the
parentheses have done *something*. Let's see what happens using gcc
under Cygwin on Windows:

321
321
321

Okay. At least some of the students might have suspected they'd get
this result. What about Visual Studio?

333
333
333

Sure, we can teach our students good habits and beg them not to use
global variables or design code with side-effects, but they end up
getting into pickles anyway.

Unless there is an understanding of what guarantees some common standard
offers, they could well be in for a shock later on.

At least gcc gives me a hint I'm being careless:

% gcc -std=c99 -Wall -pedantic e.c
e.c: In function ‘main’:
e.c:7: warning: operation on ‘i’ may be undefined
e.c:7: warning: operation on ‘i’ may be undefined
e.c:8: warning: operation on ‘i’ may be undefined
e.c:8: warning: operation on ‘i’ may be undefined
e.c:9: warning: operation on ‘i’ may be undefined
e.c:9: warning: operation on ‘i’ may be undefined

 

[Nachy]

http://catless.ncl.ac.uk/Risks/26.06.html#subj12

This shall shortly also be on the Digest, to where people may respond
to it. However, responses are competently moderated.

.... Proving, once and for all, that there is such a thing as
"overeducation". Also, that an education, college degree, and hanging
with genius mathematicians doth not one an intelligent person make.

 

[John Bode]

"Crap book" is Nazi language.

Dial the hyperbolator down a few notches; you're liable to burn the
damn thing out running it at 11 all the time.

To a civilized person, there is no such
thing. Since truth is always partial outside of pure mathematics, even
a highly flawed book can be useful.

But only as a lesson in how *not* to write a technical reference. It
is definitely *not* useful for its intended purpose; that is, teaching
people how to program in C. Given the mistakes that Seebs has
highlighted, it can be actively detrimental.

There is an agreed-upon definition of how the language is *supposed*
to work; that is the language standard. Most implementations conform
closely to this standard, some moreso than others. There is some slop
around the edges due to limitations in the implementation environment
or mistakes on the part of the implementor, but on the whole a
conforming compiler *should* accept a conforming program and reject a
non-conforming program.

Additionally, several decades of experience by the C programming
community have identified certain practices that result in reliable,
robust code and therefore should be encouraged, as well as practices
that result in unreliable code and therefore should be discouraged.

The problem with C:TCR is that many of Schildt's explanations run
counter to the language definition; he explains the why's
incorrectly. He also encourages practices which have been shown to
produce code that is unsafe or unreliable.

 

[Seebs]

But only as a lesson in how *not* to write a technical reference. It
is definitely *not* useful for its intended purpose; that is, teaching
people how to program in C. Given the mistakes that Seebs has
highlighted, it can be actively detrimental.

Exactly my point. There are many books I don't personally like very much,
but which are perfectly suitable to the task for which they are presented.
Even the "For Dummies" books are sometimes useful for a particular task
or purpose, though they aren't usually my favorites.

The complaint about "C: The Complete Reference" isn't just that it maybe
isn't the book I'd most want. It's that it gets many, many, things wrong,
omits crucial and fundamental bits of the language, and is full of busted
code examples, factually incorrect advice, and worse.

It's not just that it's "too DOS-specific". It's that the entire explanation
of how to use stdio for character input and output is wrong -- even on DOS
systems.

The problem with C:TCR is that many of Schildt's explanations run
counter to the language definition; he explains the why's
incorrectly. He also encourages practices which have been shown to
produce code that is unsafe or unreliable.

Not just the whys, but also the whats. He's not just giving advice which
misleads users about why things are the way they are; he's flatly
contradicting the way they are *EVEN ON DOS OR WINDOWS SYSTEMS*. Nilges
has launched a number of apologetics about this book, but none of them address
the fundamental problem -- Schildt clearly doesn't understand how EOF works
in C.

Maybe C's design here is flawed; certainly, there are persuasive arguments to
be had that it should have been done differently. However, a book on C has
to teach people what will work with C, not what would work with a completely
different language that the author would have preferred.

-s

 

[Peter Nilsson]

I'm assuming pages like...

<http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>

"... The following table summarizes the precedence and
associativity (the order in which the operands are
evaluated)..."

Which they do IN PRACTICE.

In some languages, but not in C, although many naive students
believe they do.

... ("sequence points") ... can be safely ignored

Indeed. Sequence points are not relevant as they relate to the
completion of side effects, not order of evaluation which is
explicitly unspecified in C, both in theory and in practice...

6.5p3 "The grouping of operators and operands is indicated
by the syntax. Except as specified later (for the function-
call (), &&, ||, ?:, and comma operators), the order of
evaluation of subexpressions and the order in which side
effects take place are both unspecified."

 

[Seebs]

I'm assuming pages like...

<http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx>

"... The following table summarizes the precedence and
associativity (the order in which the operands are
evaluated)..."

There was a page that said specifically that you could use ()s to
change the order in which things were evaluated. This is, of course,
not even true of Microsoft's compiler.

In some languages, but not in C, although many naive students
believe they do.

Indeed. We had a discussion on this not that long ago, in which specific
examples were brought forth showing that no such ordering occurred.

Indeed. Sequence points are not relevant as they relate to the
completion of side effects, not order of evaluation which is
explicitly unspecified in C, both in theory and in practice...

Interestingly, Schildt gets this mostly right -- he states it correctly
once in the 3rd edition, then offers an "example" which is completely wrong
and does not work as described. In the 4th edition, he removed the example
without offering a replacement, probably because he couldn't figure out
how to make a working one.

-s

 

[spinoza1111]

Dial the hyperbolator down a few notches; you're liable to burn the
damn thing out running it at 11 all the time.

It's not hyperbolic. People who like Seebach focus on other people's
putative errors while ignoring their own incompetence are just-add-
water Nazis in that under stress they look instinctively for
scapegoats. Fascism is so evil (most people, faced with the choice of
only Fascism or Communism, choose Communism) that its preconditions
must be radically addressed and not ignored...for much the same reason
we must not allow people like Seebach, whose praxis and theory creates
the preconditions for massive errors, to pretend that they give a
flying **** about software reliability...because they do not.
Seebach's own code (including queue.c after two months work) is
riddled with errors. All he cares about is a massive tu quoque which
shows that he has no competition.

But only as a lesson in how *not* to write a technical reference.  It
is definitely *not* useful for its intended purpose; that is, teaching
people how to program in C.  Given the mistakes that Seebs has
highlighted, it can be actively detrimental.

How would you know? Use scientific method, Mr. Science!

"I have a MASTER'S degree. In SCIENCE!"

That is: Seebach uses (poor) deduction from the Standard to conclude
the lemma "Herb is wrong on Ten Thousand Things". He then uses as an
axiom that "if the teacher makes mistakes, the students will not
learn". This axiom is questionable, since in my experience as a
teacher, learning is a mutual enquiry, not the old, and somewhat
discredited model, of "teacher speaks naught but the truth, students
write it down".

Dweebach then deductively concludes that "Herb is a bad teacher".

This happens to contradict Dweebach's claim that "Herb is a clear
writer", deductively, since we know that clarity leads to
understanding, and understanding to justified true belief, which has a
lot to do with education.

But that aside...Dweebach has NEVER presented any empirical evidence
to CONFIRM his deductive reasoning, and this is mediaeval, syllogistic
reasoning!

Dweebach and friends are constantly speaking of the misled "newbie" as
a complete abstraction. Since Dweebach and friends seem to me
precisely the sort of loudmouths who drive people away, this is
likely.

The only empirical evidence is in fact Schildt's sales figures, and
they contradict Dweebach's deductive reasoning!

There is an agreed-upon definition of how the language is *supposed*
to work; that is the language standard.  Most implementations conform
closely to this standard, some moreso than others.  There is some slop
around the edges due to limitations in the implementation environment
or mistakes on the part of the implementor, but on the whole a
conforming compiler *should* accept a conforming program and reject a
non-conforming program.

But then we learn that conformant compilers are in fact impossible in
C, because of aliasing and because the standard left too much
undefined...a mystery.

Additionally, several decades of experience by the C programming
community have identified certain practices that result in reliable,
robust code and therefore should be encouraged, as well as practices
that result in unreliable code and therefore should be discouraged.

The problem with C:TCR is that many of Schildt's explanations run
counter to the language definition; he explains the why's
incorrectly.  He also encourages practices which have been shown to
produce code that is unsafe or unreliable.

The C community is not known, in fact, to have met Dijkstra's
challenge thrown down two years before Dijkstra's death: to not make a
mess of it. Therefore, I do not accept their standing in judging
Schildt.

 

[spinoza1111]

There was a page that said specifically that you could use ()s to
change the order in which things were evaluated.  This is, of course,
not even true of Microsoft's compiler.

You're lying. Here's WHAT YOU SAID:

"This one is just gob-smackingly bad. Schildt has no concept of what
parentheses do. He writes, on page 57:

'Parentheses are operators that increase the precedence of the
operations inside them.'"

Which is what they are. Since you never took a comp sci 101 class,
much less compiler design, you simply seem not to know that the
semantics of a usable language are defined for NON-OPTIMIZED code,
since it is the job of the optimizer to preserve semantics while
changing order of execution as necessary as possible.

Herb is correct. This is what parentheses do. The optimizer is
entitled to change the order of evaluation if the precedence is
preserved, and that remains the same true fact if you switch "order of
evaluation" and "precedence", because that phrase and that word merely
disambiguate the mathematical meaning of the code, and how it is
executed.

 

[Seebs]

Do you mean there is no such page, or do you mean that Microsoft's
compiler allows the control of evaluation order via parentheses?

It's hard to say.

In any event:

http://msdn.microsoft.com/en-us/library/126fe14k(vs.71).aspx

"Operators in the same segment of the table have equal
precedence and are evaluated left to right in an expression
unless explicitly forced by parentheses."

Or

http://msdn.microsoft.com/en-us/library/2bxt6kc4(VS.80).aspx

"Expressions with higher-precedence operators are evaluated
first."

This is, of course, not particularly correct.

Imagine:
#include <stdio.h>
int a(void) { putc('a'); return 1; }
int b(void) { putc('b'); return 2; }
int c(void) { putc('c'); return 3; }
int main(void) {
printf("\n%d\n", a() + b() * c());
return 0;
}

Now, we know with confidence that this will print some ordering of
a, b, and c, then a newline, then 7, then a nother newline.

But we don't know what order a, b, and c will come out in. MSDN claims
that b() and c() have to be evaluated first, because their expression
has a higher-precedence operator, but this is not always the case.
Similarly, the first quote suggests that b() should be evaluated before
c() because it should be "evaluated left to right".

The problem is that MSDN's pages frequently talk about order of evaluation
when they mean grouping of expressions.

[seebs, in C:TCN]

'Parentheses are operators that increase the precedence of the
operations inside them.'"

[spinny]

Herb is correct. This is what parentheses do. The optimizer is
entitled to change the order of evaluation if the precedence is
preserved,

...or even if it isn't. Between consecutive sequence points, the
implementation is entitled to use any order of evaluation in likes.

But really, they haven't changed the precedence of anything. They've
grouped a subexpression.

The key point, of course, is to remember that Schildt's example for this was:

x = *p++ * (*p);
which he "corrects" to:
x = *p * (*p++);

First off, the parentheses are irrelevant in both cases. Secondly, nothing
in here makes any difference; there's no reason to expect one of these to
work better than the other.

So Schildt's discussion of order of evaluation remains nonsense, too.

-s

 

[Keith Thompson]

[seebs, in C:TCN]

[The above is a quotation from Schildt's book.]

[spinny]

...or even if it isn't. Between consecutive sequence points, the
implementation is entitled to use any order of evaluation in likes.

But really, they haven't changed the precedence of anything. They've
grouped a subexpression.

Schildt's description, though it's badly worded, isn't necessarily
entirely wrong. Parentheses do have to do with precedence. Perhaps a
better way to say it is that parentheses themselves have very high
precedence. (Of course the C standard doesn't discuss this in terms of
precedence, but it's not unreasonable to apply the concept.)

For example, in
x + y * z
"*" has higher precedence than "+"; in
(x + y) * z
"()" has higher precedence than either "+" or "*".

The key point, of course, is to remember that Schildt's example for this was:

x = *p++ * (*p);
which he "corrects" to:
x = *p * (*p++);

First off, the parentheses are irrelevant in both cases. Secondly, nothing
in here makes any difference; there's no reason to expect one of these to
work better than the other.

So Schildt's discussion of order of evaluation remains nonsense, too.

Exactly.

 

[John Bode]

It's not hyperbolic. People who like Seebach focus on other people's
putative errors while ignoring their own incompetence are just-add-
water Nazis in that under stress they look instinctively for
scapegoats. Fascism is so evil (most people, faced with the choice of
only Fascism or Communism, choose Communism) that its preconditions
must be radically addressed and not ignored...for much the same reason
we must not allow people like Seebach, whose praxis and theory creates
the preconditions for massive errors, to pretend that they give a
flying **** about software reliability...because they do not.
Seebach's own code (including queue.c after two months work) is
riddled with errors. All he cares about is a massive tu quoque which
shows that he has no competition.

Dude. Get help. Your current therapist is doing you no favors.

 

[Keith Thompson]

Dude. Get help. Your current therapist is doing you no favors.

Dude. People have been trying to communicate rationally with
"spinoza1111" for many years. It never works. Give it up.

 

[Ben Bacarisse]

...or even if it isn't. Between consecutive sequence points, the
implementation is entitled to use any order of evaluation in likes.

This is not wrong but could very easily be misconstrued. The sequence
points don't sit there like immovable objects -- the implementation can
move some of them around (in time) because they are attached to certain
code constructs. They move with these construct if the implementation
reorders their evaluation.

In code where x, y, and z are functions that print their own name and
then (respectively) return 2, 3, 5, the expression:

w = x() + y() * z();

can result in the printing of any one of xyz, xzy, yxz, yzx, zxy, or
zyx, and the programmer exercises no control over which of these is
printed, but w *must* get the value 17.

Your example (as I am sure you know) is littered with sequence points.
We can "see" four but there are others at the return from each function
call and associated with whatever library function does the actual
printing. Most of these can be moved about depending on the order of
evaluation chosen by the implementation.

If order of evaluation matters, we enforce it via sequence
points. That's what they're for.

Sequence points alone can't help (as your own example shows). The order
is controlled but using constructs which the C language defines (or
should define) as ordered: the ordering between consecutive statements
for example; and the special wording given for some operators (comma,
&&, || and ?. That these cases also coincide with sequence points
makes them useful but it is not what makes them ordered.

At the risk of labouring this rather small point, one can imagine both
a C-like language where all sorts of constructs are ordered but with no
sequence points, and one where everything has a sequence point but no
order of evaluation is defined -- even between statements! Neither
language would be useful, of course. The utility of C comes from the
interplay between the limited permission to reorder and the relative
abundance of sequence points which allow you know what must have
happened (and to legally observe these effects).

 

[spinoza1111]

[seebs, in C:TCN]

'Parentheses are operators that increase the precedence of the
operations inside them.'"

[The above is a quotation from Schildt's book.]

[spinny]

Herb is correct. This is what parentheses do. The optimizer is
entitled to change the order of evaluation if the precedence is
preserved,
...or even if it isn't. Between consecutive sequence points, the
implementation is entitled to use any order of evaluation in likes.

But really, they haven't changed the precedence of anything.  They've
grouped a subexpression.

Schildt's description, though it's badly worded, isn't necessarily
entirely wrong.  

Oh thanks mighty C authority

Parentheses do have to do with precedence.  Perhaps a
better way to say it is that parentheses themselves have very high
precedence.  

A remarkably ignorant statement, since in accepted usage in the
computer science community, only operators can have precedence, and
parentheses are not operators.

(Of course the C standard doesn't discuss this in terms of
precedence, but it's not unreasonable to apply the concept.)

For example, in
    x + y * z
"*" has higher precedence than "+"; in
    (x + y) * z
"()" has higher precedence than either "+" or "*".

This makes no sense whatsoever. The parentheses are not evaluated. If
you translate the expression "(x + y) * z" to suffix notation (xy+z*)
they go away.

Operator precedence is in fact defined only for infix expressions in
the ABSENCE of parentheses, and in ordinary math and compsci, the
addition and subtraction operators have higher precedence than the
multiplication and division operators, which was based on praxis in
high school algebra. Therefore, your statement gives evidence that you
flunked high school algebra. WTF do you think you are doing at Nokia?

Exactly.

I'm afraid that while Schildt may have been at times confused by an
artifact which was incompetently designed, your discussion, Mr.
Thompson, exhibits a frightening lack of comprehension of the
scientific basis of your profession.

It is remarkable how foully people who misuse "terminology" are
treated here by people who in Seebach's case, lack, and exhibit lack
of, computer science education, and in your case also eshibit this
lack.

During the later part of my programming career, earlier in this
decade, I noticed that actual programmers and their managers were
forever finding excuses not to program in the USA. This was because
for years, management had dismissed the scientific theory in favor of
snake oil, and it was confirmed by articles in the New York Times:
that most American programmers simply do not code much. They attend
meetings, they read and write "white papers", those famous documents,
carefully purged of critical thought, with a subtly racist name.

They occasionally change a line of code and almost as often get it
wrong. They write shell procedures or vanity C with unnecessarily
unstructured fallthrough.

They spend hours gossiping and backbiting, online and in meatspace,
and on the phone to real estate brokers.

When they are laid off, nothing much happens apart from the stock
price increase because all the work is being done by my former
coworkers in Shenzen, and in India.

Anyone who can say with a straight face that parentheses have
precedence is a clown.

And anyone who mounts a fifteen year campaign of personal destruction
against a harmless computer author is an evil clown.

I see another comp.risks submission: the RISKS of programmer
incompetence. Don't worry, I won't name names, whether of individuals
or companies. But part of my article will be based on what I've seen
here.

However, at this time, I have taken a break to write a Shakespearean
play about the British election, "The Well-Hung Election, or, Brown
Goeth Down to China Town". I am applying what I know about prosody.
People here are welcome to read it at
http://spinoza1111.wordpress.com/20...ive-and-well-if-rather-shady-in-london-today/.
Here's a sample:

Brown: Varlet, scum, Nancy boy, loser,
And whatever other name may not unbecome
My high and palmy state, tho’ it be thus destroy’d
(For even as men remember’d Rome they will bewail
The loss of New Labour and its grand design)
Be thou call’d. Out of my sight! Thou dost infect mine eyes:
You incompetent Piece of Matter Fecal,
You toad-eating scum of the green-mantl’d Pond,
You block, you stone, you worse than senseless thing,
Thou hast stol’n the election and I am no longer King.

Aide Secundus:What, King? Thou weren’t elected
But King thou never wert, or my name is Bert