C the complete nonsense

[Seebs]

[spinny]

Just blank the page, Peter, and this matter will disappear and be
forgotten.

I assure you it won't.

I don't think your sort of harrassment should be allowed to succeed.

Oh, it's succeeded.

I have, at last count, 7,869 words of much more carefully researched material
on the current edition of Schildt's books, showing that not only does he still
not understand basic C features and functionality, but that he himself
accepted my criticisms of the previous book -- but didn't understand them
well enough to apply their logical conclusions.

I'm having some folks review it for a bit before I post it.

But I assure you, once I have a much better-written, much more comprehensive,
article explaining just how much Schildt's books suck, I will happily alter
the old one to indicate that it is incomplete and based on an older edition.

I wouldn't want Nilges to think that his pleadings have gone unheard. He
has, in fact, motivated me to action -- it's taken several hours to produce
the new document.

-s

 

[Seebs]

I cannot tell whether this is better termed "Nilgewater" or "Bullschildt".

But it clearly ought to be one or the other.

and when does he undo this particular example of lying to children?

He doesn't.

The trouble with giving wrong examples is they later have to be
unlearned

To be fair, the *example* is correct (if useless). However, the
*description* is incorrect.

And worse, the example appears to illustrate the incorrect description.
You have to realize that he has, without warning, repurposed the name
"end", to understand that the example shows that the description is wrong.

The example, yes, is correct.

some of us have memories. I remember being a child and I remember
being a newbie.

I also remember what it was like to be a newbie, and spend a lot of time
working with newbies to help them understand things.

"we are a grandmother!"
Margaret Hilda Thatcher

Heh.

More importantly, the best he's come up with for showing that my code is
"far less competent" is that he didn't know how switch() works in C and
couldn't comprehend standard idioms. Oh, poor wounded me. My reputation
is in tatters.

I'll take "over a year in production with exactly one failure which was
caused by a user error" over approval by Nilges any day.

-s

 

[Seebs]

Strange. The copy of Seeb's post delivered to me by the news server
I use contained no such characters, and when I saved the code in a
file and added appropriate declarations, etc. (without changing the
above lines), it compiled fine. Could Google's interface be adding
those invisible(?) characters?

So far as I know, yes. It has to use special "non-breaking spaces"
to handle indentation in some cases, because plain spaces don't
indent as expected.

-s

 

[Seebs]

that is more and more looking like its major flaw. If CTCN was updated
it would be *more* devastating.

It is. I'm gonna try very hard not to expand past 10,000 words, though!

Pretty much all the examples commit the following basic errors
- incorrect bracketing of standard headers
- incorrect return value from main()
- non-portable value passed to exit()

I nearly said "insufficient error checking" but I think that needs to
be tackled on a case by case basis

He's better about those in the current version. I haven't found a "stdio.h"
anywhere, only <stdio.h>. I'm unsure about the value of pursuing the
"exit(1)" idiom; it's technically wrong, but at this point I'm inclined to
just admit that this is clearly a Windows programming book. He removed both
the DOS and UNIX interfaces in the 4th edition, so far as I can see. (I
like that in the 3rd edition, he said the Unix-like interface was "expected
to decline in popularity". Whoops, Linux!)

-s

 

[Seebs]

Judging by the faults Richard is finding and, most importantly, Edward
is neither challenging nor refuting, it's beginning to look like an
updated CTCN would be as long as the book it is criticising!

I would guess longer. The error density, when things go wrong, is AMAZING.

-s

 

[Willem]

Seebs wrote:
)> Strange. The copy of Seeb's post delivered to me by the news server
)> I use contained no such characters, and when I saved the code in a
)> file and added appropriate declarations, etc. (without changing the
)> above lines), it compiled fine. Could Google's interface be adding
)> those invisible(?) characters?
)
) So far as I know, yes. It has to use special "non-breaking spaces"
) to handle indentation in some cases, because plain spaces don't
) indent as expected.

What's wrong with <pre> tags ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

Seebs wrote:
)> Strange. The copy of Seeb's post delivered to me by the news server
)> I use contained no such characters, and when I saved the code in a
)> file and added appropriate declarations, etc. (without changing the
)> above lines), it compiled fine. Could Google's interface be adding
)> those invisible(?) characters?

) So far as I know, yes. It has to use special "non-breaking spaces"
) to handle indentation in some cases, because plain spaces don't
) indent as expected.

