C: The Complete Meta-Nonsense

spinoza1111 <> writes:

> This thread shall be the center for compaints about Peter Seebach's
> document "C: The Complete Nonsense", which is as far as I can tell the
> sole source of the false rumors about Herb Schildt's books, a source
> amplified by the confusion of a citation with that of a citation of a
> citation.
>
> I shall start the ball rolling: Peter, what goes around, comes around.
>
> "Page 284
> All of the header files are listed in capitals; the standard specifies
> them in lower case. It is not required that a C compiler reject all-
> caps, but nor is it required that it accept them. "
>
> Herb here relies on the relative prevelance of case insensitivity in
> Windows systems and before them, in IBM systems.

Eh? The first IBM[*] I used was most certainly not case
insensitive. Sure, the shell translated everything to upper case, but
if you could fiddle it in (say through a REXX program) you ended up with
a file that you couldn't delete other than through another program.
[*] CMS, since you ask. Gad I hated it.
--
Online waterways route planner: http://canalplan.org.uk
development version: http://canalplan.eu

Nick

On Nov 4, 10:49*am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 4, 12:38*am, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>
> > On Tue, 3 Nov 2009 08:28:08 -0800 (PST), John Bode
>
> > <jfbode1...@gmail.com> wrote:
> > >On Nov 2, 9:03*pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > >[snip]
>
> > >> Stop blaming, and scapegoating, Schildt for your own poor taste in
> > >> programming languages.
>
> > Umm... isn't this Schildt's taste in programming languages? He wrote
> > several books about C, that indicates some level of interest.
>
> A professional masters a tool without loving it.
>
>
>
> > >WHY DO YOU CARE? *What difference does it make to you what we think of
> > >Schildt's books? *Is he your BFF? *Or are you Herb himself and
> > >unwilling to face criticism directly?
>
> I'm Edward G. Nilges, not Herb Schildt. And it's called solidarity.
> I've seen too many people publish books and work as editors, only to
> get screwed.
>

Would you express solidarity with the author of an electronics
textbook that confused capacitance with inductance? How about an
historian who described David Bowie's last hours at the Alamo?

The errors we're talking about in C:TCR are of similar magnitude.

You seem to think that technical accuracy doesn't matter when writing
a technical reference, or that it's not the author's fault for making
the mistake. Such a position is frankly incomprehensible to me.

John Bode

On Nov 7, 1:03*am, John Bode <jfbode1...@gmail.com> wrote:
> On Nov 4, 10:49*am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Nov 4, 12:38*am, Colonel Harlan Sanders <Har...@kfc.com> wrote:
>
> > > On Tue, 3 Nov 2009 08:28:08 -0800 (PST), John Bode
>
> > > <jfbode1...@gmail.com> wrote:
> > > >On Nov 2, 9:03*pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > >[snip]
>
> > > >> Stop blaming, and scapegoating, Schildt for your own poor taste in
> > > >> programming languages.
>
> > > Umm... isn't this Schildt's taste in programming languages? He wrote
> > > several books about C, that indicates some level of interest.
>
> > A professional masters a tool without loving it.
>
> > > >WHY DO YOU CARE? *What difference does it make to you what we think of
> > > >Schildt's books? *Is he your BFF? *Or are you Herb himself and
> > > >unwilling to face criticism directly?
>
> > I'm Edward G. Nilges, not Herb Schildt. And it's called solidarity.
> > I've seen too many people publish books and work as editors, only to
> > get screwed.
>
> Would you express solidarity with the author of an electronics
> textbook that confused capacitance with inductance? *How about an
> historian who described David Bowie's last hours at the Alamo?

In the case of electronics and history, there is agreement among
tenured faculty members not subject to market forces about these
matters.

Whereas programming folklore such as what main should return (which is
in fact completely dependent on the host) or whether it's even an
error to use upper case in file ids on Microsoft systems that were
case-insensitive with respect to file ids at the time are the
intellectual production of worker bees working at-will at the pleasure
of an employer.

Everything they say must therefore be discounted in some measure,
since there is no independent test of whether they are making their
claim because it is true, or because it advances or defends their
position.

Thus, people trained in C and in unix have seen, as Kenny points out,
the lower marketability of their skills as a threat and will make
pseudo-scientific claims out of fear, including the attempt to destroy
a computer author's reputation based on twenty "errors".

There are people who either are so employable, or else so reconciled
to economic insecurity as a result of speaking truth-to-power, or
both, that we do not discount what they say. But generally speaking,
they do not attack other people's reputations out of fear and anger.

