Then Vax was arguably wrong.
Well, uhm. No. That's sort of the point.
Remember your rant about the guy who has to get started right now to keep
his job? He might not be on a DOS box.
You've offered thus far *zero* reasons for which writing the names in caps
can ever be of any benefit to the user, and you've just heard that, in the
real world, it screwed up at least one user.
And why are we discussing out of date
systems, and why is Richard Heathfield quoting Aho/Sethi et al (Dragon
compiler book) 1986? Are we in a time warp?
You're the one obsessing over a 1995 book review.
No they didn't. No intelligent programmer (there are very few)
programs by moronically copying code snippets.
But someone trying to learn from a book is certainly likely to start
by naively (not moronically) copying in example code, assuming that
it'll work.
Nothing really works,
without change, for all platforms, and this isn't Herb's doing:
Again, many writers were able to make C books which did not run into these
problems. He's special.
it's
what vendors do to make money. Even if the code doesn't have to be
changed for a particular target, anyone who expects not to have to
probably change and in consequence doesn't do his homework, deserves
what he gets.
Again, the entire point is that if Herb's book doesn't actually tell people
correctly how to use C, and other books do, then Herb's book sucks. The
more you talk, the more you establish that his book is crap; you're
blaming the victim at a revolutionary pace.
The hypocrisy is particularly stunning. If it's *your* expectation, failure
to comply with the expectation is a horrible thing. But if it's the fairly
reasonable expectation that code examples in a book which claims to cover
"standard C" will run on a variety of systems unless they specifically state
otherwise, then it's because people didn't do their homework...
Yes, it is. Even more valuable would have been an explanation of the
culture divide in computing between case insensitivity in IBM
mainframes and subsequently PCs, and Vaxen and many other systems
which were case-sensitive.
While that might make a great sidebar, the fact is that using names
that aren't in the canonical forms, and never mentioning that they won't
work, is indubitably worse than just using names in the correct forms.
It's not Herb's fault that this difference exists. I do feel that for
best results, he needed a co-author who was expert on non-Microsoft
systems. But this lack was absolutely no reason for the campaign of
abuse to which he was subjected.
There has been no campaign of abuse. Merely a properly evidenced and
supported claim that, for NO BENEFIT AT ALL, he did something in a way
that screws many readers, but does not improve the experience of any
readers. And we keep finding more and more of these examples.
The shit is in the design of C.
Even if that's so, if the book can't describe it accurately, it's a pretty
shitty reference.
The world is full of things which have design flaws or historical quirks.
Good references correctly describe the thing they claim to be a reference
for. They might criticize it, too, but the first key step is to describe
it accurately.
Again, even if we grant this (and you've shown no evidence for it), it's
the author's job to describe the language correctly.
akin to the sprintf issue (sprintf
intrinsically unsafe on all platforms).
Actually, it isn't. sprintf can be used unsafely, but... Let's come back
to this.
As I have said, a professional
Might not be reading this book. He hasn't got time to mess around with
stuff that might be right most of the time. But what about hobbyists, who
also like to learn to program sometimes?
doesn't accept the correctness of code in books any more than a
mathematician expects all the statements in an elementary math
textbook to be true in literal terms and given what we now know:
explanations in calculus in particular can be wildly off-base.
I love that when it's an error in the book your venerate, a "professional"
ought to check his work. But when it's sprintf, the "professional"
mysteriously loses all obligation to expend any kind of cognitive effort
whatsoever.
But you'll be glad to know, the sprintf thing was fixed, in fact, in C99.
We now provide snprintf, which is safe.
As a humanist and not an autistic twerp who worships abstractions and
machines because he can't get laid, I think Schildt's peace of mind
and reputation was MORE important than using a language in which it is
(almost by design) insanely difficult to write correct code.
You may well be right, in which case, he shouldn't have written a book
about a language in which he was unable to write correct code. He should
have picked a better language and gone and written about that.
The standards efforts had a chance to rectify this situation and they
failed to owing to vendor greed.
You keep saying this, but keep not supporting it.
Actually, they are. Seeback lists only twenty mistakes and says in "C:
The Complete Nonsense" that these are the known errors.
Bullshit.
The following is a partial list of the errors I am aware of, sorted by
page number. I am not including everything; just many of them.
I am missing several hundred errors. Please write me if you think you
know of any I'm missing. Please also write if you believe one of these
corrections is inadequate or wrong; I'd love to see it.
The page unambiguously states that it is a partial list, and has done so for
over ten years.
I today teach classes in *critical* reading of texts such as Joseph
Conrad. You don't understand until you've found aporias and errors in
a text so arguably Schildt does his readers an unintentional service
with his errors, which as I have said, are fewer in number than
claimed.
This is so awesome. If/when I redo the page, I am going to have to do a
ton of sidebars for your various awesome quotes.
Furthermore, I see where you don't have the balls to post a fix to the
strcat.
.... Uh. There are at least a dozen fixes, all utterly trivial.
Maybe we should leave fixing the errors to a first-year CS student or
something.
The point is that C IS A JOKE especially in string handling.
It certainly isn't a string processing language, but it's actually pretty
easy to get right.
As soon
as any competent programmer starts using C (whether Bjarne Stroustrup
in the 1970s or I in the early 1990s) he is appalled by it and starts
using its macro and function facility to craft his own C.
Interesting assertion, but not especially supported.
Stop blaming, and scapegoating, Schildt for your own poor taste in
programming languages.
It sure is a shame that, in the 80s and 90s, marauding gangs of fanatic
lovers of bad programming language went around holding guns to peoples'
heads and forcing them to write books about substandard languages.
-s