Re: subroutine stack and C machine model
- From: Seebs <usenet-nospam@xxxxxxxxx>
- Date: 31 Oct 2009 18:14:12 GMT
On 2009-10-31, spinoza1111 <spinoza1111@xxxxxxxxx> wrote:
The creators of what you call the facts weren't able to get those
facts right.
Doesn't matter. They could have standardized that the language would be
implemented entirely by squealing pigs, and if you then claimed that it
was implemented on digital hardware rather than squealing pigs, it'd show
you to be unqualified to comment on it.
The fact is that what they standardized is clearly documented and known,
and if you can't correctly describe what they did, then it is ridiculous
for anyone to pay attention to your criticisms of what you imagine they
might have done in an alternate reality.
A programmer who has a certain expectation of the way in which his
program should work, which is violated by a bad software system, is to
me more intelligent than the people who created the bad system. He's
what Kant would call "the citizen of a better world".
As long as we're talking merely about expectations, there is certainly
some merit to such a view. But we're not talking about expectations. We're
talking about you claiming that things are true of C, which aren't.
Let's explore this a bit. I ran into a guy once, forgot his name, who was
firmly convinced that C should have standardized order of evaluation, for
instance, of function arguments. I disagreed with him, but I did not think
he was an idiot. That's because he did not claim that it had previously
standardized order of evaluation then ceased to. He did not claim that 9 out
of 10 compilers did it this way, and then turn out not to be able to give
a single actual example of a compiler doing it. In short, he made it clear
that he actually *knew* what C was doing, and that he disagreed with it.
You have consistently gotten the question of what C actually does wrong.
That makes your comments much less credible.
For example, Ted Nelson thought that the Internet should support
double pointers TO information and BACK TO its source. He was mocked
and reviled for this view, but his Xanadu design would show your
vicious little tirade as the source for most if not all anti-Schildt
tirades. Tim Berners-Lee's design makes multiple cites of the same
evidence appear to be more than one piece of evidence.
So, your claim here is that you have a compelling argument as to why there
is no evidence for your claim... Okay, granted. There is no evidence
for your claim. If you ever hear back from people in an alternate reality
where there is evidence for one of your claims, do let us know what that
evidence turned out to be.
Schildt is no Ted Nelson, just a hard-working programmer who's helped
thousands of people in the same way I helped people understand
compilers without having to read Aho et al.
I would be much more sympathetic to this view had I not been obliged to deal
with many of those "thousands of people" here, where it consistently turned
out that they were having a very hard time getting from the DOS box Schildt
described into other environments. Since they consistently turned out to
be having trouble caused by his errors, I concluded that his errors caused
trouble.
You'll note an interesting technique I used in the above: I took real-world
observations as an input, and from them, tried to develop a theory of what
those observations might mean. Your tactic, of declaring a theory and then
asserting that such observations would have existed if only someone else
had designed the Internet, is certainly innovative, but I'm not sure it
works better.
You're quite simply not qualified to speak as to whether the document
in question is good or bad. You don't understand the material to begin
with. You've gotten everything wrong from order of evaluation to
whether or not the operand of ++ needs to be an lvalue (it does, in C,
and always has).
In what sense? It is usable on expressions in some compilers. It
doesn't work, but most compilers don't seem to prevent it. Let's try
it out using Microsoft.
(boop boop)
OK, it's flagged. OK, did you add that rule to C99, or is it in the
standard?
It's been that way since 1978.
My guess would be that you tried this on a C++ compiler at one point,
not aware that C++ changed that rule, and you then came here and blamed
C for getting something wrong that C never got wrong.
Peter, my individual mistakes have nothing to do with the broad issues
I'm addressing
Individually, no, but the *pattern* of mistakes goes straight to credibility.
You're not giving the reader any reason to believe that your opinions are
of value. When you make an assertion such as "order of evaluation should
be defined" or "order of evaluation should be unspecified", you must either
provide compelling evidence (not just assertions that it's obvious to
people who are smart like you), or have credibility to begin with. You
have no credibility, so you'd need to provide evidence.
including the scapegoating of one person for the flaws,
not of that person, but of C.
You mean like the way you keep trying to blame me for stuff I had nothing
to do with?
It is autistic on your part to try to
use errors in detail to make a case at the level I'm discussing.
I originally mentioned the autism thing in the hopes that you would do
no research at all, pick up a couple of vague half-baked stereotypes
of what the word "autism" means, and then try to drag the word into
nearly every paragraph of your future writing as an attack or an insult.
I am pleased to note that you have performed precisely as expected.
Have you considered how this works for your case? Most people feel
uncomfortable with attacks on people who are viewed to be disabled. Many
people have wrestled with some kind of mild mental illness, such as
depression; most people have had friends who have done so. Because autism
is much overrerpresented in the programming industry, the chances are that
many of the readers here have autistic friends or coworkers. And here
you are, using "autistic" as a derogatory epithet. And yet, true to
form, getting the facts wrong anyway.
There are three essential forms of argument; ethos, pathos, and logos.
(Or, for the Frank Zappa fans, five: ethos, pathos, porthos, aramis,
and brut cologne.)
Ethos refers to your character and credibility; the degree to which
people are likely to believe what you say because of whom they
believe you to be. You presumably expect that hammering on the
"autism" point works to undermine my ethos, but you are gravely mistaken.
Most people working in computers these days have come to associate
"autistic" with "precise, careful, and honest, but also rude." But
no one cares whether I'm rude; they care whether I'm right or not.
However, on your end, it undermines your ethos rather severely, because
you're picking on the disabled guy. (That the disabled guy finds
it hilarious may mitigate the effect some, but not very much usually.)
You are coming across as a bully, whether or not you mean to.
For logos (pure reasoning and logic), we find that your arguments
are heavily undermined by the key fact that you don't actually make
arguments, in the form of premises which lead to conclusions. You
just sort of throw random assertions out and then assert your
conclusions. If there are connections, they are too subtle for
anyone to have picked them out yet.
Your best case is the pathos argument -- your appeal to the stories
of the programmers who were laid off by the compiler vendors might
carry weight, except that no one seems to believe them to be true,
probably because C99 was a huge effort and involved substantial new
work by large numbers of people at various vendors.
My errors are correctable; like Winston Churchill, who told Lady Astor
that he was drunk but would be sober in the morning, whereas she would
be ugly, I am relearning C and willingly admitting error in what I
consider an important cause. I shall be right on the morrow, whereas
you will still be a stupid little twerp who thinks that free(NULL) is
a counterexample to the need to balance free() with allocation and
As I pointed out already, it is indeed a counterexample, and my other
objection to that passage was more significant.
that C needs to be semirandom because that allows it to be optimized
(the reverse is true: C is more difficult to optimize than more
deterministic languages).
You've said this before, but you haven't supported it.
Because of your learning disorder, which paradoxically makes you
correct in detail because the need for intelligent interpretation is
beyond you, errors threaten you and when you see others make them you
are horrified by way of psychological transference.
Again, you are mistaken. The root of my complaints was the discovery
that newbies coming to comp.lang.c were getting confused.
Actually, that's something I'd think you'd understand, as an author:
If you need "intelligent interpretation", what you probably actually need
is to go do some editing. Text which is not clear without relying on
the reader to guess at what the author meant instead of what the author
said can make for delightful fiction, but is poor form in technical
writing.
["Oh my they might laugh at me like back in school."]
You really need to do some basic research on autism. Hint: The
predominant characteristic in question would be *not caring* whether
people might laugh at me. If they're laughing, great! That probably
means they're happy.
But, in programming, we know how to deal with errors. And one major
way is a free and open discussion undominated by autistic twerps.
I have rarely dominated a discussion. :)
So stop replying.
But you're *funny*.
Don't you get it? No one cares. Your posts are funny. I show them to
friends and coworkers as jokes, like linking them to a picture of a cat
with a funny caption or one of those youtube videos with the WW2 movie
and hilarious subtitles. ("Hitler's battletech minis" is my favorite,
but relies heavily on domain-specific knowledge; if you want a more
approachable one, I recommend "HITLER FINDS OUT THE SUBTITLES ARE ALL
WRONG".)
I have better things to do and a life.
You've been hammering on this Schildt thing since January of 2008 or so,
haven't you? Why? Who cares? It's a review of a book that's been out
of print for a decade.
How did it affect you? Did you lose a job offer because you said you
liked his books or something? Your level of obsession makes it pretty
clear that this is not merely "SOMEONE IS WRONG ON THE INTERNET", but some
kind of personal effect.
I am spending quite a lot of
time on this issue including relearning C, but I simply do not believe
that some detail about C will convince me that it was not wrong of you
to do what you did.
That may well be. But then, I've seen very little yet to indicate to me
that you draw conclusions from data, rather than manufacturing handwaving
claims that data must exist based on your conclusions.
There are obvious technical reasons, for one thing, that compilers would
have tended to use right-to-left evaluation for function arguments -- which
is probably why the examples that had a consistent pattern that people
have found have usually gone that way.
In the mainframe era, I noted very rapidly how the most rigid and
error-condemning programmers were men so frightened of making errors
that they covered up their own.
That's fascinating. Me, if I find I've broken something, I usually send a
note out to the list for the entire development team warning them of what
it is. (This is because if my stuff breaks, EVERYTHING breaks.)
I have no interest at all in covering up errors. I'm not afraid of making
errors; I just want to make sure that they get caught and corrected.
Any computer book contains both errors and buggy code. The question is
not one of counting errors like a vicious child but whether the book
HELPS PEOPLE LEARN.
Yes. That is EXACTLY the question.
And the answer, for the Schildt books, is that they consistently produced
people who were LESS able to manage C than people who learned from other
books, because the errors were systematic and severe.
Nearly all books in nearly all fields outside formal refereed science
contain errors but as a practical matter, we prefer having many books
to having only refereed books. This is because in the case of
"technical" books, the person reading them is NOT indemnified against
his responsibility to apply the information diligently, testing it
himself.
Right. Which sucks for the newbies, because they don't know HOW to test
it correctly. They don't know that the tests they do on their home computer
at night won't be informative on the servers they have to work on during the
day.
Schildt's audience consists, in some measure, of people who will LOSE
THEIR JOBS if they don't master some enormous program left behind by
some Fat ***. They need to GET STARTED above all. They have NO
CLUE where to do so.
Right! And he gives them... what? Material that they have to "apply
diligently", testing it themselves. Which is to say, material that is in
many cases not merely containing typos, but containing SUBSTANTIVE
ERRORS. Errors which will lead them to make common mistakes.
Schildt shows sizeof() used on an array parameter to a function, and
claims it yields the size of the array. That's not just wrong; it's wrong
in a way which is plausible to a novice user, and will produce badly-broken
code if they trust it. And yet, why shouldn't they trust it? The
craziness of array parameters to functions is, IMHO, a bit of a flaw
in C. (Not one we could correct at this point, or even could have
corrected in 1989, but I think it's a flaw; I think C should have disallowed
declaring parameters as arrays if they weren't going to be actually passed
as arrays.)
Which is to say... If they try to GET STARTED, then... they're gonna be
fucked, because Schildt's books require too much unlearning and relearning.
You'd throw a standards manual at them. This is silly.
You're right, it's silly. What makes you think I'd do it?
Please check out the number of times I've recommended that a newbie coming
to C start with the standard. Hint: It's zero.
I used to mostly recommend K&R to people. I still do, but these days my
first preference is to recommend Kim King's _C Programming: A Modern
Approach_. I was a huge fan of the first edition (I think it was Bob
Nelson who first pointed it out around these parts, but my memory's not
great). I recommended it to people for years. I am biased on the second
edition, because Mr. King did me the honor to ask me to do a tech review
on it. But, biased or not, I think it is a damn fine book. It is clear,
well-written, and very good at avoiding the sorts of overly-specific
explanations of a given platform that Schildt was prone to.
I would recommend that people pick up a copy of the standard, not to learn
the language from, but for reference when trying to understand things where
their book isn't quite as formal as they'd like.
Herb took them by the hand and described the important stuff;
And got some of it importantly wrong.
all of
you creeps praise him for his clarity, which shows you don't know the
meaning of that word, for it means "conducive to understanding and
acquiring JUSTIFIED TRUE BELIEF".
No, it doesn't. First off, it can't, because "clarity" is a noun and you
just gave us an adjecitve phrase. But let's say we fix up the parts of
speech for you.
Clarity:
"clearness or lucidity as to perception or understanding; freedom from
indistinctness or ambiguity."
Clear:
"easily seen; sharply defined: a clear outline."
"easily understood; without ambiguity: clear, concise answers."
"distinct; evident; plain: a clear case of misbehavior."
"entirely comprehensible; completely understood: The ultimate causes of
inflation may never be clear."
Clarity does not imply truth.
The reader will of course have to
try out what he suggests.
But that, it turns out, doesn't work... Because "trying out" on one
platform may not yield the same results as "trying out" on another, so
if the reader is, say, trying to learn C in a hurry, and using a home
computer to study while working on something different, the reader is
gonna get screwed.
Indeed, if he's any good, he will want to do
so.
You just started out by arguing that a big class of readers were newbies
who needed to learn C right away. How would they know to do so?
He will get at times different results because C is basically a
piece of *** crap language which just growed as a result of rush to
market on the part of vendors, with a great deal of ad hoc design (the
contrast between the evaluation of a()||b() and a()+b() being one
example.
As pointed out before: That's not ad-hoc, that's considered.
The logical operators short-circuit because their values can be determined
without evaluating the other side. Same reason that a?b:c evaluates only one
of b or c.
Your use insightful, because I'd concede that a student who learns C
from Schildt could be like the guy who thinks he saw Madonna in
Central Park when (1) he saw a cutout and (2) Madonna was in Central
Park in reality.
I'd say that it'd be more like someone who thinks he saw Madonna in central
park when (1) he saw a cutout of Pamela Anderson and (2) Madonna was in
Boston.
Which is to say, too many errors -- too many cases where the belief the
student forms ends up being incorrect.
But note that this is the educational process in a nutshell!
It could be, done correctly. If Schildt had ever used some kind of
language like "this is an example of how it could be done" on his discussion
of the x86 stack, that would mitigate a lot of the concerns. It wouldn't
handle the pure errors, though.
Would you go into a high school class and call for the teacher to be
fired because he's not proving Dijkstra's et al.'s generalization of
Euclid for oblique triangles?
No.
Your silly and foolish "counterexample"
of free(NULL) shows you would condemn a teacher for not teaching every
detail about the Thirty Years War in a survey class on modern European
history.
No, it doesn't. It shows that I'd condemn a math teacher for claiming that
all prime numbers are odd.
Basically, because of your learning disorder, you hate language and
you are puzzled and enraged by people who can see the forest for the
trees, and you are ready to clear cut the forest for this reason.
Except, of course, that again you Didn't Do The Research -- like many
autistic people, I love language.
And what was your motivation for attacking Schildt?
People kept showing up in comp.lang.c with questions that were rooted in
misunderstandings they'd acquired from reading his books. I felt that it
would be beneficial to warn people that the books were substandard. Since
I did get feedback from Schildt via his publisher, establishing that he was
unwilling to accept a plain factual correction on a fairly straightforward
issue, I concluded that there was not much point in trying to get things
fixed from that side, so I went with Plan B: Make the information about
the quality of the books available to people who might be trying to decide
whether they were good, and encourage them to read other books that I felt
were more likely to be useful.
Surely, flawed
compilers (such as the one Nash was using which messed up his
calculation of a power of 2) do far more damage.
Perhaps they do, but "A is worse than B, we should do nothing about B" is a
stupid argument. I don't have the ability to do very much about flawed
compilers. (Although I have indirectly contributed to fixing a major
usage flaw in gcc, which is to say, I used a service contract with a vendor
to get a fix for it...) I have submitted plenty of bug reports on various
compilers.
I can only conclude
that somehow, he attracted your jealousy.
And again, go do the research. Hint: Jealousy is not a primary
characteristic of autistic social experiences.
Have you submitted book proposals and been shot down,
Oh, definitely, at least once. I learned that the key was to wait for
publishers to approach me.
for the same reason McGraw Hill refused
to incorporate your vicious little tirade as errata...when my son at
13 got errata into Stroustrup?
Well, actually, my "vicious little tirade" was never submitted to McGraw
Hill. I corresponded with them briefly somewhere in the mid 90s, they
offered me money to do a technical review, I did the math, and concluded
the money wouldn't come close to covering my time. (In retrospect, a
poor decision; I was thinking of it in terms of dollars/hour as compared
to minimum wage, which was the wrong model entirely; the point of technical
review is not to earn money at it, but to improve the quality of a book.
I regret that decision now, but at the time I didn't know anything about
how publishing worked.)
You've admitted a learning disorder. You've admitted that the document
was bad. But you are clearly a worthwhile and talented person. You
obviously know C and technology, and independent of this discussion,
you seem to be a fair and open minded moderator of clcm. I suggest you
now should take the step of withdrawing the vicious little tirade and
apologising to Herb.
You do indeed suggest that, but fundamentally, you've done nothing to change
my reasoning. I have not admitted that the document was "bad" in a
substantive way. It was poorly organized.
That bridge is ugly. Structurally sound, sure, working great, no risk of
collapse, but dear god what were we thinking painting it in earth tones.
Solution? Tear it down and apologize for inflicting an ugly bridge on
commuters who now have the option of swimming across the river.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@xxxxxxxxx
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
.
- References:
- Re: subroutine stack and C machine model
- From: Richard Heathfield
- Re: subroutine stack and C machine model
- From: *** T. Winter
- Re: subroutine stack and C machine model
- From: spinoza1111
- Re: subroutine stack and C machine model
- From: Richard Heathfield
- Re: subroutine stack and C machine model
- From: spinoza1111
- Re: subroutine stack and C machine model
- From: Richard Heathfield
- Re: subroutine stack and C machine model
- From: spinoza1111
- Re: subroutine stack and C machine model
- From: Richard Heathfield
- Re: subroutine stack and C machine model
- From: bartc
- Re: subroutine stack and C machine model
- From: Richard
- Re: subroutine stack and C machine model
- From: Seebs
- Re: subroutine stack and C machine model
- From: Richard
- Re: subroutine stack and C machine model
- From: Seebs
- Re: subroutine stack and C machine model
- From: Richard
- Re: subroutine stack and C machine model
- From: Seebs
- Re: subroutine stack and C machine model
- From: spinoza1111
- Re: subroutine stack and C machine model
- From: Seebs
- Re: subroutine stack and C machine model
- From: spinoza1111
- Re: subroutine stack and C machine model
- Prev by Date: Re: subroutine stack and C machine model
- Next by Date: Re: subroutine stack and C machine model
- Previous by thread: Re: subroutine stack and C machine model
- Next by thread: Re: subroutine stack and C machine model
- Index(es):