What's wrong with <pre> tags ?

Who knows? But I don't think they use them.

-s

 

[spinoza1111]

this is standard practice amongst experienced C programmers

[...]

He misses one thing: for macros that expand to multiple statements,
the definition should be surrounded with "do { ... } while (0)".
Failing to do so can cause some problems with "else".  (This is in the
FAQ, but the site appears to be down at the moment.)

That's correct. In fact, I started using that rule just recently. I
got it from Ben Bacarisse. Forgot it since for me it is new.

Perhaps the FAQ site is down because someone's removing the Schildt
canard.

These aren't universal rules; for macros that mess around with the
syntax, it's not always possible to follow them.  Such macros should
usually be avoided, but they can sometimes be useful.

All normal macros are either expressions or statements (where ideally
the latter are compound statements enclosed in curly braces with or
without a null do wrapper).

 

[spinoza1111]

Oh, totally agreed.  However, you simply haven't shown that they were
wrong.  You've shown that one of them relies on a questionable interpretation
of English, which I grant.

There are usually n>1 interpretations of any English text. None of
them necessarily "questionable".

Furthermore, we have show that only six of your errata out of 20 are
correct. We have also shown your claim that "the 'heap' is a DOS term"
to be wrong.

Time for you to call it a day. Blank the page or put wording at the
top saying that your information is controversial and applies to an
old edition. Then remove the Reception section in Wikipedia. Then
send me email certifying you have done so. Wouldn't mind if that email
contained an apology to me, but that is optional. Then it will all be
over and you can return to finding, or missing, compiler bugs as the
case may be.

But the bulk of the complaints are not wrong, and are not things that can
be explained away as simple typos.

No, only 6 were genuine errata.

Furthermore, as demonstrated by the 4th edition:

SCHILDT GRANTS THAT THE CRITICISMS ARE CORRECT.

Extra! Extra! Read all about it!

Give me a break. The 6 out of 20 errata could have been found by any
competent programmer as well as by you, with your sharp (but not
nearly as sharp as Ben's) eye for the failings of the Other (as
opposed to your lack of awareness of your own failings). They probably
were known issues before you wrote your vanity slam.

Look specifically at my criticism of getchar() (page 314 in the 3rd edition).

In the 3rd edition, the described sentence was present in both getchar()
and getc().  (I do not consider the duplication of text between functions to
be a bug; this is a reference, and each entry should be reasonably
self-contained.)

In the 4th edition, the one I complained about was removed, but the identical
sentence in the description of getc() was not.

So we have it from the horse's mouth:  The criticisms were, by and large,
valid, and most of them have been "corrected" by Schildt.  Sadly, he didn't
understand them -- the example code for getchar() is still useless, in the
same way it used to be.

No, only 6 out of 20 were.

Get over it.

 

[spinoza1111]

I would guess longer.  The error density, when things go wrong, is AMAZING.

Richard and Seebach are in desparation mode. Omission of obviously
needed variables in a code example is NOT AN ERROR. As Malcolm has
pointed out, they are examples. You need a few brains to make them
work, and no normal, non-psychotic person makes this big a deal.

 

[Richard Bos]

Seebs wrote:
)> Strange. The copy of Seeb's post delivered to me by the news server
)> I use contained no such characters, and when I saved the code in a
)> file and added appropriate declarations, etc. (without changing the
)> above lines), it compiled fine. Could Google's interface be adding
)> those invisible(?) characters?
)
) So far as I know, yes. It has to use special "non-breaking spaces"
) to handle indentation in some cases, because plain spaces don't
) indent as expected.

What's wrong with <pre> tags ?

They don't work on Usenet.

But then, neither does Google.

Richard

 

[spinoza1111]

It is.  I'm gonna try very hard not to expand past 10,000 words, though!