Whitfield Diffie and Bob Gaskins were co-workers of mine at Bell
Northern Research. Both of them worked cheerfully in a dual-vendor
(DEC and IBM) without once seeking to enlarge their status in the zero
sum game of talking behind people's backs about their limitations or
the limitations of the platform on which they specialized. Diffie and
Gaskins invented power point (and are suitably sorry for that
invention ) and Diffie, of course, is a world-famous cryptanalyst.
Neither of them went around shooting off their mouths about other
people's errors. Instead, Diffie in particular had the balls to speak
truth about computer security to power: he testified on his views to
Congress.

In my case, I speak truth to power today because my kids are grown, I
need no longer work in programming, and working with today's noncoding
programmers makes me sick, especially their reversion to the worst
habits of data processing people in the 1960s: the ageism, the sexism,
the racism, and the constant stress on other people's "errors" as a
way of building yourself up by tearing others down.

There is NO learned consensus about C other than a learned hope that
it will just go away some day, because it's just as much an infantile
disorder as Basic was before Visual Basic. If you need to write tight
code, factor that code out and write it in assembler.

Herb made no such errors on the scale of your silly analogies, because
"knowledge" of programming folklore and trivial OS-dependent facts
such as case sensitivity and what main should return is so dependent
on so many preconditions as to be unverifiable and unfalsifiable.
>
> The errors we're talking about in C:TCR are of similar magnitude.
>
> You seem to think that technical accuracy doesn't matter when writing
> a technical reference, or that it's not the author's fault for making
> the mistake. *Such a position is frankly incomprehensible to me.- Hide quoted text -
>
> - Show quoted text -

spinoza1111

On 2009-11-07, spinoza1111 <> wrote:
> In the case of electronics and history, there is agreement among
> tenured faculty members not subject to market forces about these
> matters.

I suspect you'd find comparable agreement among CS teachers not subject
to market forces about most of the stuff you've asserted.

> Whereas programming folklore such as what main should return (which is
> in fact completely dependent on the host)

Well, no, it isn't. Language spec, not host environment.

> or whether it's even an
> error to use upper case in file ids on Microsoft systems

Liar. The assertion was not that it was an error to do something on a
particular system.

> Everything they say must therefore be discounted in some measure,
> since there is no independent test of whether they are making their
> claim because it is true, or because it advances or defends their
> position.

This is beautiful. You have finally realized that you can't argue your
points at all, and the ad hominem (abusive) didn't get you anywhere,
so you've gone straight to the ad hominem (circumstantial).

Why not just argue your points?

> In my case, I speak truth to power today

No, you don't.

Speaking truth to power has a crucial prerequisite; you have to be
willing to genuinely try to understand the thing you are talking about.
You have made it clear that you don't know jack **** about C, and are
"relearning it".

Given that, the entire history of your random attacks on people who
know something about C is absolutely, categorically, not an example
of "speaking truth to power".

Finish relearning C. When you know C well enough to not pepper your
attempts to talk about C with blatant newbie mistakes, then reevaluate
everything; re-read the Schildt books yourself, for instance, and make
your own conclusions about what they say. Browse Usenet archives from
the mid-90s to see what newbies reading Schildt were saying and asking.
THEN tell us what you think about these matters.

Otherwise, you're not speaking truth to power, you're speaking from
your ego alone.

> There is NO learned consensus about C other than a learned hope that
> it will just go away some day, because it's just as much an infantile
> disorder as Basic was before Visual Basic.

Got any support for this kind of thing?

> Herb made no such errors on the scale of your silly analogies, because
> "knowledge" of programming folklore and trivial OS-dependent facts
> such as case sensitivity and what main should return is so dependent
> on so many preconditions as to be unverifiable and unfalsifiable.

Even if we granted this, his direct self-contradictions and his example
of how to use sizeof on function arguments would be egregious enough
errors to justify serious concern...

>> - Show quoted text -

Please learn to use your newsreader. You keep misquoting things or
quoting only parts of them, and also leaving in hundreds of lines of
text you don't respond to. While this doesn't directly impact the
substance of your arguments, it does appear to result in you not reading
things that are substantial and relevant in other peoples' posts.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

On 2009-11-08, Malcolm McLean <> wrote:
> It's not that. Programmers are very literal-minded, because computers are
> literal-minded.

Not always, but often.

