S
spinoza1111
This shows a deep and incurable ignorance, because by this logic, my
first language (machine language) was just fine. I just had to "do the
math".
This shows a deep and incurable ignorance, because by this logic, my
first language (machine language) was just fine. I just had to "do the
math".
S
spinoza1111
How would you know? I have already shown that the proliferation of
"tools" on unix (C++, awk, grep, sh, bsh) is in large part a reaction
to the deficiencies of C. In particular, Stroustrup had learned about
object oriented programming using Simula in Denmark before coming to
the US, because in Denmark labor unions had real power and demanded
that factory automation be documented for union oversight.
You squeal that my assertions are "not especially supported". Then
you're blasted with the documented record, and facts you can verify.
Your feeble and libelous response is to accuse me of mental disorder,
when you yourself has told us you're autistic. Your autism, however,
is used by you to excuse your behavior and to garner sympathy. Pretty
ridiculous when you think it's funny to compare people to mental
patients.
S
spinoza1111
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 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, and to make
unwarranted generalizations from small data sets. 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.
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.
I have no problem with homos at all. I've worked with homos in
technology since 1981. However, I have nothing but contempt for
faggots who become bullies, and deal out the persecution to which they
were subject when they were little faggots. The only pervert I despise
is the pervert who infects another pervert with Aids without telling
him, and it appears to me that Seebach is this type of queer. I don't
know whether he does this, but he does use the Internet to try to
destroy people.
Ben Bacarisse shows us all how to act. Peter Seebach needs to learn
from him.
S
Seebs
If Schildt had mastered C, and then criticized it, he'd be a lot more
respected. Instead, he praised it, then didn't get it right at all.
You do apparently think this.
But:
1. You've made it clear that you, yourself, do not understand C well enough
to comment competently.
2. Even if we ignore that and simply investigate your comments, we
consistently find that you have no clue what you're talking about.
3. You've never actually established that any of the claims made are
substantively false.
4. When confronted with specific, significant, errors in Schildt's texts
which would lead readers who trusted them to grave errors and buggy
code, you make various excuses about how of course the reader is supposed
to put time and effort into guessing when the book is simply wrong.
5. ... even though you elsewhere insist that Schildt's books are of
great importance because they allow people to get quickly up to speed and
use the language effectively.
In short, you make claims which are not only false, but inconsistent, and
have taken to bragging about how little you understand C, and how bad a thing
it would be to understand C.
If we accept your claims of what it would say about someone for that person
to have mastered C, and also your claims that Schildt mastered C, you have
criticized him much more harshly, and in much more personal terms, than any
of his other critics. If we disregard the claims that Schildt mastered
C, we find that you have no basis for complaint about articles which claim
that his knowledge of C is insufficient. If we disregard your claims about
how horrible C is, and how only bad people would be good at it, you're
nothing but an internet kook suitable for drinking games.
And one of their core tactics is to portray that linking up in solidarity
as bullying...
-s
S
Seebs
No, it doesn't.
sprintf() can overrun the ends of a string, which is stored in memory.
printf(), by contrast, writes to a file. No amount of writing to a file
suddenly magically overwrites objects in memory. (Some weird exceptions
exist, involving memory-mapped files, but in general...)
This goes down as one of your more impressively incoherent complaints, and
I consider that category fiercely contested.
Even granting that theoretically printf can spew unbounded output,
there is no problem corresponding to sprintf overruns. Furthermore,
there are multiple ways to keep the output bounded.
There was a genuine, well-understood, way in which sprintf could be risky
if not used with extra caution. snprintf corrects that.
-s
T
Tim Streater
spinoza1111 said:
You're still peddling this lie, I observe.
S
Seebs
Well, one way I'd know would be that you haven't shown any support for
it. You have made a claim about every competent programmer who has ever
used C. You have not shown that this claim is true of more than a tiny
number of people -- or indeed any. Could you cite to a source for the
claim that Stroustrup, in the 1970s, was "appalled" by C?
You've asserted it. To show it, you'd have to make some kind of argument.
This is one of the most astounding non-sequiturs I have ever seen.
Seriously, this is just awesome. "Factory automation must be documented
for union oversight, therefore, people learn about object oriented
programming using Simula."
Except the facts have no connection to anything. You've never shown any
record or facts supporting your various claims about standardization, or
about what "intelligent" programmers ought to expect for order of evaluation,
or any of that. The closest you've gotten thus far to showing support
for a claim with verifiable facts is to assert that labor unions in Denmark
demanded that factory automation be documented. I mean, certainly this
could presumably be verified, but since it has no connection to anything
under discussion, who cares?
-s
S
Seebs
I keep planning to.
No, really, it isn't.
It could be, but for it to be serious, you'd have to actually respond
to any of the dozens of requests that you support your allegations, and
not just with world-class non-sequiturs.
There's been no "debate". A debate is a thing where two parties exchange
arguments. This has been a thing where I alternate between making fun of
you and advancing arguments, and you make random assertions with no
supporting evidence at all.
I assure you, I have genuinely been having fun. Also, I am pretty sure the
record is clear here. The part where I told you I was thinking of making a
drinking game? The clown nose comment? There has been no point since my
initial two or three responses to you weeks ago at which any rational observer
could conclude that I had any motivation in reading or responding to your
posts but having fun.
When you come back with a serious argument to support your claim that the
C standard was motivated primarily by a desire to "protect vendor profits"
by avoiding imposing reasonable requirements on vendors, so they could lay
off their compiler developers, I will take you more seriously. Note that
it has to be an actual argument with evidence and with some kind of logical
connection shown between the evidence and your claims. Appeals to the fact
that you used to work with Nash don't count.
Not that I can detect.
-s
S
Seebs
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.
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.
Unwarranted but provisional, I'd grant -- it's a good way to learn.
Except that, as you've been told several times, that was never submitted
to McGraw Hill.
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
S
Seebs
My guess is he's drawing the wrong inference from the snide remark
about the publisher's lack of concern.
I'd noticed! (He also doesn't seem to read carefully for qualifiers,
I might add.)
-s
N
Nick
spinoza1111 said:
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.
J
John Bode
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.
S
spinoza1111
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.
S
Seebs
I suspect you'd find comparable agreement among CS teachers not subject
to market forces about most of the stuff you've asserted.
Well, no, it isn't. Language spec, not host environment.
Liar. The assertion was not that it was an error to do something on a
particular system.
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?
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 shit 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.
Got any support for this kind of thing?
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...
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
S
Seebs
Not always, but often.
However, this has a corollary: It is *useful* to be literal-minded when
dealing with the computer.
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.
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.
Less often in books than in production code, because books are aimed at
teaching people how to do things.
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
J
John Bode
So the answer is "no", then?
[snip remainder of "truth to power" rant]
S
spinoza1111
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".
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.
"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.
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.
You're confusing computer science and programming language training
here.
S
spinoza1111
You're lying:
"Don't bother contacting the publisher; they apparently don't feel
these errors are significant."
S
Seebs
No, I'm not.
We do, however, let specialists in a field point out that a particular
teacher doesn't know the field.
In other words, you don't care about truth, you care only about status.
Fine.
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.
My code is run by all our customers, not just internally.
That's nice.
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.
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.
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.
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.
When someone proves to me that the statements therein are false, sure.
So **** the business world. I am not interested in writing something
based on systematic inequality; I am interested in writing something true.
Depends on the teacher.
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".
I think I would have had to submit them.
-s
S
Seebs
No, you're failing to read for comprehension.
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