He's better about those in the current version.  I haven't found a "stdio.h"
anywhere, only <stdio.h>.  I'm unsure about the value of pursuing the
"exit(1)" idiom; it's technically wrong, but at this point I'm inclined to
just admit that this is clearly a Windows programming book.  He removed both
the DOS and UNIX interfaces in the 4th edition, so far as I can see.  (I
like that in the 3rd edition, he said the Unix-like interface was "expected
to decline in popularity".  Whoops, Linux!)

This is the basic problem. You define what it is you want to work with
and you don't play well with others. In fact, my research has
confirmed that you have a problem working with others in general. I
won't go into any detail on this in order to respect your privacy in a
way mine has not been respected by you; suffice it to say I have
examined material in the public view only.

You believe that using Linux makes you special. This is in fact a form
of white racism which has infected computing because the dirty little
secret is that by staying away from Windows you stay away from Windows
users, who are increasingly and in a global sense nonwhite, while
Linux's affiliation with universities codes this in your mind as a
"white" system.

You also demand a "white" privilege of defining the rules of success.
If another person, especially someone affiliated with the "nonwhite"
aspect of Windows, makes a mistake, you infer that he doesn't know his
job by fitting your interpretation to the desired result. Whereas when
you make a silly mistake (unstructured and unnecessary fallthrough in
switch(), off by one in one line of code, not finding %s, etc.) your
theory of your specialness (which I'm afraid to say has a racial
component) means that this must be explained by a fashionable disease,
fashionable that is to say in wealthier and whiter *arondissements*
and school districts, while students with the equivalent attention
disorder in minority districts receive no such privileged diagnosis
and wind up at best in my old classes in Visual Basic at Devry (with
sixty students in the class) or in prison.

The zaniest consequence is that you want Herb to code in a way that
would be far more opaque than mine, which is unfamiliar to you simply
because it's superior to your crap. You want him to refer to what the
Windows C Sharp user, who's learning C in order to maintain some code,
knows as a "long integer" as a "long long integer", which is just
silly. You want him to return values that Windows will toss in the
garbage. You want him to pretend that Windows is Linux, which at best
is an insult to Linux, isn't it?

I suggest you take a deep breath and either blank CTCN or insert a
disclaimer at the top, remove the Reception section in his wikipedia
entry, send me email confirming that this has been done. I am fairly
confident that you are in no wise able to put together an acceptable
or complete new list of errata in any reasonable amount of time, but
if you attempt this, I shall resume my criticism of your dreck in the
fashion I criticised it this week, line by line, sparing you no
applicable humiliation. I suggest you find another hobby, such as
night school in computer science.

 

[spinoza1111]

I cannot tell whether this is better termed "Nilgewater" or "Bullschildt"..

But it clearly ought to be one or the other.


He doesn't.


To be fair, the *example* is correct (if useless).  However, the
*description* is incorrect.

And worse, the example appears to illustrate the incorrect description.
You have to realize that he has, without warning, repurposed the name
"end", to understand that the example shows that the description is wrong..


The example, yes, is correct.


I also remember what it was like to be a newbie, and spend a lot of time
working with newbies to help them understand things.


Heh.

More importantly, the best he's come up with for showing that my code is
"far less competent" is that he didn't know how switch() works in C and
couldn't comprehend standard idioms.  Oh, poor wounded me.  My reputation
is in tatters.

You are lying. I know how case works since I've written compiler code
to parse and generate object code for case statements. Have you? I am
also aware that switch was incredibly poorly designed by the standards
even of 1969, since it failed, three years after Bohm and Jacoponi
proved that three control structures suffice and two years after
Dijkstra published "Go To Considered Harmful" in JACM for August 1968,
to be structured and allowed "fallthrough" although common logic is
better handled by function calls, inline, or preprocessor macros. This
poor design, and your incompetence, causes your queue.c code to
misleadingly seem to handle invalid ack and nak from or in clients,
leading the program reader (who knows like me how you need a break to
avoid fallthrough) to nonetheless waste his time in trying to find out
why you included ack and nak (after two months "work") in the first
place.

Yes, your reputation is in tatters with the people here who matter,
and who know their trade, as opposed to self-serving little corporate
dweebs who post nonsense about computer books, pay their way onto
standards boards, and backstab to get what they want.

It's only going to get worse, Peter. To the dispassionate observer, I
come across in code, in prose, and even in original poetry as the
person here who can write because he knows his trade. Word to the
wise: lawyers tend to like my style. Nuf ced?

I realize I might have what blm would probably consider a
"communications problem" with little creeps like you and in the
corporate playbook I'm supposed to dumb down. Well, I don't have to
and I won't. I'll end my days in a Bangkok whorehouse first.

I'll take "over a year in production with exactly one failure which was
caused by a user error" over approval by Nilges any day.

Hmm, a "failure" caused by a "user error". You know, Dweebach, the
most uncharitable but quite possibly true interpretation of this was
that the "failure" was not an error message on the server and a
graceful termination. No, based on your failure in queue.c to
initialize db_header followed by a nested if statement which assigned
it only if certain preconditions were true, my guess is that this
"failure" was quite spectacular. It is only a pity that it isn't the
old days when there would have been smoke and flames.

Flame and smoke, smoke and flame
Oh how nice, we have the user to blame

And I wouldn't break my arm patting myself on the back. FYI, in my
salad days, when I could abide working with lower middle class dweebs
because I liked programming just enough, I had to produce tens of such
programs including a compiler and microassembler, in one month, and it
didn't uh crash owing to unexpected input from the "user". Learn your
trade: a good program does not "fail" on user error. It does something
graceful to prevent further harm such as returning void, or zero, or
-1, to the OS. If you hadn't wasted half your life on shibboleth and
back-stabbing you'd know this by now.

Besides, if it didn't fail, did it produce the correct "answers"? Or
did it just cheerfully run, leaking memory and using (in something
like the uninitalized db_header in your famous queue.c) uninitialized
data which was Nul most of the time? Wir sagt?

Just blank CTCN, or insert a disclaimer at the top, remove the
Reception section in the wikipedia article and confirm you have done
so, and quit fucking around.

 

[Walter Banks]

snipped personal vendetta rant...

I am fairly
confident that you are in no wise able to put together an acceptable
or complete new list of errata in any reasonable amount of time, but
if you attempt this, I shall resume my criticism of your dreck in the
fashion I criticised it this week, line by line, sparing you no
applicable humiliation.

In search of truth I assume that you acknowledge the
Richard Heathfield's and other posters comments on
the Schildt's books are correct. If not why not.

Have you got the basic disapline to actually seek the
truth?

 

[spinoza1111]

[spinny]

Just blank the page, Peter, and this matter will disappear and be
forgotten.

I assure you it won't.
I don't think your sort of harrassment should be allowed to succeed.

Oh, it's succeeded.

I have, at last count, 7,869 words of much more carefully researched material
on the current edition of Schildt's books, showing that not only does he still
not understand basic C features and functionality, but that he himself
accepted my criticisms of the previous book -- but didn't understand them
well enough to apply their logical conclusions.  

I'm having some folks review it for a bit before I post it.

But I assure you, once I have a much better-written, much more comprehensive,
article explaining just how much Schildt's books suck, I will happily alter
the old one to indicate that it is incomplete and based on an older edition.

I wouldn't want Nilges to think that his pleadings have gone unheard.  He
has, in fact, motivated me to action -- it's taken several hours to produce
the new document.  

(Sigh) If you post a new document:

1. Questions will still remain at wikipedia how you misled them with
the old document for fifteen years, violating their Biographies of
Living Persons policies with maliciously false information that
endangers them, because it appeared to be about the current edition,
which has been in print for a long time. I will be delighted as their
sacred monster to illumine them on the sordid details of your actual
competence and conduct. Since Jimmy Wales, apparently, has seen fit to
post at my wordpress blog, his administrative assistant will probably
forward my emails to him for action, but failing this, I can always go
in on an anonymous IP address and modify the wikipedia article with a
"source of reception" section that will, I assure you, contain just
enough information about your competence and conduct to not be in turn
libel in any way, but will discredit the Schildt canard once and for
all.

2. I will also go through the new document line by line and once
again expose your lack of education in computer science and low
English skills.

Peter: you don't need this. Your employer doesn't need this. It's a
waste of your time and mine. Just blank CTCN or put a disclaimer at
the top, change the wikipedia article, STOP POSTING ABOUT SCHILDT, and
send me email confirming that you have and will do this.

 

[Seebs]

Have you got the basic disapline to actually seek the
truth?

I have no idea whether he does. I do, and I have indeed got an early
draft, which I've forwarded to a few experts in the field for feedback
and analysis.

I really do owe credit to Malcom McLean, for making the very good point that
it is possible to have a bad criticism of a bad book. C:TCN is not a
well-written or well-structured piece. The quotes are too small to give
clear context, the explanations of what's wrong aren't long enough to give
a real understanding of the problems, and so on. Sure, it's fine for an
expert reader, but the expert reader wouldn't need anything but the quotes
from C:TCR to see the problems.

So I'm doing a new one, based in no small part on the "random page game"
people have been playing here, as well as some more detailed analysis. In
this case, I'm taking the time and effort to seriously clean things up,
give real explanations of what's wrong, and so on. (Next thing I need to
do, apart from some more organizational work, is start adding the specific
citations to the standard to illustrate some of the issues, because a
number of them depend on knowledge of the language far beyond what Schildt
or his prospective readers have.)