However, this has a corollary: It is *useful* to be literal-minded when
dealing with the computer.

> But people don't learn from formal definitions, but from
> explanations.

This is only partially correct. Some people do in fact learn from formal
definitions.

That said, I agree. People mostly learn from explanations -- which is why
it's extremely important that the explanations be right, because a
persuasive-sounding explanation which is wrong will be extremely hard for
the reader to later correct.

> Sometimes it is helpful to skate over details for pedagogical
> purposes,

Agreed. However, Schildt's problems are not "skating over details".

Let me give you an example of "skating over details for pedagogical
purposes". I'm afraid it's from a shell book, 'cuz that's what I had
handy.

If you try to assign a value including spaces to a variable,
you will discover that the shell splits the line into words before
trying to assign variables. Thus, this doesn't work:

$ name = John Smith
sh: Smith: command not found
$ echo hello, $name
hello,

A brief explanation of what went wrong follows in the next section;
a full explanation of what went wrong is found in Chapter 3. For now,
the key lesson is that the assignment doesn't work, and you need a way
to prevent the shell from splitting words.

That's how you "skate over details". The reader is warned that there's
more lurking, but is given a workable first approximation.

> sometimes errors are too trivial to be wort worrying about (in
> books, not in production code).

Less often in books than in production code, because books are aimed at
teaching people how to do things.

> Then almost all code contains some bugs,
> especially code that isn't actually run in real applications.

Agreed.

> It is easy for programmers to convince themselves that a book which is in
> fact very good at what it sets out to do is worthless.

I don't think this is the case. None of your categories cover the
sizeof(rec) example. The error is not trivial at all -- the code will
absolutely not work as described on any system currently in existence.
And, crucially, it's *not* just a bug in the code -- it's a bug in
the explanation given. The explanation, which is the crucial part that
the reader will be learning from, is more wrong than the code.

Similarly, Schildt doesn't "skate over details" -- he gives details which
are incorrect or only correct in some specific contexts, without any hint
at all that he's describing something that may not be universal.

As a book on "How C works on DOS and Windows", it would be a better book,
but would still have enough flaws that it would not be one I could honestly
recommend to anyone. As a book purporting to be a complete reference,
applicable to all platforms, it was crap.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

On Nov 7, 7:37*am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 7, 1:03*am, John Bode <jfbode1...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 4, 10:49*am,spinoza1111<spinoza1...@yahoo.com> wrote:

[snip]

> > > I'm Edward G. Nilges, not Herb Schildt. And it's called solidarity.
> > > I've seen too many people publish books and work as editors, only to
> > > get screwed.
>
> > Would you express solidarity with the author of an electronics
> > textbook that confused capacitance with inductance? *How about an
> > historian who described David Bowie's last hours at the Alamo?
>
> In the case of electronics and history, there is agreement among
> tenured faculty members not subject to market forces about these
> matters.
>

So the answer is "no", then?

[snip remainder of "truth to power" rant]

John Bode

On Nov 9, 1:24*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-08, Malcolm McLean <regniz...@btinternet.com> wrote:
>
> > It's not that. Programmers are very literal-minded, because computers are
> > literal-minded.
>
> Not always, but often.
>
> However, this has a corollary: *It is *useful* to be literal-minded when
> dealing with the computer.
>
> > But people don't learn from formal definitions, but from
> > explanations.
>
> This is only partially correct. *Some people do in fact learn from formal
> definitions.
>
> That said, I agree. *People mostly learn from explanations -- which is why
> it's extremely important that the explanations be right, because a
> persuasive-sounding explanation which is wrong will be extremely hard for
> the reader to later correct.

All very true. However, you're missing something.

We don't let non-teachers tell teachers what or how to teach in
general, and when we do, the results are about half the time pretty
bad.

If Dennis Ritchie or Brian Kernighan had written an anti-Schildt rant
we would take it seriously because both have a combination of
verifiable academic qualifications and industrial experience to rank
them ABOVE Schildt.

Likewise, why do you suppose academic journals "peer review" by
sending submissions to faculty at prestigious universities?

Why do you suppose tenure decisions are not made by university
administrators or state assembly members except in cases of political
interference?

Sure, the instructional content of K-12 teachers is monitored pretty
closely for political and scholastic reasons in the USA, but part of
this monitoring is political.

You are in fact not a real programmer by your own admission, but some
sort of bug finder who may indeed program very good tools for your own
use and the use of your group, and you have no academic certification
in computer science. Whereas Herb was both employed as a programmer
and completed an MSCS.