But as I expected, what comes out in a more careful study is:

1. The book is much worse than I thought it was. I genuinely thought it
was merely careless and badly presented before. I am now convinced, based
on study of not only the text itself, but the way Schildt changed it
between the 3rd and 4th editions, that Schildt genuinely *does not
understand* many of the things he's getting wrong. This isn't just bad
phrasing; he clearly doesn't understand how EOF works in C, for instance.

2. This book is not merely unaccaptable as a reference, it is also a
shoddy tutorial. Time and time again, a single paragraph of decently-written
text would have done wonders for allowing a reader to understand and address
a prospective problem, but Schildt simply ignored the opportunity. Probably,
based on what I've seen, because he did not understand the issue himself.

3. I am obliged to, sort of, grant one point to Nilges. Having studied
the book more, I think I am obliged to retract the claim that it is "clear".
The writing is fairly approachable, but is full of ambiguities, vagueness,
and handwaving. Back in the day, I thought it much better, because I
didn't have the experience to distinguish between "this book clearly describes
X" and "after seeing this book's reference to X, I have a clear understanding
of X". The latter indicates only prior knowledge, not the book's quality.

But I must congratulate Mr. Nilges. After a mere 7 months of frothing,
raving, incoherence, he has managed to persuade me (with some help) that
the deficiencies in C:TCN justify taking the time to update and improve
it. On the down side (for him, anyway), it turns out that the real problem
was that I had vastly understated the scope, depth, and severity of the
flaws in the text. This will be corrected.

-s

 

[Keith Thompson]

But I must congratulate Mr. Nilges. After a mere 7 months of frothing,
raving, incoherence, he has managed to persuade me (with some help) that
the deficiencies in C:TCN justify taking the time to update and improve
it. On the down side (for him, anyway), it turns out that the real problem
was that I had vastly understated the scope, depth, and severity of the
flaws in the text. This will be corrected.

I encourage you to retain the existing version of the web page,
either unchanged or with a small number of clearly marked
annotations. I find it to be of historical interest.

 

[Seebs]

I encourage you to retain the existing version of the web page,
either unchanged or with a small number of clearly marked
annotations. I find it to be of historical interest.

Oh, certainly. I'll keep it with notes on the historical relevance.

Especially given that Schildt seems to have specifically addressed things
covered in that document, while not addressing identical errors on adjacent
pages in his book... That makes it more than just a little interesting.

I'm probably gonna need another day or two of free time to get this properly
written up. People who'd like to review it are invited to contact me. (And
no, Nilges, you don't count; I'm looking for people who are basically lucid
and capable of reading at least one of English or C with reasonable
comprehension.)

-s

 

[Malcolm McLean]

1.  The book is much worse than I thought it was.  I genuinely thought it
was merely careless and badly presented before.  I am now convinced, based
on study of not only the text itself, but the way Schildt changed it
between the 3rd and 4th editions, that Schildt genuinely *does not
understand* many of the things he's getting wrong.  This isn't just bad
phrasing; he clearly doesn't understand how EOF works in C, for instance.

If what you say is right then we've actually discovered something very
interesting. The books sell well, and are into edition 4. So either
there are a lot of deluded people out there, or technical accuracy
really isn't so important in a programming book. Either statement
seems hard to swallow, but one must be correct. I'd go for the second.
I think if the book really wasn't an effective tutorial/reference,
then no amount of slick marketing and readable prose would have made
it successful in the marketplace. So it must be that people find it
useful.

 

[BruceS]

If what you say is right then we've actually discovered something very
interesting. The books sell well, and are into edition 4. So either
there are a lot of deluded people out there, or technical accuracy
really isn't so important in a programming book. Either statement
seems hard to swallow, but one must be correct. I'd go for the second.
I think if the book really wasn't an effective tutorial/reference,
then no amount of slick marketing and readable prose would have made
it successful in the marketplace. So it must be that people find it
useful.

One of the most popular books ever on personal finances is _Rich Dad,
Poor Dad_. A bit of study shows it to be of extremely low quality,
but it remains popular. I vote for option 1.