You have confirmed this when you foolishly mis-represented Michael L.
Scott, the author of Programming Language Pragmatics as writing about C
++ on p. 111 of that book when he was writing about C, and you said on
two occasions that he was also wrong to speak of Forbidden Things,
such as "the" stack...when you haven't shown us how to implement C
runtime without a stack, and when this would involve disproving Noam
Chomsky's typology of languages, and Hopcroft and Ullman's typology of
automata.

Yet you were the source of a rumor campaign which has seriously
damaged Schildt because of the Internet in which (1) it is hard to
determine whether information is credible unless it originates at
a .edu site and (2) the ease of reproduction of a single claim makes n
claims seem quickly to be n times a tens power of actual facts.

Your errata was rejected by technical people at McGraw Hill yet to my
knowledge you have NOT ONCE sought confirmation of your claims by
having them reviewed by a real C programmer with academic
qualifications, writing experience, and knowledge of both Microsoft
and unix-based technology.

As a result you harmed a man's reputation.

It's time to apologize and withdraw "C: the Complete Nonsense".
>
> > Sometimes it is helpful to skate over details for pedagogical
> > purposes,
>
> Agreed. *However, Schildt's problems are not "skating over details".
>
> Let me give you an example of "skating over details for pedagogical
> purposes". *I'm afraid it's from a shell book, 'cuz that's what I had
> handy.
>
> * * * * If you try to assign a value including spaces to a variable,
> * * * * you will discover that the shell splits the line into words before
> * * * * trying to assign variables. *Thus, this doesn't work:
>
> * * * * * * * * $ name = John Smith
> * * * * * * * * sh: Smith: command not found
> * * * * * * * * $ echo hello, $name
> * * * * * * * * hello,
>
> * * * * A brief explanation of what went wrong follows in the next section;
> * * * * a full explanation of what went wrong is found in Chapter 3. *For now,
> * * * * the key lesson is that the assignment doesn't work, and you need a way
> * * * * to prevent the shell from splitting words.
>
> That's how you "skate over details". *The reader is warned that there's
> more lurking, but is given a workable first approximation.

This approach doesn't work in the business world. Of course, the
business world sucks since it's based on systematic inequality.
Nonetheless, programmers confronted with a new language don't want to
hear that "I will explain all this later since right now you swine are
too stupid to get it".

Instead, they want a working model which they can examine.

This working model, as an Aristotelean instantiation of a Platonic
idea, will have any number of aporias. However, REAL programmers
understand that life sucks and only approximates the Platonic for the
same reason that I figured out that Sherman's Programming and Coding
Digital Computers was describing a single-address fixed word length
machine, but that not all machines need conform to this model.

Any given time-slice of a classroom on a video or in a transcript will
consist of stops and starts and half-truths.

An autistic-Platonic teacher, that refuses to speak unless he's
speaking "the truth" is a bore, and a damned fool, because learning
STARTS in stories with partial, at times almost mythological truth.
Haven't you ever taken calculus? Most of Calculus 101 is bullshit from
the standpoint of modern mathematics, and students struggle with the
material.

Their "flash of insight" is often a CRITICAL flash of insight where
they realize that what the teacher said was under some interpretation
WRONG. The real teacher, like Wittgenstein, knows

6.54 My propositions are elucidatory in this way: he who understands
me
finally recognizes them as senseless, when he has climbed out through
them, on them, over them. (He must so to speak throw away the ladder,
after he has climbed up on it.) He must transcend these propositions,
and then he will see the world aright.

"But professor Schildt told us that the stack grows toward the heap
and the heap grows down to the stack! You've got it backwards! Your
code won't work!"

"Don't be an ass. The POINT is that the stack and the heap are of
varying size with no apriori bound, dipshit, whereas the size of the
compiled code is fixed. Therefore, the IMPORTANT point is that the
stack and the heap have to occupy what's left over when my program is
given a fixed amount of memory on startup, a quantum which is not
modified in our OS."

Should "professor" Schildt have said this? Not if it's going to
confuse the class.

You think, autistically, that there's something out there called the
"truth" and it's to be found in data systems. But ultimately, "the
truth" is ethical. It's what contributes to human survival and human
flourishing, not, in the last analysis, to the "correctness" of
computer code, half of which is bullshit computer games, one quarter
of which could be thrown away, and one quarter of which gets people
killed as part of advanced high-tech weaponry used for shits and
giggles in places like Gaza.

>
> > sometimes errors are too trivial to be wort worrying about (in
> > books, not in production code).
>
> Less often in books than in production code, because books are aimed at
> teaching people how to do things.

"Those who can't do, teach" goes the saw. But I'd add that those who
can't teach should not teach the teacher, although teaching (and
jailing, and shooting) teachers is a favorite hobby world-wide of
Fascists, Taliban, and it seems autistic twerps who simply did not
have the chops to criticise Herb, and need to apologize.

>
> > Then almost all code contains some bugs,
> > especially code that isn't actually run in real applications.
>
> Agreed.
>
> > It is easy for programmers to convince themselves that a book which is in
> > fact very good at what it sets out to do is worthless.
>
> I don't think this is the case. *None of your categories cover the
> sizeof(rec) example. *The error is not trivial at all -- the code will
> absolutely not work as described on any system currently in existence.
> And, crucially, it's *not* just a bug in the code -- it's a bug in
> the explanation given. *The explanation, which is the crucial part that
> the reader will be learning from, is more wrong than the code.

Had you focused on the genuine errors, where errors exist in most
large computer books with code examples, your errata would have been
accepted. What was unacceptable for you to speak without recognizable
incompetence of Schildt in general.


>
> Similarly, Schildt doesn't "skate over details" -- he gives details which
> are incorrect or only correct in some specific contexts, without any hint
> at all that he's describing something that may not be universal.
>
You're confusing computer science and programming language training
here.

> As a book on "How C works on DOS and Windows", it would be a better book,
> but would still have enough flaws that it would not be one I could honestly
> recommend to anyone. *As a book purporting to be a complete reference,
> applicable to all platforms, it was crap.
>
> -s
> --
> Copyright 2009, all wrongs reversed. *Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

spinoza1111

On Nov 5, 2:23*am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > No, it's not. I'm not autistic and I don't have a learning disorder,
> > but I don't mock Seebach for being autistic other than calling him an
> > "autistic twerp", of course. You see, an "autistic twerp" is someone
> > who simultaneously tries to get sympathy for his disease
>
> When have I ever done that? *I have pointed out that your derision is
> likely to make people less sympathetic to you, because many people are
> by-default sympathetic to any or all disabilities (note: *"disability"
> or "disorder", but probably not "disease), but I have not stated that I
> want them to do this, or expect it, or anything like that.
>
> > but doesn't
> > take responsibility for the fact that, in Seeb's case, his autism
> > causes him to be mistaken about the knowledge of others,
>
> If this is the case, it has not been shown. *Indeed, you haven't yet
> shown that I am substantively mistaken about the knowledge of others,
> let alone what the causes of such mistakes might be.
>
> > and to make
> > unwarranted generalizations from small data sets.
>
> Unwarranted but provisional, I'd grant -- it's a good way to learn.
>
> > It also causes the
> > autistic to be deficient at organizing material (in his Vicious
> > Tirade) in a sensible way, which caused McGraw Hill to reject it.
>
> Except that, as you've been told several times, that was never submitted
> to McGraw Hill.

You're lying:

"Don't bother contacting the publisher; they apparently don't feel
these errors are significant."
>
> > And it's obscene to turn from trying to get sympathy for having a
> > fashionable disease, and a fashionable sexual orientation, to labeling
> > others mentally ill.
>
> The only reason I mentioned the sexual orientation was that you used the
> word "faggots" to mean "people who understand algorithms better than I do.."
>
> -s
> --
> Copyright 2009, all wrongs reversed. *Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

spinoza1111

On 2009-11-09, spinoza1111 <> wrote:
> All very true. However, you're missing something.

No, I'm not.

> We don't let non-teachers tell teachers what or how to teach in
> general, and when we do, the results are about half the time pretty
> bad.

We do, however, let specialists in a field point out that a particular
teacher doesn't know the field.

> If Dennis Ritchie or Brian Kernighan had written an anti-Schildt rant
> we would take it seriously because both have a combination of
> verifiable academic qualifications and industrial experience to rank
> them ABOVE Schildt.

In other words, you don't care about truth, you care only about status.
Fine.

> You are in fact not a real programmer by your own admission,

You know, your ability to read for comprehension is pretty minimal. I'm
a programmer. The specific case in which I don't do programming but merely
filter things is when I'm passing compiler bug reports on to a vendor...
But note that even CREATING those bug reports is often programming beyond
what most people would ever need to do.

> but some
> sort of bug finder who may indeed program very good tools for your own
> use and the use of your group, and you have no academic certification
> in computer science.

My code is run by all our customers, not just internally.

> Whereas Herb was both employed as a programmer
> and completed an MSCS.

That's nice.

> You have confirmed this when you foolishly mis-represented Michael L.
> Scott, the author of Programming Language Pragmatics as writing about C
> ++ on p. 111 of that book when he was writing about C,

I did not represent him as anything, I merely pointed out that what was
said wasn't true of C, but perhaps it was of another language.

> and you said on
> two occasions that he was also wrong to speak of Forbidden Things,
> such as "the" stack...when you haven't shown us how to implement C
> runtime without a stack,

But I have shown how to implement a C runtime without the thing Schildt
actually describes, which is not "a" stack but "the" stack, and is
specifically asserted to have very specific trait which are not universal.

> Your errata was rejected by technical people at McGraw Hill

This is not true. The document you see was never shown to any technical
people at McGraw hill, or indeed, to anyone at McGraw Hill. They got
a vague letter asserting that there appeared to be errors.

> yet to my
> knowledge you have NOT ONCE sought confirmation of your claims by
> having them reviewed by a real C programmer with academic
> qualifications, writing experience, and knowledge of both Microsoft
> and unix-based technology.

I posted them on the Internet and have welcomed comments and feedback
for fifteen years. In all that time, I've gotten no bug reports which
withstood even casual analysis.

> It's time to apologize and withdraw "C: the Complete Nonsense".

When someone proves to me that the statements therein are false, sure.

> This approach doesn't work in the business world. Of course, the
> business world sucks since it's based on systematic inequality.

So **** the business world. I am not interested in writing something
based on systematic inequality; I am interested in writing something true.

> Nonetheless, programmers confronted with a new language don't want to
> hear that "I will explain all this later since right now you swine are
> too stupid to get it".

Cite.

> Instead, they want a working model which they can examine.

Cite.

> Any given time-slice of a classroom on a video or in a transcript will
> consist of stops and starts and half-truths.

Depends on the teacher.

> "Don't be an ass. The POINT is that the stack and the heap are of
> varying size with no apriori bound, dipshit, whereas the size of the
> compiled code is fixed. Therefore, the IMPORTANT point is that the
> stack and the heap have to occupy what's left over when my program is
> given a fixed amount of memory on startup, a quantum which is not
> modified in our OS."

If that actually happened, you'd have a point. Howeve, Schildt made
it clear that he was specifically talking about the directions and
relationship of their growth.

Consider: Schildt asserts that the stack can run into the heap. Why
can it run into the heap, but not run into the program code? Because
he's describing a specific system's implementation, but claiming it to
be "how things work".

> Had you focused on the genuine errors, where errors exist in most
> large computer books with code examples, your errata would have been
> accepted.

I think I would have had to submit them.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs

On 2009-11-09, spinoza1111 <> wrote:
> On Nov 5, 2:23*am, Seebs <usenet-nos...@seebs.net> wrote:
>> Except that, as you've been told several times, that was never submitted
>> to McGraw Hill.

> You're lying:

No, you're failing to read for comprehension.

> "Don't bother contacting the publisher; they apparently don't feel
> these errors are significant."

Right. I've already told you what happened:
1. I wrote them to say there were errors, and they should fix
them.
2. They offered me a small amount of money to do a technical
review.
3. I declined because I didn't think the money was good enough
to justify the effort.
4. I wrote up enough errors to make the point, posted it, and
forgot about it.

With the benefit of several years' professional writing and editing
experience, I now know that the money wasn't intended to be enough to
justify the effort, and I should have just taken them up on it and
fixed it. At the time, though, I didn't understand that part of the
process, so I made a poor decision.

However.

1. At no point did I submit a list of errata past a couple of things I
could describe as one-liners to anyone.
2. They never rejected my technical claims, they just didn't offer me an
amount of money that, at the time, I thought was reasonable for the amount
of work I'd have had to do to write up a more complete list.

The point might be a lot more relevant if the book I had looked at were
still in print, but it's not, so it hardly matters.

But as a pure matter of fact, it is worth pointing out that the errata were
never submitted to them, and there has never been any technical evaluation
that I know of by McGraw Hill of those claims.

(Interesting that your claimed sources of information about Schildt's feelings
about the matter don't include any coverage of our correspondence, though...
Almost as though you're just making it up and don't actually have any
information.)

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs