Statement on Schildt submitted to wikipedia today
spinoza1111
The vandalism of Schildt continues. I propose that the following text
be added to the discussion of the controversy. I shall also post this
for discussion at comp.lang.c and submit it to comp.lang.c.moderated.
Other commentators, however, have found that Seebach's and Feather's
objections to Schildt's work result from their POV which is that of
self-serving "language lawyers" concerned less with clear explanation
to working programmers and more with being "right all the time, even
when it's undefined" in the words of one wag. For example, Schildt
describes how things work in terms of the most common features of C
runtimes, features that are not part of "the language". This is an
excellent way to help programmers, typically men and women who want a
"shirtsleeves" POV and to understand how things work, only to have
Seebach condemn him, in a spirit with a nasty overtone of religious
fundamentalism (made merely nastier by the secular, sordid and
pecuniary goals of programming language standardization in service to
corporations) for daring to speak of such Eleusinian mysteries as the
"stack"...which looks backwards to an era when programmers in
corporations were admonished or terminated for excess curiosity.
It is widely believed today that C99 as a standardization effort
failed rather miserably. The reason, according to some, is that it was
less concerned with the needs of working programmers, and more
concerned with spending public monies (in the spirit of the Bush-
Clinton years of privatization) on protecting corporate profits, here
making as many compilers as possible "work" by leaving common sense
functionality "undefined", so that compiler developers could be shed
by compiler development and other corporations, and their investment
protected. There was no interest outside Open Source in making
correct, much less excellent, C compilers in 1999, C compilers having
become commodities, and there was no fiduciary reason for companies to
fix compilers to conform to a more precise standard: therefore, the
standard was made as undefined (not a standard, in other words) as
possible in a giveaway to corporations which looked forward to the
monies handed over to banks in 2008.
It appears to many of us that Schildt was a sacrificial lamb, a
representative of an individual knower, and of the type of
knowledgeable programmer who (like Carthage) had to be destroyed, for
his knowledge is now the private property of corporations, to be
preserved or destroyed at will. In all of this, the public interest
was unmentioned, and the public was damned, not only by corporations
but also by people corrupt enough to work, nor for the wretched of the
earth, but for Moloch itself: the corporation.
Seebach and Feather have not only gone after Schildt. They also
continue to savage professional reputations whenever their standard is
questioned. This despite the fact that the standard destroyed the very
ability to teach C save in the most cautious, and fundamentalist way,
such that "professors" today are well advised to be *imams* in
*madrassahs* teaching *taliban*. In a sense this is an insult to Islam
for the *imams* giving *fatwas* are concerned with the highest things,
whereas the new prophets of C are concerned with the lowest and most
sordid things.
Edward G. Nilges, Hong Kong 7 Sep 2009
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
David Wolff
> Seebach and Feather have not only gone after Schildt. They also
> continue to savage professional reputations whenever their standard is
> questioned. This despite the fact that the standard destroyed the very
> ability to teach C save in the most cautious, and fundamentalist way,
> such that "professors" today are well advised to be *imams* in
> *madrassahs* teaching *taliban*. In a sense this is an insult to Islam
> for the *imams* giving *fatwas* are concerned with the highest things,
> whereas the new prophets of C are concerned with the lowest and most
> sordid things.
>
> Edward G. Nilges, Hong Kong 7 Sep 2009
And where do you propose to put this in Wikipedia? Under "slander"?
-- David
spinoza1111
> have an appropriate newsgroups line in your header for your mail to be seen,
> or the newsgroup name in square brackets in the subject line. Sorry.
Erratum: In paragraph 4, for "corrupt enough to work" read "corrupt
enough to work for free". Thanks.
Seebs
On 2009-09-08, spinoza1111 <spino...@yahoo.com> wrote:
>== Proposal from Edward G. Nilges 7 Sep 2009 ==
> The vandalism of Schildt continues. I propose that the following text
> be added to the discussion of the controversy. I shall also post this
> for discussion at comp.lang.c and submit it to comp.lang.c.moderated.
What discussion of the controversy are you referring to?
> Other commentators, however, have found that Seebach's and Feather's
> objections to Schildt's work result from their POV which is that of
> self-serving "language lawyers" concerned less with clear explanation
> to working programmers and more with being "right all the time, even
> when it's undefined" in the words of one wag.
You're never gonna get this into Wikipedia. Name your sources. Who said
it? When? Where?
In any event, who are these "other commentators"? How have they "found"
this? Don't present the claim that someone somewhere said something --
present the evidence itself.
> For example, Schildt
> describes how things work in terms of the most common features of C
> runtimes, features that are not part of "the language".
I would tentatively grant this. I haven't looked at his stuff in some
years, but when I did, he described things pretty much as they existed
on DOS systems, or possibly early Windows. Many of the things he said
were untrue for other common systems.
> This is an
> excellent way to help programmers, typically men and women who want a
> "shirtsleeves" POV and to understand how things work,
Well, how they work sometimes.
> only to have
> Seebach condemn him, in a spirit with a nasty overtone of religious
> fundamentalism (made merely nastier by the secular, sordid and
> pecuniary goals of programming language standardization in service to
> corporations) for daring to speak of such Eleusinian mysteries as the
> "stack"...which looks backwards to an era when programmers in
> corporations were admonished or terminated for excess curiosity.
Wait, huh?
Hi, I'm "Seebach". Pleased to meet you. I am mystified by these
criticisms. I don't see how you find any "religious fundamentalism"
in my views of programming.
Lemme be blunt, though: I don't even remember most of this stuff. I
think it's been ten years since I last looked at the Schildt books. I
remember being utterly gobsmacked to find an example using <> instead
of != in a book nominally about C, so I went and grabbed the book,
did a quick writeup, and basically forgot about it. I don't think I had
even been actively involved at C standardization back then, but I could be
wrong; you'd have to go look at the dates, I don't know them.
I have never heard of "an era when programmers in corporations were
admonished or terminated for excess curiousity". Certainly, I've never
seen one, and I've been working as a programmer fairly close to full time
for a while now. (For the curious, I work at Wind River, now a subsidiary
of Intel, so I guess we're a big company.)
> It is widely believed today that C99 as a standardization effort
> failed rather miserably.
Again, don't use the passive voice to disguise the principal actors. Who
believes this?
You run the risk that people will think it's just you, and since no one
knows who you are or what you're talking about, that's sort of a weakness.
> The reason, according to some,
Again, according to whom, specifically?
> is that it was
> less concerned with the needs of working programmers, and more
> concerned with spending public monies (in the spirit of the Bush-
> Clinton years of privatization) on protecting corporate profits, here
> making as many compilers as possible "work" by leaving common sense
> functionality "undefined", so that compiler developers could be shed
> by compiler development and other corporations, and their investment
> protected.
Sadly, Usenet is a text-only medium, but what I clearly need here is a
picture of a giant temple in Cambodia, captioned "WAT?"
As it happens, I was an active participant in the C committee during the
C99 era. I did this on my own dime; the extent of support I received from
my employer (BSDi, at first, later Wind River) was that they counted only
half the time I spent at meetings as vacation, making it possible for me to
attend meetings.
The major corporate interests were compiler developers, and the people
representing them were compiler workers -- who seemed enthusiastic about
building substantial new functionality into the language.
I assure you, if you wanted to shed compiler developers, dropping the IEEE
annex and the type-generic math functions would have been MUCH more
significant.
Meanwhile, we committed everyone to supporting 64-bit math even on 16-bit
processors, committed to standard division semantics, and otherwise
standardized things substantially.
In fact, the bulk of the "undefined behavior" cases are there, not so that
compiler writers can do LESS work, but so that they can do MORE work -- such
as aggressive optimizations.
> There was no interest outside Open Source in making
> correct, much less excellent, C compilers in 1999, C compilers having
> become commodities, and there was no fiduciary reason for companies to
> fix compilers to conform to a more precise standard: therefore, the
> standard was made as undefined (not a standard, in other words) as
> possible in a giveaway to corporations which looked forward to the
> monies handed over to banks in 2008.
I do not believe that, even today, C compilers are "commodities". I did
some experimentation with IBM's research compiler and compared it to gcc
on the Cell; the differences were really quite noticeable, and given that
this is an environment targeted at supercomputing apps, I think a 10%-20%
difference in performance of generated code pretty much refutes the notion
that compilers are a "commodity".
> It appears to many of us that Schildt was a sacrificial lamb, a
> representative of an individual knower,
Uh, no.
He was a representative of someone who wrote books about issues he knew
nothing about. (Not that I can claim that there's no errors in my books;
if my esteemed critic would like a copy of Portable Shell Scripting to
comb through for errors, I'm pretty sure there's at least a dozen.)
> and of the type of
> knowledgeable programmer who (like Carthage) had to be destroyed, for
> his knowledge is now the private property of corporations, to be
> preserved or destroyed at will.
Uh, no. His "knowledge" was, as it happens, just plain wrong.
(Wording amended as requested in next sentence):
> In all of this, the public interest
> was unmentioned, and the public was damned, not only by corporations
> but also by people corrupt enough to work for free, nor for the wretched
> of the earth, but for Moloch itself: the corporation.
I can make no sense of "corrupt enough to work for free". The volunteer
work I've done over the years (and there isn't that much of it) doesn't
exactly seem "corrupt" to me. I do things because I believe them to be
important.
> Seebach and Feather have not only gone after Schildt. They also
> continue to savage professional reputations whenever their standard is
> questioned.
Er, we have?
I am unaware of this. I am all for people questioning the standard. I hear
there's a new one being worked on, and it sounds like they're continuing
to focus on things that compiler developers want to add based on feedback
from the users who need the best performance they can get from their
compilers.
> This despite the fact that the standard destroyed the very
> ability to teach C save in the most cautious, and fundamentalist way,
> such that "professors" today are well advised to be *imams* in
> *madrassahs* teaching *taliban*. In a sense this is an insult to Islam
> for the *imams* giving *fatwas* are concerned with the highest things,
> whereas the new prophets of C are concerned with the lowest and most
> sordid things.
I'm afraid I don't know enough of these words to understand the analogy.
I recently did a technical review for the second edition of Kim King's
excellent _C: A Modern Approach_. I don't see anything in it that I would
call "cautious" or "fundamentalist", and I found it a delightful book.
> Edward G. Nilges, Hong Kong 7 Sep 2009
Hello, Edward. Let me tell you a story.
Long ago, I was in college. I had an Amiga. And I wanted to learn to
program. I used the college computers, which ran UNIX, and I used the Amiga
in my dorm room.
I tried to program, and I had some issues, because I kept getting answers
that didn't work for me. People told me to use getch() to read characters
without echoing them, but it didn't work. Why?
* MS-DOS, which they used: getch() is in <conio.h> and does what they said.
* UNIX: getch() is in <curses.h> and may or may not do what they said, but
requires you to switch to a wholly different I/O mechanism.
* Amiga: getch() is not defined by my compiler.
I ran into a lot of trouble with this, until someone (pretty sure it was
Chris Torek) explained to me about the difference between the standard and
the specific implementation. I was fascinated by this concept, and started
exploring it.
Sure enough: If I wrote according to this "standard", my code worked on my
Amiga and on the UNIX machines. If I separated out parts I couldn't make
standard, I could have most of a program work on both systems, with a few
narrowly-defined bits which were system-specific.
This meant that I could make progress. I could write programs and expect
them to work. I could predict what they'd do. I could, in short, *get
things done*.
I got more involved in, and interested in, the standard. I spent a few years
going to C meetings (something Schildt never did that I know of; he was a
"member", but he just paid for a membership, he never participated that
I'm aware of), listening to people explain what their customers wanted their
compilers to do. We spent a lot of time talking about what users would
expect, what could be done efficiently, and how to balance the need for
optimizations and performance against reasonable user expectations of how
things would work. We dealt with embedded systems, and kernel development,
and application development. We talked about systems with 8GiB of memory and
32-bit registers, and about systems with 16KiB of memory.
Throughout this process, I consistently found that the people I was working
with had a genuine interest in both compiler development and the use of the
resulting compilers to actually accomplish things. The compiler vendors
viewed their compilers in terms of the result to the user -- the ability to
get good performance on particular hardware, without sacrifcing the ability
to run that code on other hardware. Many members of the committee were
not compiler developers, but users of compilers. We had compiler writers,
software writers, and teachers involved in the process, and it stayed
remarkably focused. IMHO, the C99 standard is a solid and well-considered
standard which preserves the spirit of C remarkably well.
I would acknowledge that it has not seen the huge pressure for commercial
adoption that C89 did. There are two key influences:
1. C is much less of the market space than it used to be. C++, C#, Java,
Python, Ruby, and PHP have all entered into market spaces where C used to
be the best available choice. Quite simply, the market for C compilation
is a smaller chunk of the software market than it used to be.
2. C89 came into a complete vacuum, where users and compiler writers alike
had no way of establishing what they were expecting or what they needed.
C89 gave vendors a way to say "we support all of these standard features"
and developers a way to indicate what features they required. As such, it
had immense value to both developers and vendors. By contrast, C99 came
into a market where people had existing systems that WERE working and
WERE portable. Until C99 became widely available, it was a poor choice
for developers, but until developers used it, it wasn't as appealing to
vendors. In short, C99 didn't achieve as much market penetration in part
because C89 had been so very successful.
For what it's worth, the last large project I wrote used C99 features,
because they saved me time and effort in development and gave me clearer
code which ran better. We looked at the available market and what we needed
to run on, decided we felt safe counting on C99, and ran with it.
The relevance of this long rambling bit?
I am personally convinced, based on my experience, that a standards-based
approach to understanding C is more useful, and more effective, than an
approach based on how a particular system happened to work. I have spent
a great deal of time working with people in the C community, and consistently
found that your charges as to their motivation are somewhere on the fuzzy
boundary between merely baseless and genuinely incoherent.
I continue to believe that the sort of material I saw in Schildt's books
contributes directly to people being unable to develop code which reliably
does what they want it to do across a range of possible future systems.
I currently do compiler support -- I handle incoming bug reports against
the distribution of gcc we use. (Actually, I triage them; the actual fixes
are handled by Code Sourcery.) I see a lot of code that people think should
work differently than it does. On the whole, I consistently find that they
would not benefit from us defining the behaviors they're running into
differently, or at all, but rather, that they would benefit most from
greater familiarity with the tools and resources available to them in the
C language to reliably obtain their goals. I do not think that "working
programmers" suffer from a well-defined language which leaves compilers
ample room to optimize and improve performance. There are specific cases
where I am not totally sold on the decisions made in C99, but on the whole,
I think it does what it's supposed to do.
Reading your piece, I get the feeling you're upset, and angry, but I don't
understand why. You use a lot of vague language referring to anonymous
commentators or "many people", but you don't really get down to specific
examples of criticisms you feel are invalid. If you want to persuade people
that criticisms are invalid, I suggest that you should look at the technical
merits of the criticisms, and explore those.
So, how about this. Please identify specific criticisms of Schildt on
particular technical issues, and explain why you think those are bad
criticisms. If the answer is "Seebach got the standard wrong", go ahead
and explain why. If the answer is "the standard is too cautious, and should
have guaranteed the behavior Schildt described", go ahead and explain why
you think that behavior is a reasonable thing for the standard to enforce.
When the opportunity to be "toolchain guy" came up, and I jumped at it,
some of my coworkers were a bit surprised. Most people don't regard working
on compilers as fun. I do. I love to look at code and think about what it
should (or shouldn't) do. I love to think about what compilers can reasonably
do to optimize performance, and whether a given optimization preserves the
semantics of a program or not. This is a field which continues to fascinate
me and delight me, and if you have the idea that there are things we have not
considered, I would love to know more about it. It's been solidly over
ten years since the comp.lang.c regulars explained to me why some things
couldn't be done portably, and I am still learning new things about C just
about every day.
Thanks for the feedback. I don't particularly agree with many of your
evaluations, but I'm actually sort of pleased to know that people even
remember some of the stuff I wrote about C way back in the day. Maybe
I should take more time (hah!) and update some of my old writings on these
various topics.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> In article <clcm-20090908-0...@plethora.net>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > == Proposal from Edward G. Nilges 7 Sep 2009 ==
> [snip]
> > Seebach and Feather have not only gone after Schildt. They also
> > continue to savage professional reputations whenever their standard is
> > questioned. This despite the fact that the standard destroyed the very
> > ability to teach C save in the most cautious, and fundamentalist way,
> > such that "professors" today are well advised to be *imams* in
> > *madrassahs* teaching *taliban*. In a sense this is an insult to Islam
> > for the *imams* giving *fatwas* are concerned with the highest things,
> > whereas the new prophets of C are concerned with the lowest and most
> > sordid things.
>
> > Edward G. Nilges, Hong Kong 7 Sep 2009
>
> And where do you propose to put this in Wikipedia? Under "slander"?
If you investigate the disorganized "laundry lists" of charges put out
by Seebach and Feather, you discover that Schildt was libeled. The
laundry lists are padded with trivia and matters of style and
interpretation. Most seriously, they criticise Schildt for implying
that the Standard requires functionality merely when Schildt is
explaining how C works by using concepts which are known to be
necessary to implement C.
>
> -- David
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Francis Glassborow
> On Sep 10, 5:28 am, dwolf...@panix.com (David Wolff) wrote:
>> In article <clcm-20090908-0...@plethora.net>,
>>
>> spinoza1111 <spinoza1...@yahoo.com> wrote:
>>> == Proposal from Edward G. Nilges 7 Sep 2009 ==
>> [snip]
>>> Seebach and Feather have not only gone after Schildt. They also
>>> continue to savage professional reputations whenever their standard is
>>> questioned. This despite the fact that the standard destroyed the very
>>> ability to teach C save in the most cautious, and fundamentalist way,
>>> such that "professors" today are well advised to be *imams* in
>>> *madrassahs* teaching *taliban*. In a sense this is an insult to Islam
>>> for the *imams* giving *fatwas* are concerned with the highest things,
>>> whereas the new prophets of C are concerned with the lowest and most
>>> sordid things.
>>> Edward G. Nilges, Hong Kong 7 Sep 2009
>> And where do you propose to put this in Wikipedia? Under "slander"?
>
> If you investigate the disorganized "laundry lists" of charges put out
> by Seebach and Feather, you discover that Schildt was libeled. The
> laundry lists are padded with trivia and matters of style and
> interpretation. Most seriously, they criticise Schildt for implying
> that the Standard requires functionality merely when Schildt is
> explaining how C works by using concepts which are known to be
> necessary to implement C.
I am deeply insulted that you have not added my name to the above 2.
IMNSHO Schikdt is responsible for more bad and dangerous code being
written than any other two authors combined.
Yes he did get better in his latter books but generally there are simply
too many real errors in his books. The problem is that he writes
fluently and can be easily understood so his work is popular even if
erroneous.
Now I have no idea why you want to raise this issue. Schildt has made a
great deal of money from his writing even if his understanding of what
he is writing about is sometimes tenuous.
Note that statements of error cannot constitute libel.
Seebs
> If you investigate the disorganized "laundry lists" of charges put out
> by Seebach and Feather, you discover that Schildt was libeled. The
> laundry lists are padded with trivia and matters of style and
> interpretation. Most seriously, they criticise Schildt for implying
> that the Standard requires functionality merely when Schildt is
> explaining how C works by using concepts which are known to be
> necessary to implement C.
Except they aren't.
I was thinking about this some, and I want to give you an example of a
real-world implementation in which the explanations Schildt offers would
be worthless to you.
The context: I do toolchain maintenance and bug triage. We build a lot
of stuff with our compilers, across several different architectures. (For
the curious: I have to keep track of ARM, IA32, MIPS, PowerPC, and SPARC
toolchain issues.) One of the things we build is Linux kernels, from a shared
source base, across about eighty targets.
We recently encountered a bug report. A particular networking feature would
cause kernel panics on a subset of MIPS kernels. This feature worked fine
on every other system. After some experimentation, we were able to isolate
the problem to a pair of files: If you compiled these files with optimization
disabled, the kernel ran as expected and everything worked fine.
You might think that this was a compiler bug; we certainly did. After all, it
was generating incorrect code for these files, right? And if not, it was
certainly, you would expect, a problem with the code in these files.
Wrong on both counts.
Let's explore the bug a little more closely. The exact symptom was roughly as
follows: A pointer inexplicably became a null pointer. You could check the
pointer's value repeatedly, and it was not null. Then, after a hunk of code
which did not refer to it or touch it in any way, it suddenly became null.
What happened?
It turns out that, on this particular architecture, some registers are saved
by the called function, if and only if it needs to use those registers. The
pointer in question was being stored in one of those registers when the
modules in question were compiled with optimizations; otherwise, it was not.
The register in question was getting whacked. So, the next question is,
why is it getting whacked? Maybe the compiler isn't saving it? No, no,
that's fine, the compiler does indeed save, and restore, the register. You
never skip the save and restore code.
No, the problem was this.
About five calls in from the functions where the crash occurred (all small
helper functions which didn't use all that many registers), there was a
function which DID use that register. Thus, this function began with code to
stash the values of all these registers on... dare I say it... the stack.
Next to some automatic variables.
And there is an idiom in this hunk of networking code of declaring an
array:
elaborate_type *stuff[FOO_MAX + 1];
and in this copy of the code, it had been declared as:
elaborate_type *stuff[FOO_MAX];
Well, there's a macro that calls an initializing routine which initializes
entries 0 through FOO_MAX, inclusive. And this turns out to, on some but not
all of the MIPS systems, overwrite the hunk of space where the saved register
values are stored. And thus, when the register is restored, it's restored to
0. None of the intervening functions use it, but when we finally get back to
the previous function which was using it, the pointer's value has changed.
Oops.
The problem is, even though indeed this implementation has "a stack", if you
adopt Schildt's model and description of what's happening, it makes it
impossible to see the error. The value in question was not an argument to
the function being called. It was not an automatic variable in that function.
Nor was it an argument to, or an automatic variable in, the caller. That
variable was not on "the stack" in terms of the abstract C machine, and
all of Schildt's explanations of how you use the "stack" omit the possibility
that, on some machines, you'll have registers which are not part of the
calling convention, so functions which want to use them have to save them
somewhere, and one of their options is to save these registers on the stack,
right next to the stuff that everyone says is on the stack.
More significantly, if you were in the function where the register was
originally used, it was an automatic variable which was NOT on the stack.
If you come to a problem like this with a Schildt-based theory of what "the
stack" is, and how things are pushed and popped on the stack, you will
have no chance of guessing how something from five layers up the stack could
end up adjacent to one of our newest automatic variables.
In short, he is not explaining how C works. He is explaining how a few
specific C implementations worked on specific target platforms. Believing
the things he says is misleading.
Now, the above explanation is full of details about an implementation that
you'd only likely know if you happened to have a fairly senior MIPS specialist
on hand (hi, Ralf!). So the question is, if you didn't know any of this
stuff, and just knew standard C, would you have a chance of catching it?
Of course you would. It would be patently obvious (as it was the moment I
found the right hunk of code) that the writes to the array exceeded the size
of the array. That's "undefined behavior". You'll note that, in this case,
"undefined behavior" didn't mean "crash right away" or "overwrite a value
that's even got a name in scope in the current function" or anything like
that; it meant that a local variable several function calls away might get
overwritten, but whether or not this would happen would depend on compilation
options used for code *nowhere near the bug*.
Approaching this from a standard C perspective makes it easy to understand
and fix the bug (but, I admit, doesn't help you at all in figuring out where
to look). Approaching it from a platform-specific level with real
understanding of the local ABI makes it possible to track down the bug.
Approaching it from the perspective of someone who believes the stuff Schildt
writes about "how C works", though, would make it impossible to diagnose;
the behavior is simply too different from the model Schildt presents.
-s
p.s.: In defense of the Linux kernel folks, it was our fault for merging
an early version of a patch before it went into the mainline kernel; the
version that actually went in upstream had the array declared correctly.
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
>
> >== Proposal from Edward G. Nilges 7 Sep 2009 ==
> > The vandalism of Schildt continues. I propose that the following text
> > be added to the discussion of the controversy. I shall also post this
> > for discussion at comp.lang.c and submit it to comp.lang.c.moderated.
>
> What discussion of the controversy are you referring to?
The controversy on Schildt's books here and on Amazon, Peter.
>
> > Other commentators, however, have found that Seebach's and Feather's
> > objections to Schildt's work result from their POV which is that of
> > self-serving "language lawyers" concerned less with clear explanation
> > to working programmers and more with being "right all the time, even
> > when it's undefined" in the words of one wag.
>
> You're never gonna get this into Wikipedia. Name your sources. Who said
> it? When? Where?
I don't care. Wikipedia is a violation of tax law in that it was
founded for profit but portrays itself as nonprofit. Its editors no
longer know subject matter and are thieves of intelllectual
production.
>
> In any event, who are these "other commentators"? How have they "found"
> this? Don't present the claim that someone somewhere said something --
> present the evidence itself.
A text is a text, not "evidence".
>
> > For example, Schildt
> > describes how things work in terms of the most common features of C
> > runtimes, features that are not part of "the language".
>
> I would tentatively grant this. I haven't looked at his stuff in some
> years, but when I did, he described things pretty much as they existed
> on DOS systems, or possibly early Windows. Many of the things he said
> were untrue for other common systems.
At the time most of his audience needed him to focus on MS DOS and
Windows. Peter, is this why you made trouble for him? Because I was
well acquainted with anti-IBM snobbery in the past, and anti-Microsoft
snobbery in the present. I have no problem with pointing out the
defects of IBM and Microsoft software and hardware: expert IBM and
Microsoft people are very familiar with them: but your campaign
marshaled ignorance in my view.
>
> > This is an
> > excellent way to help programmers, typically men and women who want a
> > "shirtsleeves" POV and to understand how things work,
>
> Well, how they work sometimes.
And why (the stack narrative being essential in explanation).
>
> > only to have
> > Seebach condemn him, in a spirit with a nasty overtone of religious
> > fundamentalism (made merely nastier by the secular, sordid and
> > pecuniary goals of programming language standardization in service to
> > corporations) for daring to speak of such Eleusinian mysteries as the
> > "stack"...which looks backwards to an era when programmers in
> > corporations were admonished or terminated for excess curiosity.
>
> Wait, huh?
>
> Hi, I'm "Seebach". Pleased to meet you.
Hello, Mr. Seebach.
> I am mystified by these
> criticisms. I don't see how you find any "religious fundamentalism"
> in my views of programming.
That's because complementarily to your mathematical and scientific
intelligence, you have failed to see a textual isomorphism between
religious fundamentalism and your technical fundamentalism.
>
> Lemme be blunt, though: I don't even remember most of this stuff. I
> think it's been ten years since I last looked at the Schildt books. I
> remember being utterly gobsmacked to find an example using <> instead
> of != in a book nominally about C, so I went and grabbed the book,
Sounds like a trivial reason to be gobsmacked.
> did a quick writeup, and basically forgot about it. I don't think I had
> even been actively involved at C standardization back then, but I could be
> wrong; you'd have to go look at the dates, I don't know them.
>
> I have never heard of "an era when programmers in corporations were
> admonished or terminated for excess curiousity". Certainly, I've never
> seen one, and I've been working as a programmer fairly close to full time
> for a while now. (For the curious, I work at Wind River, now a subsidiary
> of Intel, so I guess we're a big company.)
This is the reality for programmers (especially minority and female
programmers). How nice for you to be so ... esconced.
>
> > It is widely believed today that C99 as a standardization effort
> > failed rather miserably.
>
> Again, don't use the passive voice to disguise the principal actors. Who
> believes this?
>
> You run the risk that people will think it's just you, and since no one
> knows who you are or what you're talking about, that's sort of a weakness.
A number of people at clc have conceded this, litera scripta manet.
>
> > The reason, according to some,
>
> Again, according to whom, specifically?
>
> > is that it was
> > less concerned with the needs of working programmers, and more
> > concerned with spending public monies (in the spirit of the Bush-
> > Clinton years of privatization) on protecting corporate profits, here
> > making as many compilers as possible "work" by leaving common sense
> > functionality "undefined", so that compiler developers could be shed
> > by compiler development and other corporations, and their investment
> > protected.
>
> Sadly, Usenet is a text-only medium, but what I clearly need here is a
> picture of a giant temple in Cambodia, captioned "WAT?"
Nixon invaded Cambodia while I was discovering that IBM refused to fix
a broken Fortran compiler that we needed in my computer science class.
Middle class white students at the Univ of Chicago had no such
problem, and I fixed the compiler a year later in machine language and
made it available to students. I can connect. Can you, Peter?
>
> As it happens, I was an active participant in the C committee during the
> C99 era. I did this on my own dime; the extent of support I received from
> my employer (BSDi, at first, later Wind River) was that they counted only
> half the time I spent at meetings as vacation, making it possible for me to
> attend meetings.
You should have negotiated a better deal.
>
> The major corporate interests were compiler developers, and the people
> representing them were compiler workers -- who seemed enthusiastic about
> building substantial new functionality into the language.
As employed compiler developers, I am certain they were. I was
likewise enthusiastic as a compiler developer. The problem is that
there's a sharp separation between people's roles as compiler
developers paid to actually feel enthusiastic and those people years
later, homeless or without medical insurance owing to the lack of
interest in actually fixing C as opposed to standardizing mistakes on
behalf of their former employers.
>
> I assure you, if you wanted to shed compiler developers, dropping the IEEE
> annex and the type-generic math functions would have been MUCH more
> significant.
>
> Meanwhile, we committed everyone to supporting 64-bit math even on 16-bit
> processors, committed to standard division semantics, and otherwise
> standardized things substantially.
Very good as far as it goes.
>
> In fact, the bulk of the "undefined behavior" cases are there, not so that
> compiler writers can do LESS work, but so that they can do MORE work -- such
> as aggressive optimizations.
...at the cost of making C comprehensible in the vast majority of
cases.
>
> > There was no interest outside Open Source in making
> > correct, much less excellent, C compilers in 1999, C compilers having
> > become commodities, and there was no fiduciary reason for companies to
> > fix compilers to conform to a more precise standard: therefore, the
> > standard was made as undefined (not a standard, in other words) as
> > possible in a giveaway to corporations which looked forward to the
> > monies handed over to banks in 2008.
>
> I do not believe that, even today, C compilers are "commodities". I did
> some experimentation with IBM's research compiler and compared it to gcc
> on the Cell; the differences were really quite noticeable, and given that
> this is an environment targeted at supercomputing apps, I think a 10%-20%
> difference in performance of generated code pretty much refutes the notion
> that compilers are a "commodity".
>
> > It appears to many of us that Schildt was a sacrificial lamb, a
> > representative of an individual knower,
>
> Uh, no.
>
> He was a representative of someone who wrote books about issues he knew
> nothing about. (Not that I can claim that there's no errors in my books;
Up to this point ("knew nothing about") you sound sensible. But as in
the case of Clive Feather, you make global/null claims about him. And
then you start in on him, and you appear at that point to have an
unhealthy obsession.
> if my esteemed critic would like a copy of Portable Shell Scripting to
> comb through for errors, I'm pretty sure there's at least a dozen.)
You concede this. But you seem to assume that you should be forgiven
for errors, whereas the Outsider may not.
>
> > and of the type of
> > knowledgeable programmer who (like Carthage) had to be destroyed, for
> > his knowledge is now the private property of corporations, to be
> > preserved or destroyed at will.
>
> Uh, no. His "knowledge" was, as it happens, just plain wrong.
But when we investigate what's wrong, we find trivia, MS-DOS v unix
differences, and style.
>
> (Wording amended as requested in next sentence):
>
> > In all of this, the public interest
> > was unmentioned, and the public was damned, not only by corporations
> > but also by people corrupt enough to work for free, nor for the wretched
> > of the earth, but for Moloch itself: the corporation.
>
> I can make no sense of "corrupt enough to work for free". The volunteer
> work I've done over the years (and there isn't that much of it) doesn't
> exactly seem "corrupt" to me. I do things because I believe them to be
> important.
>
> > Seebach and Feather have not only gone after Schildt. They also
> > continue to savage professional reputations whenever their standard is
> > questioned.
>
> Er, we have?
Yes, in clc.
>
> I am unaware of this. I am all for people questioning the standard. I hear
> there's a new one being worked on, and it sounds like they're continuing
> to focus on things that compiler developers want to add based on feedback
> from the users who need the best performance they can get from their
> compilers.
Note how your language, from "want" to "performance", excludes
correctness while you scapegoat Schildt for incorrectness, not of
software, but in teaching software, an activity which requires
"incorrectness" in the form of metaphors and narrative.
FYI, what compiler developers "want" has nothing to do with
correctness or even efficiency. And wrong answers at high speed isn't
what users "need".
Psychologically, you've displaced the guilty secret, that it's nearly
impossible to produce safely correct software in C, in part owing to
your standardization, onto Schildt.
>
> > This despite the fact that the standard destroyed the very
> > ability to teach C save in the most cautious, and fundamentalist way,
> > such that "professors" today are well advised to be *imams* in
> > *madrassahs* teaching *taliban*. In a sense this is an insult to Islam
> > for the *imams* giving *fatwas* are concerned with the highest things,
> > whereas the new prophets of C are concerned with the lowest and most
> > sordid things.
>
> I'm afraid I don't know enough of these words to understand the analogy.
Look them up in wikipedia, then.
> read more »...
"The rest is silence". Hey, sweet Prince, this is no country for old
men: but when you were farting around with the Amiga I had had 14
years of experience as a bottom feeding programmer who'd evolved into
a compiler developer on the IBM mainframe.
I read the Algol 60 report in 1971 and I support language
standardization.
However, standardizing C was by 1999 lipstick on a pig, since aliasing
means that the standard cannot address the unsafety of C, only help C
programmers get wrong answers faster given your emphasis on
optimization. Standardization also sent the wrong message: that C was
appropriate outside of OS development and for new OS development.
Because of aliasing and because of its vaunted "closeness to the
machine", C is a fuzzy bounded language and more usefully viewed as a
set of human practices. It is not at all a formal, mathematical
notation and cannot be standardized. Therefore, Schildt was under the
US Constitution alone free to experimentally present his results using
C on the most common platform and present and explain those results to
programmers with no choice of language on the job.
You set out to destroy him. You did not, as did Niklaus Wirth at
ASPLOS 1987, question the interest in "optimization" when Dijkstra's
1999 question, how not to make a mess of it, hasn't been answered.
The result is that USA consumer electronics makes profits in part
owing to the unexplainable failure of complex devices which the user
is forced to replace rather than fix.
The result is the culture of clc wherein individuals similar to
Schildt are bullied for sins which the community itself is guilty of.
We only work here, Mr. Seebach, in the US without health insurance as
temps. We're tired of being bullied by employers to put lipstick on a
pig. We're never (never) given enough time to do it right because at
the top, US and UK computer scientists have been always more
interested in premature optimization and the profits of corporations.
Seebs
> The controversy on Schildt's books here and on Amazon, Peter.
I see no controversy.
> I don't care. Wikipedia is a violation of tax law in that it was
> founded for profit but portrays itself as nonprofit.
Even assuming this were true, what do I care? I'm not the IRS.
> Its editors no
> longer know subject matter and are thieves of intelllectual
> production.
You imply a time at which the wikipedia editors knew their subject matter?
Also, how are they "thieves"? I've never heard of them stealing anything.
Being given is not the same as stealing.
>> In any event, who are these "other commentators"? How have they "found"
>> this? Don't present the claim that someone somewhere said something --
>> present the evidence itself.
> A text is a text, not "evidence".
Nonetheless, if you don't name the commentators and cite to when and where
they said it, it's not a substantiated claim.
> At the time most of his audience needed him to focus on MS DOS and
> Windows.
No, they didn't.
There is nothing that they needed to accomplish which was made better or
easier by that choice, and a great deal that was made harder for them.
> Peter, is this why you made trouble for him?
No.
I don't know, or care, whether I "made trouble" for him. He said things
in print which were false. I corrected them. He did it a lot. I pointed
out that it was a problem and that the books were not accurate sources.
Given that, according to Wikipedia, his books have been bestsellers for
three decades, I don't really see any evidence that he's been noticably
harmed.
> Because I was
> well acquainted with anti-IBM snobbery in the past, and anti-Microsoft
> snobbery in the present. I have no problem with pointing out the
> defects of IBM and Microsoft software and hardware: expert IBM and
> Microsoft people are very familiar with them: but your campaign
> marshaled ignorance in my view.
"Campaign"?
Dude. I wrote a single web page on the topic, which took me probably an
hour. I posted it on my web site. I pretty much forgot about it. I think
I exchanged a couple of emails with people at his publisher, decided that
their attitude did not suggest that they were seriously interested in
correcting the defects, and... Honestly, I don't think I've done anything
else on the topic until the last couple of months. Someone contacted me
earlier this summer to ask some questions about one of my specific criticisms.
I've gotten a couple of messages about it, which I've responded to. I saw
your post here (it'd be hard for me to miss it!) and thought I'd comment.
This is not exactly a "campaign". I've put more time and effort in any given
week of the last decade into playing video games than I have put into thinking
about or writing about Schildt in that whole decade.
>> Well, how they work sometimes.
> And why (the stack narrative being essential in explanation).
Well, hang on.
Given the existence of stackless implementations, how is that narrative
"essential"? Can you get more concrete here, and show us something which
can be explained through the "stack" narrative, and which is "essential"?
The word "essential" implies that, without a given thing, something can't
be accomplished. Do you suggest that it is *impossible* to explain C
without talking about stacks, even though real C implementations exist
which don't use them? (I already provided a detailed example of a case
where, even though there WAS a stack, the "stack narrative" would make
it virtually impossible to comprehend the failure of a given program.)
> That's because complementarily to your mathematical and scientific
> intelligence, you have failed to see a textual isomorphism between
> religious fundamentalism and your technical fundamentalism.
Why, yes. Yes, I have failed to see it. One solution for this would be
for you to offer more detailed explanations of where you feel this
relationship exists.
>> Lemme be blunt, though: I don't even remember most of this stuff. I
>> think it's been ten years since I last looked at the Schildt books. I
>> remember being utterly gobsmacked to find an example using <> instead
>> of != in a book nominally about C, so I went and grabbed the book,
> Sounds like a trivial reason to be gobsmacked.
Really?
There has never been, to the best of my knowledge, any C-like language with
that operator in it. I didn't even realize what it was until someone who
used to use Pascal told me it was used for != in some variants of Pascal.
It's not a mistake I can make sense of. There's nothing it could be a
typo for, there's nothing it could have meant -- it's just a bit of Pascal
code inexplicably inserted into a code sample.
> This is the reality for programmers (especially minority and female
> programmers).
Is it? Do you have some kind of data supporting this theory?
> A number of people at clc have conceded this, litera scripta manet.
Again, vague assertions like this buy you nothing. You might as well
just say "the lurkers support me in email!" or go whole hog and post
under the name "Socky McSockington" and say "Me Too!" a lot.
>> Sadly, Usenet is a text-only medium, but what I clearly need here is a
>> picture of a giant temple in Cambodia, captioned "WAT?"
> Nixon invaded Cambodia while I was discovering that IBM refused to fix
> a broken Fortran compiler that we needed in my computer science class.
Uh, huh?
> Middle class white students at the Univ of Chicago had no such
> problem, and I fixed the compiler a year later in machine language and
> made it available to students. I can connect. Can you, Peter?
I don't even know what you mean by "connect" in this context.
>> As it happens, I was an active participant in the C committee during the
>> C99 era. I did this on my own dime; the extent of support I received from
>> my employer (BSDi, at first, later Wind River) was that they counted only
>> half the time I spent at meetings as vacation, making it possible for me to
>> attend meetings.
> You should have negotiated a better deal.
Impressive! It barely took you a page to go straight from talking about how
I have it easy compared to other programmers, to how the corporation screwed
me.
> As employed compiler developers, I am certain they were. I was
> likewise enthusiastic as a compiler developer. The problem is that
> there's a sharp separation between people's roles as compiler
> developers paid to actually feel enthusiastic and those people years
> later, homeless or without medical insurance owing to the lack of
> interest in actually fixing C as opposed to standardizing mistakes on
> behalf of their former employers.
Well, that's a pretty huge and sweeping claim. The industry has been
remade a couple of times, multiple new languages and ways of approaching
programming have come along and gained widespread usage, often replacing
things that used to be done in C, but you think that it's unspecified
flaws in standardization, rather than marketplace shifts, that are at
fault in the relatively smaller number of active C compiler developers.
That's fascinating, and by fascinating, I mean it sounds borderline
schizophrenic.
>> In fact, the bulk of the "undefined behavior" cases are there, not so that
>> compiler writers can do LESS work, but so that they can do MORE work -- such
>> as aggressive optimizations.
> ...at the cost of making C comprehensible in the vast majority of
> cases.
Why, yes. When the time came that we had to consider whether or not to
make C comprehensible in the vast majority of cases, we said "damn the
torpedoes! We will make C comprehensible." So we did. And as you say,
C is indeed comprehensible in the vast majority of cases.
It was a very very small price to pay, for huge benefits, but I think it
was worth it.
Hint: C is in no way "incomprehensible".
>> He was a representative of someone who wrote books about issues he knew
>> nothing about. (Not that I can claim that there's no errors in my books;
> Up to this point ("knew nothing about") you sound sensible. But as in
> the case of Clive Feather, you make global/null claims about him. And
> then you start in on him, and you appear at that point to have an
> unhealthy obsession.
Welcome to conversational English, where "know nothing about" is hyperbole
and means "not know very much about".
> You concede this. But you seem to assume that you should be forgiven
> for errors, whereas the Outsider may not.
I do not recognize the category of "outsider"; it is foreign to my view
of humanity.
I don't think "forgiving" or "not forgiving" for errors is a coherent concept.
Errors are corrected or not-corrected. I don't care who made them, when, or
how; just whether things are fixed.
I disrecommended Schildt's book because the frequency and quality of the
errors was such as to suggest fundamental problems with understanding C,
and people who "learned C" from his books consistently ended up with
severe difficulty understanding the language as it existed outside a small
subset of implementations.
> But when we investigate what's wrong, we find trivia, MS-DOS v unix
> differences, and style.
Actually, no. We find substantive errors that point to a genuine
misunderstanding of the nature of C.
You might think that, if he'd claimed to be writing only about "C for MS-DOS",
the complaints would be mostly resolved, but in fact, many serious complaints
would survive, because even within that environment, many of his
"explanations" are simply incorrect.
>> > Seebach and Feather have not only gone after Schildt. They also
>> > continue to savage professional reputations whenever their standard is
>> > questioned.
>>
>> Er, we have?
>
> Yes, in clc.
I haven't posted in clc for years -- I only started reading it again the other
day.
But you have made an exceptional claim here; you have claimed first that we
"savage professional reputations" -- a pretty high standard, I'd say -- and
furthermore that we do so *whenever* "their standard is questioned".
So, if we find even one case of someone questioning the standard, and not
having his/her/its professional reputation "savaged", your claim is false. If
we were to find that the vast majority of people questioning the standard
were treated courteously and in many cases invited to contribute or write
papers for the committee to consider in C0x, that would go even further...
And that, in fact, is what seems to happen.
> Note how your language, from "want" to "performance", excludes
> correctness while you scapegoat Schildt for incorrectness, not of
> software, but in teaching software, an activity which requires
> "incorrectness" in the form of metaphors and narrative.
I have no clue what you just said. This is sorta word salad; I would
recommend that you check with a mental health professional and see whether
you might have a schizotypal disorder.
I don't see any exclusion of correctness in my language; neither "want" nor
"performance" has any such implications. Furthermore, effective teaching
most certainly does not require incorrectness. An experienced and skilled
teacher can generally find a narrative which is both communicative *and
correct*. Failing that, competent teachers explain that their narrative is an
approximation to explore a particular quality, then go on to explain the
details glossed over by the narrative.
> FYI, what compiler developers "want" has nothing to do with
> correctness or even efficiency. And wrong answers at high speed isn't
> what users "need".
Empirically, compiler developers do indeed want correctness and efficiency,
given that these are the things that seem to consume most of their time.
> Psychologically, you've displaced the guilty secret, that it's nearly
> impossible to produce safely correct software in C, in part owing to
> your standardization, onto Schildt.
Uh, what?
You have the chronology wrong. I concluded that Schildt's writing was tripe
before I started working on standardization. It is impossible for me to have
done so based on hypothesized guilt for something that hadn't even happened
yet.
Furthermore, I don't agree that it's particularly impossible to produce
safely correct software in C. It's hard, as it is in most languages -- harder
than in many modern languages, I'd say. However, C does a good job of
what it was designed to do, even today. I do not think the problems you
describe are a result of poor standardization.
> Look them up in wikipedia, then.
That wouldn't help. If you want to make a point, make it clearly using
terms in a language I know.
> "The rest is silence". Hey, sweet Prince, this is no country for old
> men: but when you were farting around with the Amiga I had had 14
> years of experience as a bottom feeding programmer who'd evolved into
> a compiler developer on the IBM mainframe.
So what?
> However, standardizing C was by 1999 lipstick on a pig, since aliasing
> means that the standard cannot address the unsafety of C, only help C
> programmers get wrong answers faster given your emphasis on
> optimization.
The standard provided solid new tools for dealing with aliasing... up to a
point. Past that point, if you want that kind of safety, you shouldn't be
using C. That's not what C is for.
> Standardization also sent the wrong message: that C was
> appropriate outside of OS development and for new OS development.
It didn't send any message either way on this issue.
> Because of aliasing and because of its vaunted "closeness to the
> machine", C is a fuzzy bounded language and more usefully viewed as a
> set of human practices. It is not at all a formal, mathematical
> notation and cannot be standardized.
And yet, it has been standardized well enough to allow many, many,
compilers to produce working code from standard-compliant source across
a bewildering array of CPU types.
> Therefore, Schildt was under the
> US Constitution alone free to experimentally present his results using
> C on the most common platform and present and explain those results to
> programmers with no choice of language on the job.
I don't see any relevance at all to the Constitution. Schildt is of course
free to write anything he wants. Other people are too.
> You set out to destroy him.
No.
I set out to try to correct errors in programming texts so that future
programmers would have an easier time learning and understanding C.
> The result is that USA consumer electronics makes profits in part
> owing to the unexplainable failure of complex devices which the user
> is forced to replace rather than fix.
I don't think this has anything to do with C.
> The result is the culture of clc wherein individuals similar to
> Schildt are bullied for sins which the community itself is guilty of.
I don't think there's a logical connection here.
> We only work here, Mr. Seebach, in the US without health insurance as
> temps. We're tired of being bullied by employers to put lipstick on a
> pig. We're never (never) given enough time to do it right because at
> the top, US and UK computer scientists have been always more
> interested in premature optimization and the profits of corporations.
This is largely true... And has nothing to do with C standardization,
at all. The people I worked with in standardization were consistently
those who valued correctness and clarity over premature optimization,
and who understood that writing good software correctly takes time
and effort. The C standard was written to try to make it possible to
write clear, functional, code which behaves in an understandable manner.
For the most part, I think it does a good job of this. The impossibility
of producing good code under bad conditions has much less to do with
the choice of language, and much more to do with a schedule that is
fundamentally incorrect.
It really comes across as though you have specific personal experiences
which you are trying to achieve closure for. You've said nothing, and
illustrated nothing, that would suggest that you have any kind of
informational basis for your claims. You seem very upset, but every
time you explain why, there are huge, gaping, holes between the
world in which other people appear to be living, and the world you
are describing. You connect events twenty years apart and call it
causality without any kind of explanation of the causal process, and
ignoring much better-supported and generally accepted explanations.
I have no idea what the story here is, but it has become clear that it's
nothing to do with standardization, and nothing to do with Schildt, and
nothing to do with the various well-founded criticisms of his writing.
Try coming out with the actual story of what, specifically, happened to you
that has you so upset, and I think you'll get better results. Did you
not get a job because the interviewer disagreed with something you learned
from a Schildt book or something?
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
>> by Seebach and Feather, you discover that Schildt was libeled. The
>> laundry lists are padded with trivia and matters of style and
>> interpretation. Most seriously, they criticise Schildt for implying
>> that the Standard requires functionality merely when Schildt is
>> explaining how C works by using concepts which are known to be
>> necessary to implement C.
>
>
>Except they aren't.
>
>I was thinking about this some, and I want to give you an example of a
>real-world implementation in which the explanations Schildt offers would
>be worthless to you.
Having left programming, in no little disgust at the personalities of
programming, after thirty years, I teach English and creative writing
in addition to intro computer science. I have learned that intolerant
students, who believe words are things, make the slowest progress.
Therefore, I will be the judge as to whether a text has “intrinsic
worth”. Literary studies shows that the common person’s distinction
between fact and fiction to be negotiable (which does not, as in the
caricature, mean it does not exist, any more that there is no
difference between a shade at point a and b where a and b are
separated by a gradient).
>
>
>The context: I do toolchain maintenance and bug triage. We build a lot
>of stuff with our compilers, across several different architectures. (For
>the curious: I have to keep track of ARM, IA32, MIPS, PowerPC, and SPARC
>toolchain issues.) One of the things we build is Linux kernels, from a shared
>source base, across about eighty targets.
>
Got it.
>
>We recently encountered a bug report. A particular networking feature would
>cause kernel panics on a subset of MIPS kernels. This feature worked fine
>on every other system. After some experimentation, we were able to isolate
>the problem to a pair of files: If you compiled these files with optimization
>disabled, the kernel ran as expected and everything worked fine.
>
Got it.
>
>You might think that this was a compiler bug; we certainly did. After all, it
>was generating incorrect code for these files, right? And if not, it was
>certainly, you would expect, a problem with the code in these files.
>
Absolutely, Socrates. Most assuredly a kiss my ass.
>
>Wrong on both counts.
>
No way!
>
>Let's explore the bug a little more closely. The exact symptom was roughly as
>follows: A pointer inexplicably became a null pointer. You could check the
>pointer's value repeatedly, and it was not null. Then, after a hunk of code
>which did not refer to it or touch it in any way, it suddenly became null.
>
Welcome to the weird and wonderful world of C. This is why we have
Java, isn’t it.
>
>What happened?
>
I can’t wait.
>
>It turns out that, on this particular architecture, some registers are saved
>by the called function, if and only if it needs to use those registers. The
>pointer in question was being stored in one of those registers when the
>modules in question were compiled with optimizations; otherwise, it was not.
>The register in question was getting whacked. So, the next question is,
>why is it getting whacked? Maybe the compiler isn't saving it? No, no,
>that's fine, the compiler does indeed save, and restore, the register. You
>never skip the save and restore code.
>
In most assuredly, deed.
>
>No, the problem was this.
>
>
>About five calls in from the functions where the crash occurred (all small
>helper functions which didn't use all that many registers), there was a
>function which DID use that register. Thus, this function began with code to
>stash the values of all these registers on... dare I say it... the stack.
>Next to some automatic variables.
>
Horrors.
>
>And there is an idiom in this hunk of networking code of declaring an
>array:
>
>
> elaborate_type *stuff[FOO_MAX + 1];
>
>
>and in this copy of the code, it had been declared as:
>
>
> elaborate_type *stuff[FOO_MAX];
>
Oops.
>
>Well, there's a macro that calls an initializing routine which initializes
>entries 0 through FOO_MAX, inclusive. And this turns out to, on some but not
>all of the MIPS systems, overwrite the hunk of space where the saved register
>values are stored. And thus, when the register is restored, it's restored to
>0. None of the intervening functions use it, but when we finally get back to
>the previous function which was using it, the pointer's value has changed.
>
Alas, poor Yorick!
>
>Oops.
>
>
>The problem is, even though indeed this implementation has "a stack", if you
>adopt Schildt's model and description of what's happening, it makes it
>impossible to see the error.
> The value in question was not an argument to
>the function being called. It was not an automatic variable in that function.
>Nor was it an argument to, or an automatic variable in, the caller. That
>variable was not on "the stack" in terms of the abstract C machine, and
>all of Schildt's explanations of how you use the "stack" omit the possibility
>that, on some machines, you'll have registers which are not part of the
>calling convention, so functions which want to use them have to save them
>somewhere, and one of their options is to save these registers on the stack,
>right next to the stuff that everyone says is on the stack.
>
Nonsense on stilts, Socrates.
What you’re talking about happens to be a collision of the stack with
practices from the Ice Age which predated the stack, practices which
infected the C language, unfortunately, practices which do not show
intellectual superiority and are shibboleths.
These include the use of finite and hardened registers which remains a
necessity at the low level because the MIPS kiddies actually
rescusitated this US-centric praxis in 1987, claiming, without much
evidence, that it was “efficient” in a singularly sloppy use of
English.
And you are saying that by teaching the stack (which is good practice)
Herb FAILS to teach arcana, and makes the tyro incapable of also
thinking at the more primitive (not “better”) level of the single-
level register. Arguably, the student needs to think at both levels,
but the stack has priority because you can write slow OSen without
thinking in assembly language!
You are creating a class divide which I reject. You are saying that
bottom-feeding computer science *privat dozents* at DeVry and Borstal
may not speak of certain matters. This isn’t education. It is
Fascism.
All you need to do is have the tyro code, in CS 101, a Java or C Sharp
SIMULATOR for an stackless machine, and them make her eat her own dog
food: in CS 102, she has to program the simulated machine.
Peter, Alexander Pope was wrong, and New York feminist-conceptual
artist Jenny Holzer was right:
A LITTLE LEARNING GOES A LONG WAY
You’re here worse than student “Otto” who sits in the back of the
class with twenty years of assembler and no health insurance, soured
(in CS Lewis’ words) by true miseries, and maddened by false promises,
and decries C as a Communist plot.
You’re the plainclothes cop in the back of the class who in a police
state objects to the prof’s narrative because it didn’t mention the
leading role of the Party, or here, the holy, phallic register as
opposed to the stack.
I’m dead serious, Peter. The difficulty of programming creates
psychosexual noise even in the best brain, and the stack just bothered
people, being flexible and soft: whereas the registers are always
“there”, crystalline and hard.
>
>More significantly, if you were in the function where the register was
>originally used, it was an automatic variable which was NOT on the stack.
>
>
>If you come to a problem like this with a Schildt-based theory of what "the
>stack" is, and how things are pushed and popped on the stack, you will
>have no chance of guessing how something from five layers up the stack could
>end up adjacent to one of our newest automatic variables.
>
Schildt was describing the vast majority of cases for the vast
majority of programmers, who didn’t go down to Oxocantabridgia or
HarvardusPrinceurbsania to banter about the Higher Sodomy. No, they
went to Iraq for money for school, mate, and they aren’t going to be
programming any bare metal any time soon, they are going to maintain
applications. If they are not introduced to the stack, they won’t be
able to debug.
Is this what you want? Yet Another class divide to add to all the
lovely little barriers in the UK, the US, and even Yourup?
The stack is not your shibboleth, the stack is not your ear of corn.
It is not your Skull and Bones. It was developed by a large number of
intelligent working men and women simultaneously to solve problems and
stay employed, and the stack is the common treasury of humanity. For
shame!
>
>In short, he is not explaining how C works. He is explaining how a few
>specific C implementations worked on specific target platforms. Believing
>the things he says is misleading.
Only if you generalize. Use your common sense. People know that there
are different computer architectures. Learning is lifelong.
>
>
>Now, the above explanation is full of details about an implementation that
>you'd only likely know if you happened to have a fairly senior MIPS specialist
>on hand (hi, Ralf!). So the question is, if you didn't know any of this
>stuff, and just knew standard C, would you have a chance of catching it?
>
I just did, but perhaps because my first language was machine
language. But how do you suppose it was “caught” at its origin? This
stuff is not rocket science, although it’s hard. The fact is that
people “catch” it all the time.
Nobody is going to believe that Schildt is talking about ALL POSSIBLE
computers, nor do they seek to learn about ALL POSSIBLE computers. Use
your common sense and credit people with common sense, for the love of
Mike.
>
>Of course you would. It would be patently obvious (as it was the moment I
>found the right hunk of code) that the writes to the array exceeded the size
>of the array. That's "undefined behavior". You'll note that, in this case,
>"undefined behavior" didn't mean "crash right away" or "overwrite a value
>that's even got a name in scope in the current function" or anything like
>that; it meant that a local variable several function calls away might get
>overwritten, but whether or not this would happen would depend on compilation
>options used for code *nowhere near the bug*.
>
You fail to notice that to understand the advanced situation, your
auditor has to know about…stacks.
>
>Approaching this from a standard C perspective makes it easy to understand
>and fix the bug (but, I admit, doesn't help you at all in figuring out where
>to look). Approaching it from a platform-specific level with real
>understanding of the local ABI makes it possible to track down the bug.
>Approaching it from the perspective of someone who believes the stuff Schildt
>writes about "how C works", though, would make it impossible to diagnose;
>the behavior is simply too different from the model Schildt presents.
>
So, Schildt is not training rocket scientists (nor people who fancy
themselves rocket scientists). Well, whoop de doo.
Peter, you’ve failed to impress me.
In fact you’re beginning to depress me.
Our only point of possible agreement is that having trained people at
Princeton and having been a *privat dozent* at DeVry, I believe there
is a class divide in programming education, and I think it’s most
unfortunate. But Schildt didn’t create this class divide.
It is the height of absurdity to criticize Schildt for talking about
the stack without also talking about registers. It would make most
introductory computer science classes impossible. I can only conclude
that yes indeed, you, Mr. Seebach, believe that only certain social
classes should learn of Eleusinian mysteries, and that the rest of us
should not be permitted to read turbulent and damnable books above our
station.
No-one expects the Spanish Inquisition, Mr. Seebach. But after
Thatcher, Reagan, and the Bush-Clinton highjack of the public interest
for private gain, we’re seeing that reversion to barbarism can happen
pretty quickly. The trashing of Schildt was barbaric given the global
unsafety and global untruth of C.
>
>-s
>p.s.: In defense of the Linux kernel folks, it was our fault for merging
>an early version of a patch before it went into the mainline kernel; the
>version that actually went in upstream had the array declared correctly.
>--
>Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
>http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
spinoza1111
> On 2009-09-11,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > The controversy on Schildt's books here and on Amazon, Peter.
>
> I see no controversy.
I do.
>
> > I don't care. Wikipedia is a violation of tax law in that it was
> > founded for profit but portrays itself as nonprofit.
>
> Even assuming this were true, what do I care? I'm not the IRS.
If you're a United States citizen, you care. We pay more taxes because
Jimmy Wales doesn't pay the proper rate.
>
> > Its editors no
> > longer know subject matter and are thieves of intelllectual
> > production.
>
> You imply a time at which the wikipedia editors knew their subject matter?
Yes.
>
> Also, how are they "thieves"? I've never heard of them stealing anything.
> Being given is not the same as stealing.
They inveighle people to post and then drive them away. That's
stealing.
>
> >> In any event, who are these "other commentators"? How have they "found"
> >> this? Don't present the claim that someone somewhere said something --
> >> present the evidence itself.
> > A text is a text, not "evidence".
>
> Nonetheless, if you don't name the commentators and cite to when and where
> they said it, it's not a substantiated claim.
>
I'm saying it. Others are also saying it, on Amazon and clc. Navia has
recently said "it": your attack on Schildt was unwarranted.
> > At the time most of his audience needed him to focus on MS DOS and
> > Windows.
>
> No, they didn't.
>
> There is nothing that they needed to accomplish which was made better or
> easier by that choice, and a great deal that was made harder for them.
How would you know that? Most C programmers don't hack linux.
>
> > Peter, is this why you made trouble for him?
>
> No.
>
> I don't know, or care, whether I "made trouble" for him. He said things
> in print which were false. I corrected them. He did it a lot. I pointed
> out that it was a problem and that the books were not accurate sources.
You acted in ignorance of how to write a book review. You knew your
technical claims were for the most part Scholastic marginalia,
therefore you made your text an attack on Schildt and not on his
ideas.
You need to read Dijkstra's collected works. Dijsktra hardly ever
referred to people who he felt were wrong by name. Instead, he
accurately described what he considered to be incorrect ideas and then
constructively presented his own ideas as an alternative.
But you never formed a unified theory as to why Schildt was incorrect.
That is probably because Schildt was not systematically incorrect, and
Schildt does not have a wrong theory of computer science. Schildt,
having written a small C interpreter, educated himself in the basics
and he realized that (1) a language that forbids recursion is dead on
arrival since there's no way of preventing accidental indirect
recursion, therefore (2) we must support recursion, therefore (3)
while registers are a frill, the introductory C student must learn
about stacks.
For this reason, your attack is a laundry list of "points" which don't
even add up to errata since so many of them are hermeneutic. That's
why McGraw Hill is ignoring you.
My favorite "theory" is that Schildt showed up at an early meeting and
took your girlfriend away. I have no other way of explaining your
unprofessional conduct in making the issue "Schildt" and not a
systematic bad practice.
Is it systematic bad practice to use Microsoft platforms? Then say so,
and explain why.
>
> Given that, according to Wikipedia, his books have been bestsellers for
> three decades, I don't really see any evidence that he's been noticably
> harmed.
He and his family have been exposed to emotional distress. When I
first published on computer science (a 1975 article in Computerworld
on "Virtually Structured Programming", my wife was dismayed by the
tone of the letters the following week. I wasn't because I have brass
balls, but brass balls need not be a prerequisite for publishing a
book.
[Edward Yourdon had written in to say I was wrong to say that you
could "virtually" simulate structured programming in old Cobol and
assembler by using go to in a pattern. I was right and Yourdon,
wrong.]
>
> > Because I was
> > well acquainted with anti-IBM snobbery in the past, and anti-Microsoft
> > snobbery in the present. I have no problem with pointing out the
> > defects of IBM and Microsoft software and hardware: expert IBM and
> > Microsoft people are very familiar with them: but your campaign
> > marshaled ignorance in my view.
>
> "Campaign"?
>
> Dude. I wrote a single web page on the topic, which took me probably an
> hour. I posted it on my web site. I pretty much forgot about it. I think
> I exchanged a couple of emails with people at his publisher, decided that
> their attitude did not suggest that they were seriously interested in
> correcting the defects, and... Honestly, I don't think I've done anything
> else on the topic until the last couple of months. Someone contacted me
> earlier this summer to ask some questions about one of my specific criticisms.
> I've gotten a couple of messages about it, which I've responded to. I saw
> your post here (it'd be hard for me to miss it!) and thought I'd comment.
>
Dude. You enabled a ten year slow burning firestorm which has harmed
Schildt because posters in clc are constantly making reference to the
issue, and because unlike Dijkstra you are unable to theorize and keep
personalities out of theory, you have created an electronic shadow
over Schildt's good name.
> This is not exactly a "campaign". I've put more time and effort in any given
> week of the last decade into playing video games than I have put into thinking
> about or writing about Schildt in that whole decade.
>
> >> Well, how they work sometimes.
> > And why (the stack narrative being essential in explanation).
>
> Well, hang on.
>
> Given the existence of stackless implementations, how is that narrative
> "essential"? Can you get more concrete here, and show us something which
> can be explained through the "stack" narrative, and which is "essential"?
THERE ARE NO STACKLESS IMPLEMENTATIONS OF THE C RUNTIME THAT ARE
CORRECT. Cf. Michael L Scott, Programming Language Pragmatics, on this
matter: find "stack" in the index and do your homework. If your
standard was intended to make broken compilers and broken runtimes
"standard" therefore in the popular mind somehow "correct", this was a
serious misuse of public funds.
>
> The word "essential" implies that, without a given thing, something can't
> be accomplished. Do you suggest that it is *impossible* to explain C
> without talking about stacks, even though real C implementations exist
> which don't use them? (I already provided a detailed example of a case
> where, even though there WAS a stack, the "stack narrative" would make
> it virtually impossible to comprehend the failure of a given program.)
THERE ARE NO CORRECT STACKLESS IMPLEMENTATIONS OF THE C RUNTIME. Your
example used a stack! The issue of whether we should use the stack as
a narrative is separate, and if you claim we may not, then talk to
almost any hard-working comp sci professor.
>
> > That's because complementarily to your mathematical and scientific
> > intelligence, you have failed to see a textual isomorphism between
> > religious fundamentalism and your technical fundamentalism.
>
> Why, yes. Yes, I have failed to see it. One solution for this would be
> for you to offer more detailed explanations of where you feel this
> relationship exists.
Galileo and Spinoza were attacked by people who felt themselves to be
scientists. The attacks on them originated not from crowds of peasants
with pitchforks and torches but from people who felt themselves the
enlightened elite, whose own theories had a great deal of academic
respectability in their day. In this connection, you need to read the
chapter on "New Learning and New Ignorance" in CS Lewis' History of
English Literature (16 century). You need also to read The Columbia
History of Western Philosophy which gives "equal time" to the men of
the 17th century who felt Spinoza to be an upstart.
A grammatical analysis of the transformation between the way Dijkstra
(and other men of his generation) talked about opposing views, and
today, finds that at the time of Algol 60, they were able to stay away
from even using the proper names of others while discussing nascent
computer science.
Then, if you do comparative religion, you find the early Christians
and early Buddhists concerned with the new message and loth to
separate themselves into sects named after leaders.
Then, as the religion becomes integrated with the world, the flesh and
the devil (as was the case in Rome after Constantine and Arabia a
generation or so after the death of Mohammed) personalities arise who,
struggling for dominance, name heresies after people: Arianism, the
followers of Ali, and so on.
You cannot read this tragic record and see it operate in culture today
in a variety of ways. So read it.
>
> >> Lemme be blunt, though: I don't even remember most of this stuff. I
> >> think it's been ten years since I last looked at the Schildt books. I
> >> remember being utterly gobsmacked to find an example using <> instead
> >> of != in a book nominally about C, so I went and grabbed the book,
> > Sounds like a trivial reason to be gobsmacked.
>
> Really?
>
> There has never been, to the best of my knowledge, any C-like language with
> that operator in it. I didn't even realize what it was until someone who
> used to use Pascal told me it was used for != in some variants of Pascal.
>
> It's not a mistake I can make sense of. There's nothing it could be a
> typo for, there's nothing it could have meant -- it's just a bit of Pascal
> code inexplicably inserted into a code sample.
>
I've used it, most recently in Visual Basic. Its meaning should be
obvious. I don't see why you had a problem. You need a little urbanity
IMO.
> > This is the reality for programmers (especially minority and female
> > programmers).
>
> Is it? Do you have some kind of data supporting this theory?
I do. The New York Times did a follow up study on female computer
scientists who'd graduated from Princeton circa 1989 to find they'd
left the field or been driven away because this war against
personality is more readily turned against females owing to the
psychosexual complexes of many male techies: most tragically in the
case of Java author Kathy Sierra.
I also have life experience in counseling female programmers who as
supervisors enforced good practice only to be told that they were
"wasting time" in doing so by reduced instruction set kiddies.
>
> > A number of people at clc have conceded this, litera scripta manet.
>
> Again, vague assertions like this buy you nothing. You might as well
> just say "the lurkers support me in email!" or go whole hog and post
> under the name "Socky McSockington" and say "Me Too!" a lot.
>
Richard Heathfield has conceded it. This was a startling admission
from someone who supports it.
> >> Sadly, Usenet is a text-only medium, but what I clearly need here is a
> >> picture of a giant temple in Cambodia, captioned "WAT?"
> > Nixon invaded Cambodia while I was discovering that IBM refused to fix
> > a broken Fortran compiler that we needed in my computer science class.
>
> Uh, huh?
>
> > Middle class white students at the Univ of Chicago had no such
> > problem, and I fixed the compiler a year later in machine language and
> > made it available to students. I can connect. Can you, Peter?
>
> I don't even know what you mean by "connect" in this context.
Well, I rest my case.
>
> >> As it happens, I was an active participant in the C committee during the
> >> C99 era. I did this on my own dime; the extent of support I received from
> >> my employer (BSDi, at first, later Wind River) was that they counted only
> >> half the time I spent at meetings as vacation, making it possible for me to
> >> attend meetings.
> > You should have negotiated a better deal.
>
> Impressive! It barely took you a page to go straight from talking about how
> I have it easy compared to other programmers, to how the corporation screwed
> me.
Thank you.
Pretty cool, I agree
Hey Peter learn from me.
>
> > As employed compiler developers, I am certain they were. I was
> > likewise enthusiastic as a compiler developer. The problem is that
> > there's a sharp separation between people's roles as compiler
> > developers paid to actually feel enthusiastic and those people years
> > later, homeless or without medical insurance owing to the lack of
> > interest in actually fixing C as opposed to standardizing mistakes on
> > behalf of their former employers.
>
> Well, that's a pretty huge and sweeping claim. The industry has been
> remade a couple of times, multiple new languages and ways of approaching
> programming have come along and gained widespread usage, often replacing
> things that used to be done in C, but you think that it's unspecified
> flaws in standardization, rather than marketplace shifts, that are at
> fault in the relatively smaller number of active C compiler developers.
>
> That's fascinating, and by fascinating, I mean it sounds borderline
> schizophrenic.
When you haven't done your homework, try Soviet psychiatry.
Unfortunately for you, I assisted a former schizophrenic with C, and
he went on to win the Nobel prize. For this reason, I find that you
use that label without compassion, because it's a still fashionable
way of not doing your homework, as "half-Jew" is no longer.
>
> >> In fact, the bulk of the "undefined behavior" cases are there, not so that
> >> compiler writers can do LESS work, but so that they can do MORE work -- such
> >> as aggressive optimizations.
> > ...at the cost of making C comprehensible in the vast majority of
> > cases.
>
> Why, yes. When the time came that we had to consider whether or not to
> make C comprehensible in the vast majority of cases, we said "damn the
> torpedoes! We will make C comprehensible." So we did. And as you say,
> C is indeed comprehensible in the vast majority of cases.
No, that was Schildt who did that.
>
> It was a very very small price to pay, for huge benefits, but I think it
> was worth it.
>
> Hint: C is in no way "incomprehensible".
Oh? And why is it that there are no answers to common questions about
C?
>
> >> He was a representative of someone who wrote books about issues he knew
> >> nothing about. (Not that I can claim that there's no errors in my books;
> > Up to this point ("knew nothing about") you sound sensible. But as in
> > the case of Clive Feather, you make global/null claims about him. And
> > then you start in on him, and you appear at that point to have an
> > unhealthy obsession.
>
> Welcome to conversational English, where "know nothing about" is hyperbole
> and means "not know very much about".
This is a written record, not a conversation. And in a conversation
with Schildt, it would be boorish to use such hyperbole.
>
> > You concede this. But you seem to assume that you should be forgiven
> > for errors, whereas the Outsider may not.
>
> I do not recognize the category of "outsider"; it is foreign to my view
> of humanity.
>
> I don't think "forgiving" or "not forgiving" for errors is a coherent concept.
> Errors are corrected or not-corrected. I don't care who made them, when, or
> how; just whether things are fixed.
>
> I disrecommended Schildt's book because the frequency and quality of the
> errors was such as to suggest fundamental problems with understanding C,
> and people who "learned C" from his books consistently ended up with
> severe difficulty understanding the language as it existed outside a small
> subset of implementations.
This is because C was and is a mess, and your standard did nothing
about it's being a mess.
>
> > But when we investigate what's wrong, we find trivia, MS-DOS v unix
> > differences, and style.
>
> Actually, no. We find substantive errors that point to a genuine
> misunderstanding of the nature of C.
What are those? Hint: using a stack to explain runtime behavior is NOT
a substantive error.
>
> You might think that, if he'd claimed to be writing only about "C for MS-DOS",
> the complaints would be mostly resolved, but in fact, many serious complaints
> would survive, because even within that environment, many of his
> "explanations" are simply incorrect.
>
> >> > Seebach and Feather have not only gone after Schildt. They also
> >> > continue to savage professional reputations whenever their standard is
> >> > questioned.
>
> >> Er, we have?
>
> > Yes, in clc.
>
> I haven't posted in clc for years -- I only started reading it again the other
> day.
>
> But you have made an exceptional claim here; you have claimed first that we
> "savage professional reputations" -- a pretty high
Yes, you do, because in failing to write theoretically, and by naming
Schildt, you have created a destructive mess.
>
> read more »...
Seebs
> programming, after thirty years, I teach English and creative writing
> in addition to intro computer science. I have learned that intolerant
> students, who believe words are things, make the slowest progress.
Well, they make the slowest progress when you teach them. If you actually
teach them. If any of what you're saying is true.
> Therefore, I will be the judge as to whether a text has ?intrinsic
> worth?.
This is a non-sequitur. You have not offered a qualification to judge,
and if anything, you've offered a sort of non-qualification.
> Welcome to the weird and wonderful world of C. This is why we have
> Java, isn?t it.
Nope. Java wouldn't do us any good here.
> Nonsense on stilts, Socrates.
Uh, no. Simple fact.
> What you?re talking about happens to be a collision of the stack with
> practices from the Ice Age which predated the stack, practices which
> infected the C language, unfortunately, practices which do not show
> intellectual superiority and are shibboleths.
I made no claims about "intellectual superiority".
I claimed a *reality* -- on real machines, with real compilers, believing
Schildt's crap would leave you unable to comprehend or debug a problem which
really occurred.
> These include the use of finite and hardened registers which remains a
> necessity at the low level because the MIPS kiddies actually
> rescusitated this US-centric praxis in 1987, claiming, without much
> evidence, that it was ?efficient? in a singularly sloppy use of
> English.
When you can make a CPU do more work in less time on less power, please
let us know.
> And you are saying that by teaching the stack (which is good practice)
You keep asserting that this is "good practice", but I've just demonstrated
that it's genuinely harmful.
> Herb FAILS to teach arcana, and makes the tyro incapable of also
> thinking at the more primitive (not ?better?) level of the single-
> level register. Arguably, the student needs to think at both levels,
> but the stack has priority because you can write slow OSen without
> thinking in assembly language!
The student does not need to learn to think at either, but if you're going
to start thinking about how things "really work", it's crucial to think about
how actual machines work rather than about how Schildt thought some DOS box
worked.
> You are creating a class divide which I reject.
No, I am pointing out reality. Which you reject.
> You are saying that
> bottom-feeding computer science *privat dozents* at DeVry and Borstal
> may not speak of certain matters.
No, I'm not. I've merely said that people who make false claims are not
making true claims, and aren't going to get anywhere.
> You?re here worse than student ?Otto? who sits in the back of the
> class with twenty years of assembler and no health insurance,
Okay, so.
Basically, you have some kind of issue, totally unrelated to C, involving
health insurance and job security.
And in your mind this is all connected into one vast whole. But because
the connections occurred in a non-analytical part of your brain, you can't
tell anyone what they are, or show them to anyone, or offer any kind of
evidence for them.
> I?m dead serious, Peter. The difficulty of programming creates
> psychosexual noise even in the best brain, and the stack just bothered
> people, being flexible and soft: whereas the registers are always
> ?there?, crystalline and hard.
If you're dead serious, you are schizophrenic. Not joking, not insulting,
just telling you what is fairly obvious to anyone with access to relevant
texts.
You emit "word salad" -- strings of words which aren't always even
grammatical. You experience huge and elaborate conspiracies which are
so crystal clear to you that you can't even comprehend people not being
aware of them. Every literary reference, every cultural reference, every
experience, is somehow tied to all the others by relationships which don't
exist in normal brains.
> Schildt was describing the vast majority of cases for the vast
> majority of programmers,
Even if true, so what? He described them incorrectly; even on x86, his
description of how things work is only true some of the time.
> who didn?t go down to Oxocantabridgia or
> HarvardusPrinceurbsania to banter about the Higher Sodomy. No, they
> went to Iraq for money for school, mate, and they aren?t going to be
> programming any bare metal any time soon, they are going to maintain
> applications. If they are not introduced to the stack, they won?t be
> able to debug.
This is simply untrue.
> Only if you generalize. Use your common sense. People know that there
> are different computer architectures. Learning is lifelong.
Well, that's the thing.
People who didn't read Schildt know that there are different computer
architectures. People who are steeped in Schildt's madness frequently
come out of it convinced that he actually described "how computers work"
rather than giving a specific example of one common implementation, and
are thereby gravely disadvantaged when they come to other systems.
In short, yes, there is a real risk of creating a class of disadvantaged
programmers who can't compete effectively or adapt to new environments.
That risk is Schildt's books.
> Nobody is going to believe that Schildt is talking about ALL POSSIBLE
> computers, nor do they seek to learn about ALL POSSIBLE computers. Use
> your common sense and credit people with common sense, for the love of
> Mike.
I have been reading Usenet far too long to credit people with common
sense.
> You fail to notice that to understand the advanced situation, your
> auditor has to know about?stacks.
But not about the things Schildt describes as "how the stack works".
> So, Schildt is not training rocket scientists (nor people who fancy
> themselves rocket scientists). Well, whoop de doo.
Not just that. Schildt is teaching people falsehoods, which will make
it harder for them to learn what they need to know to do their jobs.
> Our only point of possible agreement is that having trained people at
> Princeton and having been a *privat dozent* at DeVry, I believe there
> is a class divide in programming education, and I think it?s most
> unfortunate. But Schildt didn?t create this class divide.
He's certainly making it worse.
> It is the height of absurdity to criticize Schildt for talking about
> the stack without also talking about registers.
I didn't.
I merely pointed out that his strategy demonstrably renders people unprepared
to deal with real-world systems.
A more effective solution, by far, is to teach C without trying to explain
how it "really works" as though there were a simple answer, then get into the
details of implementations in more advanced courses. That works beautifully.
> It would make most
> introductory computer science classes impossible. I can only conclude
> that yes indeed, you, Mr. Seebach, believe that only certain social
> classes should learn of Eleusinian mysteries, and that the rest of us
> should not be permitted to read turbulent and damnable books above our
> station.
That would be an exceptionally stupid conclusion. I think everyone should
be allowed to read everything -- but that "everything" includes clear warnings
about significant errors in technical books.
> No-one expects the Spanish Inquisition, Mr. Seebach. But after
> Thatcher, Reagan, and the Bush-Clinton highjack of the public interest
> for private gain, we?re seeing that reversion to barbarism can happen
> pretty quickly. The trashing of Schildt was barbaric given the global
> unsafety and global untruth of C.
Again, here's where you get off into schizophrenia land. You're wandering
off into unrelated politics, and come *ON*, the phrase "untruth of C" is
just plain crazy talk.
If you've got meds, go back on 'em. If you don't, see a doctor.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
>> On 2009-09-11,spinoza1111<spinoza1...@yahoo.com> wrote:
>>
>> > The controversy on Schildt's books here and on Amazon, Peter.
>>
>> I see no controversy.
> I do.
That's nice for you. Until you show any kind of "controversy" beyond the
level of the FIERCE debate we currently see over the errors of heliocentrism,
there is no reason for anyone else to think that the alleged controversy
exists.
>> > I don't care. Wikipedia is a violation of tax law in that it was
>> > founded for profit but portrays itself as nonprofit.
>>
>> Even assuming this were true, what do I care? I'm not the IRS.
>
> If you're a United States citizen, you care. We pay more taxes because
> Jimmy Wales doesn't pay the proper rate.
Ahh, but you're missing the point.
Even granting that, it's a total non-sequitur. It has nothing to do with
any of the substantive issues at hand. If you want to argue corporate
governance and structure, there's newsgroups about that too.
>> You imply a time at which the wikipedia editors knew their subject matter?
> Yes.
Okay, now I *knoww* you're crazy.
>> Also, how are they "thieves"? I've never heard of them stealing anything.
>> Being given is not the same as stealing.
> They inveighle people to post and then drive them away. That's
> stealing.
Uh, no, it isn't.
> I'm saying it. Others are also saying it, on Amazon and clc. Navia has
> recently said "it": your attack on Schildt was unwarranted.
If you and Navia are saying I'm doing something wrong, I think I'm going
to have to take that as complimentary.
>> There is nothing that they needed to accomplish which was made better or
>> easier by that choice, and a great deal that was made harder for them.
> How would you know that? Most C programmers don't hack linux.
Indeed. Nor did I until fairly recently. But I've gone through half a dozen
operating systems on at least five substantially different architectures, and
on every one of them, I've consistently found that the nonsense Schildt tried
to push would be fundamentally harmful to trying to use C effectively.
> You acted in ignorance of how to write a book review.
I never claimed to be writing a book review.
> You knew your
> technical claims were for the most part Scholastic marginalia,
Actually, no. I knew nothing of the sort. Now, years later, with a much
better sense of what's important and what's unimportant, I might drop a couple
of them as not worth commenting on...
On the other hand, I'd do something more than "open the book to a random page
and write about what I see, then do it again."
> But you never formed a unified theory as to why Schildt was incorrect.
I don't think a unified theory as to why someone is incorrect is needed.
Errors could occur in isolation. That said, looking at the overall pattern,
I'd say he was systematically incorrect because he generalized quickly from
insufficient data points and didn't check his results carefully.
> That is probably because Schildt was not systematically incorrect,
Yes he was.
> and Schildt does not have a wrong theory of computer science.
I have no idea how to confirm or refute such a claim.
> Schildt,
> having written a small C interpreter, educated himself in the basics
> and he realized that (1) a language that forbids recursion is dead on
> arrival since there's no way of preventing accidental indirect
> recursion, therefore (2) we must support recursion, therefore (3)
> while registers are a frill, the introductory C student must learn
> about stacks.
That's a fascinating theory, but I don't see any evidence. Care to show
your sources on how you determined what he thought?
> For this reason, your attack is a laundry list of "points" which don't
> even add up to errata since so many of them are hermeneutic. That's
> why McGraw Hill is ignoring you.
I would guess it more likely that it was because this was 1996 or so, when
I was some random kid with no formal credentials. Just guessing. Even so,
they did offer me money to do a technical review; it was just way, way,
too little for the amount of work.
> My favorite "theory" is that Schildt showed up at an early meeting and
> took your girlfriend away.
Uh.
To the best of my knowledge, Schildt has never been to any ISO committee
meetings. For that matter, there has been no time when I was going to
those meetings and had a girlfriend. :)
> I have no other way of explaining your
> unprofessional conduct in making the issue "Schildt" and not a
> systematic bad practice.
I didn't make the issue "Schildt". I commented about two specific books.
I have never seen his other books. I have no reason to speculate as to
whether they're good or bad.
> Is it systematic bad practice to use Microsoft platforms? Then say so,
> and explain why.
I see no relevance. Microsoft platforms aren't the issue. Not knowing
a language well and writing about it is.
> He and his family have been exposed to emotional distress.
I have no information to support this hypothesis. I did receive a forwarded
fax from McGraw Hill on the topic, which led me to conclude that he was
invincibly ignorant and extremely unlikely to experience emotional distress.
> [Edward Yourdon had written in to say I was wrong to say that you
> could "virtually" simulate structured programming in old Cobol and
> assembler by using go to in a pattern. I was right and Yourdon,
> wrong.]
Given your track record of claiming to be right, I suspect that you not
only were wrong, but still are. Of course, the term "virtually" is
pretty much useless.
> Dude. You enabled a ten year slow burning firestorm which has harmed
> Schildt because posters in clc are constantly making reference to the
> issue, and because unlike Dijkstra you are unable to theorize and keep
> personalities out of theory, you have created an electronic shadow
> over Schildt's good name.
Even if we grant that this were true, it's not a "campaign"; it's a side
effect which occurred without any awareness on my part.
I am certainly able to theorize and keep personalities out of theory.
However, it does a novice programmer very little good to be told "there
exists at least one book which, if you read it, will make it harder for
you to get good at C. Good luck!"
Novice programmers benefit from specific, concrete, recommendations.
> THERE ARE NO STACKLESS IMPLEMENTATIONS OF THE C RUNTIME THAT ARE
> CORRECT.
Nonsense. It's fairly trivial to do one.
You can't do one which doesn't have some functionality comparable to
what is done using a "stack" on some systems, but there's no need for it
to be a stack as such.
... And actually, I'm not totally sure of this, because I think you
can make it work using an elaborate arrangement of preallocated calling
frames.
> Cf. Michael L Scott, Programming Language Pragmatics, on this
> matter: find "stack" in the index and do your homework. If your
> standard was intended to make broken compilers and broken runtimes
> "standard" therefore in the popular mind somehow "correct", this was a
> serious misuse of public funds.
Actually, it wasn't -- committee memberships cost money which covers (by
and large) the costs of the process.
> THERE ARE NO CORRECT STACKLESS IMPLEMENTATIONS OF THE C RUNTIME.
Well, I've talked to people who have used C on a machine with no stack, so I
guess I believe them more than I believe you.
> Your
> example used a stack! The issue of whether we should use the stack as
> a narrative is separate, and if you claim we may not, then talk to
> almost any hard-working comp sci professor.
I was raised by one, thanks. Sorta already did.
> Galileo and Spinoza were attacked by people who felt themselves to be
> scientists.
And you're back into long unrelated rambling story mode.
> A grammatical analysis of the transformation between the way Dijkstra
> (and other men of his generation) talked about opposing views, and
> today, finds that at the time of Algol 60, they were able to stay away
> from even using the proper names of others while discussing nascent
> computer science.
Again, long unrelated story.
> Then, if you do comparative religion, you find the early Christians
> and early Buddhists concerned with the new message and loth to
> separate themselves into sects named after leaders.
Uh-huh.
So.
Maybe, instead of obsessing over Schildt, Schildt, Schildt, you should start
writing and talking about C and what you think it should be like. Instead of
ranting about "Seebach" and "Feather" and "Schildt", just write about how you
feel the narrative of the stack is important for teaching C, and we'll argue
with you if we think you're wrong.
If you don't think it should be all about names, then maybe the thing to do
would not be to actively drag names into it constantly.
>> It's not a mistake I can make sense of. There's nothing it could be a
>> typo for, there's nothing it could have meant -- it's just a bit of Pascal
>> code inexplicably inserted into a code sample.
> I've used it, most recently in Visual Basic. Its meaning should be
> obvious.
Maybe it should, but it's not totally obvious; if I'd had to guess, I would
have guessed it was a spaceship operator (ala perl and ruby).
> I don't see why you had a problem.
Because I thought it was a book about C, and it had a thing in it which
could not possibly have ever been submitted to a C compiler, and which no
C programmer would ever have written.
> I do. The New York Times did a follow up study on female computer
> scientists who'd graduated from Princeton circa 1989 to find they'd
> left the field or been driven away because this war against
> personality is more readily turned against females owing to the
> psychosexual complexes of many male techies: most tragically in the
> case of Java author Kathy Sierra.
This is an interesting theory, but I'm not sure I buy your interpretation.
> I also have life experience in counseling female programmers
Yes, but you're batshit insane. I would like sources that don't
emit word salad.
> who as
> supervisors enforced good practice only to be told that they were
> "wasting time" in doing so by reduced instruction set kiddies.
See, this is the kind of thing that makes me think you're a loony.
"reduced instruction set kiddies"?
> Richard Heathfield has conceded it. This was a startling admission
> from someone who supports it.
I don't see why.
I have posted an explanation of why I don't think C99 has attained the
commercial traction C89 did, and I think it's pretty much obvious that
this explanation is both necessarily true and sufficient.
>> I don't even know what you mean by "connect" in this context.
> Well, I rest my case.
Traditionally, one first makes a case, *then* rests it.
> Pretty cool, I agree
> Hey Peter learn from me.
You know, maybe I should. I once had a dream of being voted Usenet Kook
of the Month, but I could never manage the kind of complete self-contradiction
it takes.
> Unfortunately for you, I assisted a former schizophrenic with C, and
> he went on to win the Nobel prize. For this reason, I find that you
> use that label without compassion, because it's a still fashionable
> way of not doing your homework, as "half-Jew" is no longer.
Er, what?
Again, you're using references that aren't connected to what you're talking
about except in your mind.
>> Why, yes. When the time came that we had to consider whether or not to
>> make C comprehensible in the vast majority of cases, we said "damn the
>> torpedoes! We will make C comprehensible." So we did. And as you say,
>> C is indeed comprehensible in the vast majority of cases.
> No, that was Schildt who did that.
Well, no.
As you said, the language is what it is because of the committee these days,
and yes, we made it comprehensible. That Schildt was unable to comprehend
it even after it got cleaned up and made much simpler to understand and work
with is, perhaps, a genuine issue of note.
> Oh? And why is it that there are no answers to common questions about
> C?
A very good question!
Probably for the same reason that there are no answers to common questions
in a whole lot of fields -- because people ask questions that have no
meaningful answers. (What's the Chinese word for "no"?)
Let's try a nice, simple, question.
How many watts of power does a computer use?
Please give a specific answer.
Can't do it? Hmm. Does this mean that:
1. Power supplies are incomprehensible.
2. There is more than one power supply, and they have different traits.
> This is a written record, not a conversation.
It's Usenet. I'm writing conversationally. This isn't a written record;
if you want to create a written record, go bug my lawyer.
> And in a conversation
> with Schildt, it would be boorish to use such hyperbole.
Perhaps it would, but:
1. So what? I'm boorish.
2. I'm not in a conversation with Schildt.
>> I disrecommended Schildt's book because the frequency and quality of the
>> errors was such as to suggest fundamental problems with understanding C,
>> and people who "learned C" from his books consistently ended up with
>> severe difficulty understanding the language as it existed outside a small
>> subset of implementations.
> This is because C was and is a mess,
Not really. If that were true cause and effect, then the effect would follow
from the cause -- and, the C language being fairly similar, other people would
be just as unable to write books which did not make it harder rather than
easier for their readers to program effectively in C.
But, in fact, we find that there are a number of authors who have done a
wonderful job writing clearly and effectively about C.
> and your standard did nothing
> about it's being a mess.
Obviously untrue -- look at the massive and rapid adoption of C89. The
language was admittedly a "mess" before that, in that there were no clear
boundaries of what would be the same everywhere and what would reflect
the nature of specific environments.
>> Actually, no. We find substantive errors that point to a genuine
>> misunderstanding of the nature of C.
> What are those? Hint: using a stack to explain runtime behavior is NOT
> a substantive error.
Well, it is, but let's pretend for the sake of argument it isn't.
/* Write 6 integers to a disk file. */
void put_rec(int rec[6], FILE *fp)
{
int len;
len = fwrite(rec, sizeof rec, 1, fp);
if (len != 1) printf("write error");
}
Let's see how many things this gets wrong.
Let's start with plain errors. In C, since the very dawn of the language,
arguments declared in array form were actually pointers. Thus, "sizeof rec"
is "sizeof(int *)" rather than "sizeof(int [6])". Unless pointers happen
to be precisely six times the size of int, this program does not, in fact,
write six integers to the file.
But, there's more.
The reason fwrite takes both a size and a count is so you can tell it how
many objects of what size you're writing, and it can tell you how many of
them it successfully wrote. So the choice of count is almost certainly wrong.
The printf statement here has two stylistic flaws, one serious enough
that I would consider it a definite bug. The first is that it ought to
be a write to standard error, but let's let that pass. The second, and
more significant, is the lack of a terminating newline. That's virtually
guaranteed to produce unreadable output.
Finally, we have a very good example here of completely unconsidered poor
design. Imagine that you are working on a program, and you wish to call
put_rec. How, pray tell, do you determine whether it succeeded? Why,
of course! After each call to put_rec(), you print the prompt: "\nDid the
message 'write error' just appear?\n", read input, and check to see whether
the user observed the message.
Most of these are not necessarily barriers to an effective teaching exercise,
but they are the sort of habitually bad style that suggest someone who hasn't
quite gotten the hang of the language. However, the sizeof error is a
serious, fundamental, failure to understand the language. If you can't tell
pointers from arrays in C, you don't know C.
> Yes, you do, because in failing to write theoretically, and by naming
> Schildt, you have created a destructive mess.
Not noticably. However, even if we imagine that Schildt's professional
reputation had been harmed... "reputations" is a plural. Whose professional
reputation has been "savaged"?
(Also, you might find it rewarding to click on that "read more" link to get
the full text of posts you're responding to.)
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Dag-Erling Smørgrav
> If you investigate the disorganized "laundry lists" of charges put out
> by Seebach and Feather, you discover that Schildt was libeled.
It's not libel if it's true or the person who made the statement
had a "reasonable belief" that it was so.
Don't you have anything better to do?
DES
--
Dag-Erling Smørgrav - d...@des.no
spinoza1111
> > THERE ARE NO STACKLESS IMPLEMENTATIONS OF THE C RUNTIME THAT ARE
> > CORRECT.
>
> Nonsense. It's fairly trivial to do one.
>
> You can't do one which doesn't have some functionality comparable to
> what is done using a "stack" on some systems, but there's no need for it
> to be a stack as such.
>
you to say, because it is ex cathedra and a misuse of your technical
authority.
The functionality IS the stack, and I really, really hope you know
this. The runtime behavior of a normal C program must be explained by
using the stack as an abstraction, because as soon as one procedure
can have > 1 activations, it needs > 1 activation records holding its
parameters, its local variables, and the return address. There is no
way to store and retrieve these activation records which does not
involve stack "like" mechanisms: the stack is provably the minimal
amount of mechanism needed.
As soon as you write
For 1 (or 2), N factorial is 1 (or 2): for n, n factorial is n*(the
factorial of n-1)
you have a function which can only be calculated by something that
uses a stack. If it uses an array, all it needs to do is access the
beginning or end of the array, aka the top of the stack.
Therefore, once recursive call exists, the stack exists. An
"intuitionist" mathematician knows this: a "Platonist" realizes it a
few minutes later.
Peter, I regard you as "elite" wrt computer science: but from this
comment you make alone, I see you are like the ruling class which is
willing to destroy American industry to preserve the profits of a
view, because you are willing to destroy knowledge and memory merely
to be right, and preserve a standard designed primarily to protect
profits.
I'd also warn you that I'd never heard of your famous "sequence
points" prior to the standards push of the 1990s, and I am confirming
a little theory that I have: that you invented this claptrap to make
optimizing, but incorrect, compilers, correct. K & R designed C at a
time when it was not known how important it was to specify the
sequence of arithmetic and logical operators, but common C compilers
prior to your broken standard evaluated left to right with no
nonsense, and did not try to over-optimize such a profoundly unsafe
language.
More on your other points when I have more time. Meanwhile:
If the stack is something you lack
You'd better watch your back.
tohava
> guess I believe them more than I believe you.
Can you give any links where I can read more about such
implementations of C, I am intrigued by how they are done.
Part of what I am curious about is, when you say "no stack", do you
mean hardware support for a stack? Or no use of a stack-like data
structure?
(Please note, I do not want to take part in this flame war thingy, I
am asking this just out of curiosity)
Seebs
> you to say, because it is ex cathedra and a misuse of your technical
> authority.
Fascinating assertion.
> The functionality IS the stack, and I really, really hope you know
> this.
Well, now I know how you are using the word.
However, what Schildt described was not an abstract stack, but a specific
layout in which the stack and heap were separate and non-overlapping regions
of memory, such that no address of any "heap" object is between any two
"stack" objects, and vice versa.
> The runtime behavior of a normal C program must be explained by
> using the stack as an abstraction, because as soon as one procedure
> can have > 1 activations, it needs > 1 activation records holding its
> parameters, its local variables, and the return address. There is no
> way to store and retrieve these activation records which does not
> involve stack "like" mechanisms: the stack is provably the minimal
> amount of mechanism needed.
Absolutely correct!
... But "minimal amount of mechanism" is not the same as "how it really
works".
> As soon as you write
>
> For 1 (or 2), N factorial is 1 (or 2): for n, n factorial is n*(the
> factorial of n-1)
>
> you have a function which can only be calculated by something that
> uses a stack. If it uses an array, all it needs to do is access the
> beginning or end of the array, aka the top of the stack.
This is a fascinating assertion, but not true -- many compilers will
implement this function without recursion.
> Therefore, once recursive call exists, the stack exists. An
> "intuitionist" mathematician knows this: a "Platonist" realizes it a
> few minutes later.
No.
Again, "the stack" is not an abstract concept, but a specific region of
storage allocated in a particular way. If Schildt had said "a useful way
to think about automatic variable allocation is...", I probably wouldn't
be complaining; it *is* a useful way to think about automatic variable
allocation.
But what he claimed was that there existed a memory layout, and that all
automatic variables were allocated in a specific region of memory, and that
all heap variables were allocated in another, and this is not true,
and believing it is misleading.
> Peter, I regard you as "elite" wrt computer science: but from this
> comment you make alone, I see you are like the ruling class which is
> willing to destroy American industry to preserve the profits of a
> view, because you are willing to destroy knowledge and memory merely
> to be right, and preserve a standard designed primarily to protect
> profits.
I regard you as schizophrenic. There is simply no evidence or data to
support the contention that the standard was designed "to protect profits".
Indeed, as pointed out with concrete examples, the standard was designed
in a way which is extremely unlikely to achieve your described theory of
how companies were trying to protect profits.
> I'd also warn you that I'd never heard of your famous "sequence
> points" prior to the standards push of the 1990s, and I am confirming
> a little theory that I have: that you invented this claptrap to make
> optimizing, but incorrect, compilers, correct.
Again, I wasn't involved in any of this, but I don't think I buy that
argument at all. The goal of the as-if rule and sequence point rules
is to make it possible for developers to distinguish between operations
for which they require a particular sequencing, and operations for which
they do not.
> K & R designed C at a
> time when it was not known how important it was to specify the
> sequence of arithmetic and logical operators, but common C compilers
> prior to your broken standard evaluated left to right with no
> nonsense, and did not try to over-optimize such a profoundly unsafe
> language.
Before the standard, different compilers evaluated in different orders under
different circumstances. After the standard, it's the same.
> More on your other points when I have more time.
It would be more interesting if you'd stop dragging in your conspiracy
theory crap and actually talk about the language.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
>> Well, I've talked to people who have used C on a machine with no stack, so I
>> guess I believe them more than I believe you.
> Can you give any links where I can read more about such
> implementations of C, I am intrigued by how they are done.
Not off the top of my head.
> Part of what I am curious about is, when you say "no stack", do you
> mean hardware support for a stack? Or no use of a stack-like data
> structure?
The former.
So far as I can tell, you essentially need some kind of LIFO queue
somewhere to manage a C implementation, or something that will function
rather like one.
The key here is that spinoza1111 is completely mistaken about what
Schildt actually said. "The stack" is a particular implementation
choice, and Schildt makes this abundantly clear. (And he really does;
the guy is a very clear writer, which makes it all the more frustrating
that he very clearly explains things which are simply wrong in such
a way that the reader is generally left with a clear, strong, impression
of something which isn't true.)
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
Here, you descend to the level of the worst sort of geek. Get a life,
Seebach.
[My more extended reply is now in the moderated group. I had trouble
posting it. Let's see if I can post this here.]
spinoza1111
anything wrong.]
On Sep 11, 3:14 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-09-11,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Having left programming, in no little disgust at the personalities of
> > programming, after thirty years, I teach English and creative writing
> > in addition to intro computer science. I have learned that intolerant
> > students, who believe words are things, make the slowest progress.
>
> Well, they make the slowest progress when you teach them. If you actually
> teach them. If any of what you're saying is true.
You would do well to learn a discourse ethic (Kant and Habermas).
Why is it a rule on the Internet to always say this when a man reveals
he's a teacher? Could it be a normalization of an adolescent rage that
survives into adulthood that survives owing to its normalization?
Beyond ad hominem, this is not a valid argument. As a discourse ethic
it makes conversation impossible. But that's your goal, isn't it?
>
> > Therefore, I will be the judge as to whether a text has ?intrinsic
> > worth?.
>
> This is a non-sequitur. You have not offered a qualification to judge,
> and if anything, you've offered a sort of non-qualification.
>
> > Welcome to the weird and wonderful world of C. This is why we have
> > Java, isn?t it.
>
> Nope. Java wouldn't do us any good here.
>
> > Nonsense on stilts, Socrates.
>
> Uh, no. Simple fact.
>
> > What you?re talking about happens to be a collision of the stack with
> > practices from the Ice Age which predated the stack, practices which
> > infected the C language, unfortunately, practices which do not show
> > intellectual superiority and are shibboleths.
>
> I made no claims about "intellectual superiority".
>
> I claimed a *reality* -- on real machines, with real compilers, believing
> Schildt's crap would leave you unable to comprehend or debug a problem which
> really occurred.
Your example was contrived. Schildt only gives the programmer a subset
of what she needs to know to debug an OS. But that's not what he set
out to do.
>
> > These include the use of finite and hardened registers which remains a
> > necessity at the low level because the MIPS kiddies actually
> > rescusitated this US-centric praxis in 1987, claiming, without much
> > evidence, that it was ?efficient? in a singularly sloppy use of
> > English.
>
> When you can make a CPU do more work in less time on less power, please
> let us know.
When you stop producing wrong answers at high speed, be sure to write.
>
> > And you are saying that by teaching the stack (which is good practice)
>
> You keep asserting that this is "good practice", but I've just demonstrated
> that it's genuinely harmful.
To mention stacks lest the students assume that this is all there is?
Bullshit. You're the Fundamentalist parent who takes his kid out of
sex education because he might get ideas.
You cannot explain how C works at runtime without stacks. Now, if you
wish to mystify this so that you and your butt buddies can imagine
themselves high priests, why don't you just admit it?
>
> > Herb FAILS to teach arcana, and makes the tyro incapable of also
> > thinking at the more primitive (not ?better?) level of the single-
> > level register. Arguably, the student needs to think at both levels,
> > but the stack has priority because you can write slow OSen without
> > thinking in assembly language!
>
> The student does not need to learn to think at either, but if you're going
> to start thinking about how things "really work", it's crucial to think about
> how actual machines work rather than about how Schildt thought some DOS box
> worked.
At the time the "dos box" was in widest use. Your snobbery is unearned
since you haven't, in all probability, programmed on that side of the
fence.
Schildt wasn't trying to teach a class in computer architecture, and
even such classes focus on a smallish number of machines.
>
> > You are creating a class divide which I reject.
>
> No, I am pointing out reality. Which you reject.
>
> > You are saying that
> > bottom-feeding computer science *privat dozents* at DeVry and Borstal
> > may not speak of certain matters.
>
> No, I'm not. I've merely said that people who make false claims are not
> making true claims, and aren't going to get anywhere.
Learn how to craft an argument, not merely parrot your previous claim,
please.
>
> > You?re here worse than student ?Otto? who sits in the back of the
> > class with twenty years of assembler and no health insurance,
>
> Okay, so.
>
> Basically, you have some kind of issue, totally unrelated to C, involving
> health insurance and job security.
"Totally" unrelated? I don't think so. Everything is related to
everything else (that's why we have language: to relate). The problem
is that programmers don't want to think outside their jobs.
Seebs
> he's a teacher? Could it be a normalization of an adolescent rage that
> survives into adulthood that survives owing to its normalization?
No.
> Beyond ad hominem, this is not a valid argument. As a discourse ethic
> it makes conversation impossible. But that's your goal, isn't it?
No.
My goal is to make discussion possible. Your claim, though, is useless
for discussion. The plural of "anecdote" is not "data".
> Your example was contrived. Schildt only gives the programmer a subset
> of what she needs to know to debug an OS. But that's not what he set
> out to do.
My example was not "contrived", by definition. A contrived example is one
invented to suit a purpose, thus the word "contrive". My example was one
taken from actual events which occurred independent of this discussion.
The point remains: Schildt told the reader what "the stack" was, and was
wrong.
> When you stop producing wrong answers at high speed, be sure to write.
This remains a non-sequitur.
> To mention stacks lest the students assume that this is all there is?
No, to give a detailed and specific set of claims about what a stack is
which are false.
> You cannot explain how C works at runtime without stacks. Now, if you
> wish to mystify this so that you and your butt buddies can imagine
> themselves high priests, why don't you just admit it?
If your speculations were correct, I'd admit it. They aren't.
You can explain how C works at runtime without referring to the stack.
You do need to talk about some kind of logical structure similar to a
stack, but what Schildt did was make much more specific claims about exactly
what was used and how.
> At the time the "dos box" was in widest use.
Doesn't matter. You have made the claim that what Schildt taught was
absolutely necessary for all systems, and it wasn't.
> Learn how to craft an argument, not merely parrot your previous claim,
> please.
When you respond in some way to a claim, I'll address the response. If
you don't show any sign of having perceived it, I'll probably repeat it.
> "Totally" unrelated? I don't think so. Everything is related to
> everything else (that's why we have language: to relate).
That's an interesting theory.
However, while it's absolutely true that every star astronomers study
is attracted to my spleen with force proportional to the product of their
mass and its mass, astronomers don't need to talk about that to do their
jobs.
If you stay focused on things relevant to understanding C, you might
get somewhere. If you rant about health care policy and philosophy without
tying the claims to anything specific in C, we'll just say "shiny side out"
and ignore you.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
Please segment your replies, Peter. They are sometimes more than my
newsreader can reply to, and you may be burdening our moderator.
> On 2009-09-11, tohava <toh...@gmail.com> wrote:
>
> >> Well, I've talked to people who have used C on a machine with no stack, so I
> >> guess I believe them more than I believe you.
> > Can you give any links where I can read more about such
> > implementations of C, I am intrigued by how they are done.
>
> Not off the top of my head.
Translation: they don't exist.
>
> > Part of what I am curious about is, when you say "no stack", do you
> > mean hardware support for a stack? Or no use of a stack-like data
> > structure?
>
> The former.
>
> So far as I can tell, you essentially need some kind of LIFO queue
> somewhere to manage a C implementation, or something that will function
> rather like one.
So ... you need a stack. This is like pulling teeth, Peter.
>
> The key here is thatspinoza1111is completely mistaken about what
> Schildt actually said. "The stack" is a particular implementation
> choice, and Schildt makes this abundantly clear. (And he really does;
> the guy is a very clear writer, which makes it all the more frustrating
> that he very clearly explains things which are simply wrong in such
> a way that the reader is generally left with a clear, strong, impression
> of something which isn't true.)
A LIFO queue is a stack, and a stack a LIFO queue:
GENIUS asserteth this and as always, GENIUS speaketh true
Folly, on t'other hand, insists that they must differ
For she must be right, she shrieks, Lo! she starts to wither!
Horrid spectacle! Snakes she hath, no longer Hair:
Oh, avert thine eyes, heroes, of her ye must beware!
She gibbers, she moans, and in a hellish voice,
She croaks, "the stack is an implementation choice!"
But Genius stands his ground, and saith, there is no other way
To what thou callest lifo, horrid Spectre, this you cannot gainsay.
> -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!
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
> On 2009-09-11,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > I'm busy at this time, but this is an incredibly unethical thing for
> > you to say, because it is ex cathedra and a misuse of your technical
> > authority.
>
> Fascinating assertion.
>
> > The functionality IS the stack, and I really, really hope you know
> > this.
>
> Well, now I know how you are using the word.
>
> However, what Schildt described was not an abstract stack, but a specific
> layout in which the stack and heap were separate and non-overlapping regions
> of memory, such that no address of any "heap" object is between any two
> "stack" objects, and vice versa.
This is of course a respected way of presenting the key facts of
runtime, as opposed to obscuring them. No competent student will rely
upon contiguity, nor does Schildt imply contiguity.
>
> > The runtime behavior of a normal C program must be explained by
> > using the stack as an abstraction, because as soon as one procedure
> > can have > 1 activations, it needs > 1 activation records holding its
> > parameters, its local variables, and the return address. There is no
> > way to store and retrieve these activation records which does not
> > involve stack "like" mechanisms: the stack is provably the minimal
> > amount of mechanism needed.
>
> Absolutely correct!
>
> ... But "minimal amount of mechanism" is not the same as "how it really
> works".
Herb, as I have said, was NOT writing for Morgan Kauffman and fourth
year compsci majors.
>
> > As soon as you write
>
> > For 1 (or 2), N factorial is 1 (or 2): for n, n factorial is n*(the
> > factorial of n-1)
>
> > you have a function which can only be calculated by something that
> > uses a stack. If it uses an array, all it needs to do is access the
> > beginning or end of the array, aka the top of the stack.
>
> This is a fascinating assertion, but not true -- many compilers will
> implement this function without recursion.
Certain functions can be expressed iteratively, and factorial is one
example. Others cannot. But to convert a recursive factorial into the
iterative equivalent would take a lot of compile time optimization.
What I hope you mean is that most programmers will write N factorial
using iteration.
Wikipedia contains the claim that any recursive function can be
iteratively expressed. I do not think this is true, for example, in
the case of recursive descent parsing. If memory serves, my old
MacDonald-Elsevier "Monograph in Computer Science" on "Recursive
Programming" contained the contrary claim that not all functions that
can be calculated recursively can be calculated iteratively, and gave
as an example, if memory serves, Ackermann's function.
But too my knowledge there is no computer that computes all recursive
functions iteratively UNLESS it does so using a stack: the stack then
makes the calculation not iterative, so there you are.
>
> > Therefore, once recursive call exists, the stack exists. An
> > "intuitionist" mathematician knows this: a "Platonist" realizes it a
> > few minutes later.
>
> No.
>
> Again, "the stack" is not an abstract concept,
Aux d'autres, ma vielle. It IS an abstract concept. Did you flunk baby
computer science?
>but a specific region of
> storage allocated in a particular way. If Schildt had said "a useful way
> to think about automatic variable allocation is...", I probably wouldn't
> be complaining; it *is* a useful way to think about automatic variable
> allocation.
>
> But what he claimed was that there existed a memory layout, and that all
> automatic variables were allocated in a specific region of memory, and that
> all heap variables were allocated in another, and this is not true,
> and believing it is misleading.
He made no such claim.
>
> > Peter, I regard you as "elite" wrt computer science: but from this
> > comment you make alone, I see you are like the ruling class which is
> > willing to destroy American industry to preserve the profits of a
> > view, because you are willing to destroy knowledge and memory merely
> > to be right, and preserve a standard designed primarily to protect
> > profits.
>
> I regard you as schizophrenic.
Soviet psychiatry.
> There is simply no evidence or data to
> support the contention that the standard was designed "to protect profits".
On the contrary, young fellow, many of us noticed in 1980 that
suddenly, the public interest had no traction whatsoever in computer
science. You grew up (half way) in the selfish world created by
Thatcher and Reagan, but I saw my first homeless mother and child on
First Avenue in Seattle in 1986, when I was 36. I suggest you grow up
more.
> Indeed, as pointed out with concrete examples, the standard was designed
> in a way which is extremely unlikely to achieve your described theory of
> how companies were trying to protect profits.
How strange. "Sequence points" were designed to protect profits,
because you lacked the courage to insist on left to right
optimization, to protect the investment of developers who'd unwisely
over-optimized a language which is, owing to aliasing alone, unsafe at
any speed, and unsafe for optimization...as your example demonstrates.
Within OS and compiler development shops, C is surrounded by tools
which make it somewhat safe but in general it shouldn't be optimized,
especially for applications and most especially for life and mission
critical systems.
>
> > I'd also warn you that I'd never heard of your famous "sequence
> > points" prior to the standards push of the 1990s, and I am confirming
> > a little theory that I have: that you invented this claptrap to make
> > optimizing, but incorrect, compilers, correct.
>
> Again, I wasn't involved in any of this, but I don't think I buy that
> argument at all. The goal of the as-if rule and sequence point rules
> is to make it possible for developers to distinguish between operations
> for which they require a particular sequencing, and operations for which
> they do not.
"Sequence points" ignored the fact that a sensible sequence is implied
by K & R. Although few competent programmers would code i=i++, it's
clear from early C what's meant. i gets the old value of i (because
that's the value of the right side of the assignment) but is then
overwritten by i plus one. Let's try this out (using Microsoft .Net C+
+ but in C mode with file type .C):
#include <stdio.H>
int main()
{
int intIndex1;
intIndex1 = 5;
intIndex1 = intIndex1++; /* Whee */
printf("%d\n", intIndex1++);
printf("%d\n", intIndex1 = intIndex1++);
printf("%d\n", intIndex1);
}
A K&R understanding of this gives 6 7 8 and that is what I get. It's
not "undefined". Why make it so?
I agree that there are some puzzles here. What is the value of "the
right hand side" of i=j++?
But I think the puzzle is cleared up once you posit, as did Herb, a
paper machine with an ideal stack. This prints 6:
#include <stdio.H>
int main()
{
int intIndex1;
int intIndex2;
intIndex1 = 5;
intIndex2 = 6;
printf("%d\n", intIndex1 = intIndex2++);
}
because intIndex2 when it is 6 is pushed on the stack but incremented
in its addressible location.
Truly pathological constructs such as i=(j)++ have no meaning and
should have resulted in compile-time diagnostics, because a close
reading of either edition of K&R, which should have controlled, makes
it obvious that pre and post increment need lValues to be meaningful.
Requiring "standard" C programs to avoid using post and pre increment
on LValues would have been a tough and painful decision that would
have caused software vendors (and not only compiler vendors) to call
your boss. But the operation has no meaning given a close reading of K
& R, despite the fact that they allow it.
But, apparently to preserve broken compilers and their optimizers, you
seem to have invented this broken notion of a "sequence point". And I
conclude this was done because of commercial pressure.
>
> > K & R designed C at a
> > time when it was not known how important it was to specify the
> > sequence of arithmetic and logical operators, but common C compilers
> > prior to your broken standard evaluated left to right with no
> > nonsense, and did not try to over-optimize such a profoundly unsafe
> > language.
>
> Before the standard, different compilers evaluated in different orders under
> different circumstances. After the standard, it's the same.
No, you make order of evaluation "undefined". You make results
"undefined".
>
> > More on your other points when I have more time.
>
> It would be more interesting if you'd stop dragging in your conspiracy
> theory crap and actually talk about the language.
I retain the right to speak truth to power.
>
> -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!
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
> On 2009-09-11,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Why is it a rule on the Internet to always say this when a man reveals
> > he's a teacher? Could it be a normalization of an adolescent rage that
> > survives into adulthood that survives owing to its normalization?
>
> No.
Fast replies. Hey, are you also the moderator?
>
> > Beyond ad hominem, this is not a valid argument. As a discourse ethic
> > it makes conversation impossible. But that's your goal, isn't it?
>
> No.
>
> My goal is to make discussion possible. Your claim, though, is useless
> for discussion. The plural of "anecdote" is not "data".
I'm not dealing in anecdotes. The importance of the stack and the
usefulness of paper machine narrative aren't anecdotes.
>
> > Your example was contrived. Schildt only gives the programmer a subset
> > of what she needs to know to debug an OS. But that's not what he set
> > out to do.
>
> My example was not "contrived", by definition. A contrived example is one
> invented to suit a purpose, thus the word "contrive". My example was one
> taken from actual events which occurred independent of this discussion.
>
> The point remains: Schildt told the reader what "the stack" was, and was
> wrong.
No, he wasn't. He identified an idealized stack minus distracting
details.
>
> > When you stop producing wrong answers at high speed, be sure to write.
>
> This remains a non-sequitur.
Do you know what that word means?
>
> > To mention stacks lest the students assume that this is all there is?
>
> No, to give a detailed and specific set of claims about what a stack is
> which are false.
He wasn't describing the stack. He was using it.
>
> > You cannot explain how C works at runtime without stacks. Now, if you
> > wish to mystify this so that you and your butt buddies can imagine
> > themselves high priests, why don't you just admit it?
>
> If your speculations were correct, I'd admit it. They aren't.
>
> You can explain how C works at runtime without referring to the stack.
> You do need to talk about some kind of logical structure similar to a
> stack, but what Schildt did was make much more specific claims about exactly
> what was used and how.
Not any more than any teacher teaching by way of a model. You are
being disingenuous to the point of dishonesty, because this is how
education works. We draw idealized models and only students
unqualified to be there confuse those with reality.
>
> > At the time the "dos box" was in widest use.
>
> Doesn't matter. You have made the claim that what Schildt taught was
> absolutely necessary for all systems, and it wasn't.
Some form of LIFO stack or a more powerful and inclusive (and
unnecessary) exists to implement the C runtime and its recursion.
>
> > Learn how to craft an argument, not merely parrot your previous claim,
> > please.
>
> When you respond in some way to a claim, I'll address the response. If
> you don't show any sign of having perceived it, I'll probably repeat it.
>
> > "Totally" unrelated? I don't think so. Everything is related to
> > everything else (that's why we have language: to relate).
>
> That's an interesting theory.
>
> However, while it's absolutely true that every star astronomers study
> is attracted to my spleen with force proportional to the product of their
> mass and its mass, astronomers don't need to talk about that to do their
> jobs.
>
> If you stay focused on things relevant to understanding C, you might
> get somewhere. If you rant about health care policy and philosophy without
> tying the claims to anything specific in C, we'll just say "shiny side out"
> and ignore you.
I'm not "ranting". After thirty years in programming, I noticed how
political discourse was converging with programmer conversations in
which simplification was confused with virtue, and I also noticed how
like programmers in the early 1980s, people began to be utterly
subservient to corporate interests.
>
> -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!
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Francis Glassborow
> On Sep 11, 11:11 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> Please segment your replies, Peter. They are sometimes more than my
> newsreader can reply to, and you may be burdening our moderator.
>
>> On 2009-09-11, tohava <toh...@gmail.com> wrote:
>>
>>>> Well, I've talked to people who have used C on a machine with no stack, so I
>>>> guess I believe them more than I believe you.
>>> Can you give any links where I can read more about such
>>> implementations of C, I am intrigued by how they are done.
>> Not off the top of my head.
>
> Translation: they don't exist.
>
>>> Part of what I am curious about is, when you say "no stack", do you
>>> mean hardware support for a stack? Or no use of a stack-like data
>>> structure?
>> The former.
>>
>> So far as I can tell, you essentially need some kind of LIFO queue
>> somewhere to manage a C implementation, or something that will function
>> rather like one.
>
You know that a great deal of this argument about needing a stack
resolves round what that word is meant to mean. Last in first out queues
can be implemented in many ways. The problem is that Schildt decided to
describe a very specific implementation and not one that is universely used.
What makes it harder is that the implementation can also use the stack
for purposes other than storing local variables. That means that on such
machines writing to an invalid pointer can have unexpected and dire
consequences as Seebs' anecdote was intended to illustrate.
What the programmer needs to know is that local variables are stored
somewhere and that upon exit from a function that storage is released.
It is coomon practice to store the address of the data block of the
calling function in the block being used by the called function though
this is not necessary (it can be stored on an entirely different stack)
And IIRC at least one IBM implementation did not use a contiguous stack
to store local variables but a linked list of activation records.
Now to return to a couple of other points. When I pick up a technical
book I try to decide whether the author shows signs of being able to
write clearly and whether he has a clear mental model of the subject.
Schildt meets those two criteria but unfortunately when I first looked a
bit closer (almost 20 years ago) I discovered that the kind of errors he
was making strongly suggested that his mental model of C was erroneous
even if limited to a DOS based machine. I regularly checked his books
over the next decade (at that time it was part of by job as a major
reviewer of books for ACCU) and over those years I saw little if any
improvement until right towards the end when the last couple of books I
looked at did show signs that he had developed a better understanding of
his subject matter. However his poor track record over a decade left me
doubtful as to how far the learning process had gone.
Why do I (and others) call him out by name? Well how else should we do
it? None of us have any personal animosity towards Schildt we just think
that the level of error in his books is unacceptable, and for me at
least, much of his work is positively detrimental because it teaches
readers things that are not true.
His work look like that of someone who has learnt his C by experiment
and then created a mental model of why it works like that. That is a
fine way to do science but a poor way to do technology. If you want to
know how a car works, talk to an automotive engineer. If you want to
know how C works talk to an implementer, better still talk to several. A
compiler isn't a black box into which you feed source code for it to
output an executable. Learning to program should not be a kind of trial
and error (write some code and then see what the result generated by a
compiler does). It is perfectly possible to determine what a piece of
correct code does by reading it. Unfortunately it is completely
impossible to determine what a piece of incorrectly written code may do.
Look at all the problems we have with exploits based on buffer
over-runs. How many of the producers of such vulnerable code learnt
their C from Schildt (who rarely if ever warns readers of the dangers of
using such functions as gets().)
If someone wrote a book on electrical wiring to the standard that
Schildt did with C there would be class actions against the author for
the consequential damage. It is harder to pin down in the case of
programming, but nonetheless bad programming based on a poor or
erroneous understanding of the language being used is costing many
innocent users a great deal.
Those that teach have a great responsibility not just to do the best
they can but to do a good job. I suspect that Schildt was one of the
many self-taught programmers from the 70s and 80s. Like many who have
taught themselves his knowledge is very patchy. However the self-taught
should be very wary about teaching others authoritatively. With regret
most publishers are only interested in selling books, and if getting
them technically correct impacts negatively on their bottom line they
are likely to positively discriminate against those who take the time to
do so.
I wonder why Schildt left the world of programming in order to write
books on the subject. Good programmers generally earn a great deal more
than technical authors, particularly the latter when they take the time
to make sure their work is technically correct as well as fluently written.
Hans-Bernhard Bröker
> If you investigate the disorganized "laundry lists" of charges put out
> by Seebach and Feather, you discover that Schildt was libeled.
Utter, contrived nonsense. The list of arguments brought forth against
Schildt are about an order of magnitude more organized than what you've
presented here. And the only attempted libel I can spot here is you
trying to libel Mrs. Seebach and Feather. I say "attempted" because for
it to be actual libel, there would have to be a non-negligible chance of
people taking you seriously. Which there is not.
> The
> laundry lists are padded with trivia and matters of style and
> interpretation.
There's no interpretation involved. Schildt claims the C language works
in certain ways, the C language definition clearly says otherwise.
The most prominent example is Schildt's persistent claim that 'void'
were the correct return type for the main() function in a hosted
environment (at the time, that was MS-DOS), which it clearly is not.
> Most seriously, they criticise Schildt for implying
> that the Standard requires functionality merely when Schildt is
> explaining how C works by using concepts which are known to be
> necessary to implement C.
The error here is in the analysis of what is, and what is not "necessary
to implement C". You appear to share Schildt's mistaken beliefs on
those issues, including the necessity of a stack. Others know better,
and said so in public. That's not libel, that's a necessary statement
of fact.
You claim yourself to be a teacher of literature these days. So let me
put this in a way that should match your mindset a little better: what
on earth do you think qualifies _you_ to make statements about the
meanings of a text that contradict not only the words of said text
itself, but also the publicly available statements of its authors?
And how many points would a student get in one of your courses who
backs up his arguments with nothing more than "people say this", and "it
has been said that"?
Francis Glassborow
>
>>> I'd also warn you that I'd never heard of your famous "sequence
>>> points" prior to the standards push of the 1990s, and I am confirming
>>> a little theory that I have: that you invented this claptrap to make
>>> optimizing, but incorrect, compilers, correct.
>> Again, I wasn't involved in any of this, but I don't think I buy that
>> argument at all. The goal of the as-if rule and sequence point rules
>> is to make it possible for developers to distinguish between operations
>> for which they require a particular sequencing, and operations for which
>> they do not.
>
> "Sequence points" ignored the fact that a sensible sequence is implied
> by K & R. Although few competent programmers would code i=i++, it's
> clear from early C what's meant. i gets the old value of i (because
> that's the value of the right side of the assignment) but is then
> overwritten by i plus one. Let's try this out (using Microsoft .Net C+
> + but in C mode with file type .C):
>
OK, you clearly do not know what a sequence point is and what it is for.
One way of looking at them is that they are points of stability in your
code. This has actually become increasingly important with cache and
multi-core CPUs.
But I do not know why any of us is wasting time responding to you
because you clearly know even less than Schildt. In addition I am
shocked at the poor quality of your writing. I would be irritated if you
were a programmer but considering the job you claim to do, I think you
should be ashamed to expose your inability to express your thoughts
coherently.
At least Schildt writes well even the technical content of what he
writes is sometimes plain wrong.
Seebs
> You know that a great deal of this argument about needing a stack
> resolves round what that word is meant to mean. Last in first out queues
> can be implemented in many ways. The problem is that Schildt decided to
> describe a very specific implementation and not one that is universely used.
Well, I got bored. So I decided to go track down my copy of C:TCR (3rd
Edition, copyright 1995). Page 426 starts Chapter 16, "Dynamic Allocation".
"Dynamic allocation is the second way that a program can acquire
storage for data. In this method, storage is allocated from free
memory as needed during the execution of the program. The region of
free memory that is used for dynamic allocation is called the heap.
Traditionally, the heap lies between your program and its permanent
storage area, and the stack. Figure 16-1 shows conceptually how a C
program would apapear in memory. (parenthetical elided) The stack
grows downward as it is used. [...] Memory to satisyfy a dynamic
allocation request is taken from the heap, starting just above the
global variables and growing towards the stack."
This isn't particularly accurate. It's also not didactically useful. This
explanation occurs fairly late in, along with a detailed discussion of the
near, far, and huge 80x86 memory models. While it's certainly true that
those models were, at the time, significant to many developers... It utterly
undermines the claim that, at the time when we are hearing about the stack,
Schildt is trying to use a "minimal" model to avoid complicating things;
the multiple non-overlapping memory models and pointer types are far, far,
more complicated than a real discussion of stacks, registers, and other ways
of handling automatic storage.
There is an earlier part, on page 13, which says:
A compiled C program creates and uses four logically distinct regions
of memory that serve distinct functions. The first region is the
memory that actually holds your program code. The next region is
memory where global variables are stored. The remaining two regions
are the stack and the heap. The stack is used for a great many things
while your program executes. It holds the return addresses of
function calls, arguments to functions, and local variables. It will
also save the current state of the CPU. The heap is a region of free
memory that your program can use via C's dynamic allocation functions
for linked lists and trees.
The exact layout of your program may vary from compiler and compiler
and environment to environment. For example, most C compilers for the
8086 family of processors have several different ways to organize
memory because of the segmented memory architecture of the 8086.
(The memory models of the 8086 family of processors are discussed
later in this book.)
Although the exact physical layout of each of the four regions of
memory differs among CPU types and C implementations, the diagram in
Figure 1-2 shows conceptually how your C programs appear in memory.
Figure 1-2 depicts a rectangle divided into four parts:
Stack
|
v
^
|
Heap
Global Variables
Program Code
The questions we must evaluate are:
1. Is this description correct?
2. Is it at least substantively correct?
3. Was it at least substantively correct for the time when it was written?
4. Was it didactically superior to other possible explanations?
That last is probably the key defense. No one seriously defends #1. #2 is a
more interesting debate. I don't know exactly how DOS-type compilers worked
back then, but on the systems I was familiar with, I do not believe it was
even substantively correct. On Amiga and Mac systems, which multitasked but
lacked a fully-functional VM system, it is just plain not even close; stack
and heap were both allocated in free memory, with multiple different programs
having stacks and heap spaces which might be interleaved with each other. You
could easily end up with the stack for one program between two chunks of the
heap of another program.
Also significantly, the comment about global variables is incorrect. It is
not global variables, but *static* variables, which generally had reserved
space -- and local static variables would not be in the stack, but would be
in the reserved space. Or spaces; many systems already distinguished between
blocks with specific initialized values and blocks of storage which could be
initialized to zero or required no initialization. There is no general
guarantee that variables will all be moved into a separate category, and even
if they were, the key is not "global" but "static" objects.
The real question, I guess, is the didactic benefit. Does this explanation
help prepare the user to understand the coming text?
No, it doesn't.
I'm waiting for something to compile. I might as well have a go at this.
The C language allows for the declaration of variables of various
types, called "objects". An object is simply a region of storage
(generally memory) which holds a value. Most objects are stored
in memory, and the location in memory where they are stored is called
an "address". While it exists, each object's address is unique
to that object. Generally, addresses correspond to some kind of
layout of memory, the details of which vary between implementations.
While some objects exist from the start to the end of program
execution, not all do. The storage used to hold an object has a
"storage duration", or lifetime, determining when the storage
is reserved, and when the storage is made available again to be
used for storing other objects. There are three storage durations
in the C language; static, automatic, and dynamic.
Objects with "static" storage duration have storage reserved before
your program begins execution, and retain that same storage for the
entire lifetime of your program. Global variables are the most common
example of objects with static storage duration.
Objects with "automatic" storage duration have storage reserved
when they are used (or possibly earlier), and the storage is released
sometime after they are no longer available. For instance, a local
variable in a function has automatic storage duration; it is available
when the block of code containing it is executing, but the space
it was in may be reused at some point after that code completes. The
exact rules may vary from one implementation to another, or depending
on compiler options; all you need to be aware of is that you cannot
continue to refer to an object with automatic storage duration after
the block containing the declaration has been exited, and that you
do not need to explicitly allocate or deallocate these objects.
Objects with "dynamic" storage allocation have storage reserved by
explicit actions, such as calls to special library functions. That
storage remains reserved until it is released by explicit actions.
You must take care to release the storage of dynamic objects when
you are done using them, and you cannot access the object after you
have released its storage.
I'm not sure that's right, but it's not awful for a first draft, I don't
think. That took twenty minutes or so. I'm guessing that it would be at
least as useful to a novice programmer as Schildt's explanation, and it
has the advantage that it is much less likely to cause the reader trouble
later; I don't know of any system failing to match this description, and
don't think one would be possible.
The above does not address VLA types, but then, they didn't exist in 1995. :)
> I wonder why Schildt left the world of programming in order to write
> books on the subject. Good programmers generally earn a great deal more
> than technical authors, particularly the latter when they take the time
> to make sure their work is technically correct as well as fluently written.
FWIW: I earned substantially more money per hour doing technical writing,
but it wasn't as stable. Books, not so much unless they're bestsellers,
but bespoke technical writing, by someone who knows the field, can be very
rewarding.
I believe that Schildt probably has a genuine passion for communication. It's
a shame he was not as devoted to learning as he was to teaching.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Dag-Erling Smørgrav
> The functionality IS the stack, and I really, really hope you know
> this. The runtime behavior of a normal C program must be explained by
> using the stack as an abstraction, because as soon as one procedure
> can have > 1 activations, it needs > 1 activation records holding its
> parameters, its local variables, and the return address. There is no
> way to store and retrieve these activation records which does not
> involve stack "like" mechanisms: the stack is provably the minimal
> amount of mechanism needed.
You can allocate activation records on the heap and keep track of them
with a linked list. You could claim that the linked list is just a
stack in disguise, but in the case of a language that supports closures
or coroutines, the linked list can actually be a tree, or even a forest
(i.e. a collection of unconnected trees). This can even become the case
with C if you throw something like pthreads into the mix.
> Therefore, once recursive call exists, the stack exists. An
> "intuitionist" mathematician knows this: a "Platonist" realizes it a
> few minutes later.
Open any book on Lisp (I recommend Abelson & Sussman's _Structure and
Interpretation of Computer Programs_) and you will quickly learn that
there is an important distinction between a recursive function and a
recursive process, and that the former may (but does not necessarily)
result in the latter.
I'm getting the feeling that there are significant gaps in your
knowledge of programming language theory.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Certain functions can be expressed iteratively, and factorial is one
> example. Others cannot. But to convert a recursive factorial into the
> iterative equivalent would take a lot of compile time optimization.
Actually, it's very simple; it's called "tail call elimination".
> Aux d'autres, ma vielle.
Is this supposed to be French? It isn't.
DES
--
Dag-Erling Smørgrav - d...@des.no
Keith Thompson
[...]
> I'm waiting for something to compile. I might as well have a go at this.
An excellent description. Just a couple of very small quibbles.
[...]
> There are three storage durations
> in the C language; static, automatic, and dynamic.
The C99 standard uses the term "allocated" for what you call
"dynamic". (I don't think C90 had yet introduced this term.)
[...]
> Objects with "dynamic" storage allocation have storage reserved by
> explicit actions, such as calls to special library functions. That
> storage remains reserved until it is released by explicit actions.
> You must take care to release the storage of dynamic objects when
> you are done using them, and you cannot access the object after you
> have released its storage.
There are few enough memory allocation functions that naming them, or
at least mentioning malloc and free as examples, would probably
improve clarity here.
> The above does not address VLA types, but then, they didn't exist in
> 1995. :)
Yes, it does; VLAs have automatic storage duration.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dag-Erling Smørgrav
> You claim yourself to be a teacher of literature these days. So let
> me put this in a way that should match your mindset a little better:
> what on earth do you think qualifies _you_ to make statements about
> the meanings of a text that contradict not only the words of said text
> itself, but also the publicly available statements of its authors?
It's called deconstructionism.
DES
--
Dag-Erling Smørgrav - d...@des.no
Seebs
> Seebs <usenet...@seebs.net> writes:
> [...]
>> I'm waiting for something to compile. I might as well have a go at this.
> An excellent description. Just a couple of very small quibbles.
Heh.
> [...]
>> There are three storage durations
>> in the C language; static, automatic, and dynamic.
> The C99 standard uses the term "allocated" for what you call
> "dynamic". (I don't think C90 had yet introduced this term.)
I'm pretty sure that was new. (I recently had a hilarious epic battle
with someone on a vBulletin forum over the question of whether VLAs
were an instance of "dynamic memory allocation"; I argued that they
were "dynamic memory allocation", even though they might not be
"dynamic-memory allocation" using the "dynamic" term as defined in the
GNU libc docs, which he felt were extremely authoritative.)
> There are few enough memory allocation functions that naming them, or
> at least mentioning malloc and free as examples, would probably
> improve clarity here.
Good point.
>> The above does not address VLA types, but then, they didn't exist in
>> 1995. :)
> Yes, it does; VLAs have automatic storage duration.
Yeah, but it's worth noting that they have different rules. If you declare
an automatic object of non-VLA type, its lifetime begins as soon as you enter
the block containing the declaration; VLAs have a lifetime beginning at their
declaration, rather than at the top of the block. Since C99 allows mixed
declarations and code, this is actually potentially significant.
The overall point, though, is that I think you can do a much better job of
explaining C's view of memory without using the words "stack" and "heap",
in a way that covers the IMPORTANT qualities -- that these kinds of objects
require different levels of programmer awareness as to there durations --
without introducing any particular model of how the system handles them.
If I were to go after it with, say, a technical reviewer, and putting real
time into it, it could presumably be improved, but I would say that, in terms
of effectively teaching about C, that's a big step up from Schildt's
explanation of memory, which somehow manages to fail to present a useful
big picture, while presenting irrelevant trivia. The danger there is that
the irrelevant trivia, if presented on page 13 of the book, become part
of how the innocent newbie thinks about C -- making it hard for our poor
reader to cope when it turns out that real machines can be both more
complicated and simpler...
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Dag-Erling Smørgrav
> The questions we must evaluate are:
>
> 1. Is this description correct?
> 2. Is it at least substantively correct?
> 3. Was it at least substantively correct for the time when it was written?
For MS-DOS, modulo your point about global vs. static: yes. IIRC,
static variables that were not explicitly initialized were allocated by
the simple expedient of raising the bottom of the heap at program
startup. MS-DOS being what it was, most of this was done by the
compiler's runtime library, not by the operating system.
Your paraphrase of his discussion of memory models is not entirely
accurate. There is no "near", "far" or "huge" memory model; there are
"near", "far" and (rarely used) "huge" pointers, and *by common
convention* six memory models which were different ways of organizing
memory and different choices for the default pointer type for code (near
or far) and for data (near, far or huge). The simplest and most
efficient model is "tiny", with code, heap and stack in a single segment
and near pointers for everything, while "small" places the code in one
register and the heap and stack in another. Other memory models are
required when the code, the heap, or both exceed 64 kB.
DES
--
Dag-Erling Smørgrav - d...@des.no
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > Certain functions can be expressed iteratively, and factorial is one
> > example. Others cannot. But to convert a recursive factorial into the
> > iterative equivalent would take a lot of compile time optimization.
>
> Actually, it's very simple; it's called "tail call elimination".
>
> > Aux d'autres, ma vielle.
>
> Is this supposed to be French? It isn't.
It should have been a not aux: my mistake. However, it's a "real"
expression. It was mentioned in Somerset Maugham's The Razor's Edge.
Literally, it means "[tell] the others that, old girl" but Maugham
more idiomatically translated it to "tell that to the Marines" using a
World War I advertising slogan when writing in the 1930s.
Let x be a negative comment of the form "it is not the case that". I'd
suggest that these online conversations would not degenerate so
quickly if anytime had a comment of the form x on C or anything else,
he had the courage and decency to post, complementarily to x,
additional information (even at the risk of being in further error.
As it is, you people seem to me to be stuck at the level of vicious 14
year old adolescent boys.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
> > Certain functions can be expressed iteratively, and factorial is one
> > example. Others cannot. But to convert a recursive factorial into the
> > iterative equivalent would take a lot of compile time optimization.
>
> Actually, it's very simple; it's called "tail call elimination".
I could say "no its not", but I'll go out on a limb here: I'm a bit
rusty, but I'm not a vicious, smirking little twerp. OK, if the
recursive call is not at the end of the calling procedure, how does
"tail call elimination" apply?
>
> > Aux d'autres, ma vielle.
>
> Is this supposed to be French? It isn't.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
> > The functionality IS the stack, and I really, really hope you know
> > this. The runtime behavior of a normal C program must be explained by
> > using the stack as an abstraction, because as soon as one procedure
> > can have > 1 activations, it needs > 1 activation records holding its
> > parameters, its local variables, and the return address. There is no
> > way to store and retrieve these activation records which does not
> > involve stack "like" mechanisms: the stack is provably the minimal
> > amount of mechanism needed.
>
> You can allocate activation records on the heap and keep track of them
> with a linked list. You could claim that the linked list is just a
> stack in disguise, but in the case of a language that supports closures
> or coroutines, the linked list can actually be a tree, or even a forest
> (i.e. a collection of unconnected trees). This can even become the case
> with C if you throw something like pthreads into the mix.
Thanks for the illuminating example, but it does not change the fact
that (1) the stack is used all the time in exposition of runtime
semantics and (2) something that provides the functionality of the
stack is among other things an instance of the stack, no matter what
other functions it provides.
>
> > Therefore, once recursive call exists, the stack exists. An
> > "intuitionist" mathematician knows this: a "Platonist" realizes it a
> > few minutes later.
>
> Open any book on Lisp (I recommend Abelson & Sussman's _Structure and
> Interpretation of Computer Programs_) and you will quickly learn that
> there is an important distinction between a recursive function and a
> recursive process, and that the former may (but does not necessarily)
> result in the latter.
OK. Can Ackermann's function be implemented using iteration?
>
> I'm getting the feeling that there are significant gaps in your
> knowledge of programming language theory.
There may be. I was a compiler developer between 1981 and 1985, and
between 2001 and 2004 I wrote a small, interpretive compiler. I
welcome positive constructive comments for this reason. My purpose
here not to educate more knowledgeable specialists about their
discipline, but about broader issues, including a basic decency and
collegiality which I noticed is atrophied in places like Silicon
Valley.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
<francis.glassbo...@btinternet.com> wrote:
> spinoza1111wrote:
>
> >>> I'd also warn you that I'd never heard of your famous "sequence
> >>> points" prior to the standards push of the 1990s, and I am confirming
> >>> a little theory that I have: that you invented this claptrap to make
> >>> optimizing, but incorrect, compilers, correct.
> >> Again, I wasn't involved in any of this, but I don't think I buy that
> >> argument at all. The goal of the as-if rule and sequence point rules
> >> is to make it possible for developers to distinguish between operations
> >> for which they require a particular sequencing, and operations for which
> >> they do not.
>
> > "Sequence points" ignored the fact that a sensible sequence is implied
> > by K & R. Although few competent programmers would code i=i++, it's
> > clear from early C what's meant. i gets the old value of i (because
> > that's the value of the right side of the assignment) but is then
> > overwritten by i plus one. Let's try this out (using Microsoft .Net C+
> > + but in C mode with file type .C):
>
> OK, you clearly do not know what a sequence point is and what it is for.
> One way of looking at them is that they are points of stability in your
"Points of stability?" You may understand sequence points, but you
can't explain them, and I'd hesitate to call such a mute comprehension
a true understanding. A sequence point occurs at runtime, at an SP
operator which guarantees that operators which have preceded it are
executed.
The phrase "points of stability" might have meaning in analogue
computation, but there's no such thing in digital computation except
as a mental state of a confused programmer.
> code. This has actually become increasingly important with cache and
> multi-core CPUs.
>
> But I do not know why any of us is wasting time responding to you
> because you clearly know even less than Schildt. In addition I am
> shocked at the poor quality of your writing. I would be irritated if you
> were a programmer but considering the job you claim to do, I think you
> should be ashamed to expose your inability to express your thoughts
> coherently.
>
> At least Schildt writes well even the technical content of what he
> writes is sometimes plain wrong.
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
> have an appropriate newsgroups line in your header for your mail to be seen,
> or the newsgroup name in square brackets in the subject line. Sorry.- Hide quoted text -
>
> - Show quoted text -
Seebs
> For MS-DOS, modulo your point about global vs. static: yes. IIRC,
> static variables that were not explicitly initialized were allocated by
> the simple expedient of raising the bottom of the heap at program
> startup. MS-DOS being what it was, most of this was done by the
> compiler's runtime library, not by the operating system.
Sure. Perfectly reasonable.
I think I had a compiler where they were handled by the equally simple
expedient of simply having space for them mixed in with code that came
from near where they were compiled, so:
int foo(void) { ... }
int x;
int bar(void) { ... }
would yield a file containing three top-level labels, one named foo, one
named bar, and one named x... So at link time, they had sequential addresses.
> Your paraphrase of his discussion of memory models is not entirely
> accurate.
I am frankly surprised that it's even recognizeable. I had the good fortune
to only once in my entire programming career have to deal with such an issue;
after about four hours of careful study and debugging, we checked a box
in Visual Studio (or whatever it was) and things started working.
> There is no "near", "far" or "huge" memory model; there are
> "near", "far" and (rarely used) "huge" pointers, and *by common
> convention* six memory models which were different ways of organizing
> memory and different choices for the default pointer type for code (near
> or far) and for data (near, far or huge). The simplest and most
> efficient model is "tiny", with code, heap and stack in a single segment
> and near pointers for everything, while "small" places the code in one
> register and the heap and stack in another. Other memory models are
> required when the code, the heap, or both exceed 64 kB.
Right you are.
Hmm. This is interesting. Page 427 of TCR3E says:
"The ANSI C standard defines only four functions for the dynamic allocation
system: calloc(), malloc(), free(), and realloc(). However, this book
examines several others that are in wide use -- especially in the 8086 family
of CPU environments."
The other functions described are alloca(), various far/huge allocations
and frees, and:
_freect(size_t size) (returns approximate number of objects of that
size that can be allocated)
_memavl(void) (approximate number of bytes of free memory left)
_stackavail(void) (approximate number of bytes of stack left
for use with _alloca())
Can anyone point to an instance of any of these functions existing in another
environment? "Especially" implies that these functions have ever existed
elsewhere, which would sort of surprise me.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Dag-Erling Smørgrav
> OK. Can Ackermann's function be implemented using iteration?
I believe so, using memoization and a work queue:
place (m, n) at the back of the queue
while the queue is not empty:
take (i, j) from the front of the queue
if i = 0
store (j + 1) at position (i, j) in the cache
else if j = 0
if position (i - 1, 1) in the cache contains a value
store that value in position (i, j) in the cache
else
place (i - 1, 1) at the back of the queue
place (i, j) at the back of the queue
endif
else
if position (i, j - 1) in the cache contains a value
let k be that value
if position (i - 1, k) in the cache contains a value
store that value in position (i, j) in the cache
else
place (i - 1, k) at the back of the queue
place (i, j) at the back of the queue
endif
else
place (i, j - 1) at the back of the queue
place (i, j) at the back of the queue
endif
endif
endwhile
return the value at position (m, n) in the cache
Neither the cache nor the work queue can be construed as a stack.
DES
--
Dag-Erling Smørgrav - d...@des.no
--
spinoza1111
This is perfectly clear, and it is qualified to show that it is
exemplary. It is a clear word picture. He's not delivering a graduate
lecture in computer architecture.
>
> Figure 1-2 depicts a rectangle divided into four parts:
>
> Stack
> |
> v
> ^
> |
> Heap
>
> Global Variables
>
> Program Code
>
> The questions we must evaluate are:
>
> 1. Is this description correct?
> 2. Is it at least substantively correct?
> 3. Was it at least substantively correct for the time when it was written?
> 4. Was it didactically superior to other possible explanations?
>
> That last is probably the key defense. No one seriously defends #1.
I would, as long as you realize that Schildt's memory geometry is
topological and not metric.
> #2 is a
> more interesting debate. I don't know exactly how DOS-type compilers worked
> back then, but on the systems I was familiar with, I do not believe it was
> even substantively correct. On Amiga and Mac systems, which multitasked but
> lacked a fully-functional VM system, it is just plain not even close; stack
> and heap were both allocated in free memory, with multiple different programs
> having stacks and heap spaces which might be interleaved with each other. You
You use "interleaved" in such a sloppy fashion here that it could mean
almost anything. If a stack and a heap are allocated to a process, how
could they be safely "interleaved" with a stack and a heap allocated
to another process? If you go "down" from the process to a
"thread" (where terminology varies), two "threads" can share the same
stack and heap with locks, but this does not mean that the stack or
heap are multiply-interleaved at all.
You have repeatedly conceded that Schildt is a "clear" writer. While
Dijsktra would have no respect at all for Schildt, being horrified at
the actual systems Schildt and countless other programmers must master
as a matter of economic necessity, he did equate clarity with
understanding, so the unfortunate conclusion is that you may have been
exposed to more computer science than Schildt, but understand it less
than Schildt understands his material. And the even more unfortunate
conclusion is that you had no business accepting money to destroy
Schildt's reputation and enable a meanKids style attack on him that
has gone on far too long...and which set a precedent for the attack on
Java author Kathy Sierra.
> could easily end up with the stack for one program between two chunks of the
> heap of another program.
Zowie. But what you're missing is the fact that we don't want to have
to care about the layout of the heap and stack. If we are caring,
things have gone awry, and we are debugging at machine level. And
while debugging at this level is a noble ordeal which I've undergone,
it is also a sign of failure to write good code.
In all your education, you never learned, as would a good computer
scientist, to treat levels of representation with respect. Had you so
learned, you would have realized that Schildt has to give a metric to
a "topos", the latter being a variety of different ways of allocating
storage in detail.
Had you taken Phil 101, or stayed awake, you'd be aware that you're
making Plato's mistake: to think that over and above messy human
reality there is a world of Forms that can nonetheless be visualized,
which implies that anything but YOUR vision is a false picture. But as
it happens, there is no such thing as a "real" stack: all there is are
meat puppets stumbling around computers subject to the laws of
physics, and events in the brains of meat puppets in which the meat
puppets think they are using a "stack". But the "stack" is at another
level of representation "just" an array or linked list, then it's just
a block of memory, then it is silicon and then it is sand.
It's in fact what the priest said on Ash Wednesday: remember man thou
art dust. And because we're dust, we must love one another or die like
Auden said, not accept money to destroy a person's reputation, you dig
me, kid?
Oh, am I ranting? Too bad. Your computer science professor father
needed to jerk you around a long time ago. Stop calling people names
in the internet, punk.
>
> Also significantly, the comment about global variables is incorrect. It is
> not global variables, but *static* variables, which generally had reserved
> space -- and local static variables would not be in the stack, but would be
In C, the meanings of "global" and "static" are distinct. Elsewhere
they are not.
It is unfortunate that Schildt confused them. However, he is following
ordinary usage on the ground and presents the words in context in such
a way that their differential meaning (what makes them different) is
clear. Language policing isn't science. And, to use words as
shibboleths is barbaric.
> in the reserved space. Or spaces; many systems already distinguished between
> blocks with specific initialized values and blocks of storage which could be
> initialized to zero or required no initialization. There is no general
> guarantee that variables will all be moved into a separate category, and even
> if they were, the key is not "global" but "static" objects.
>
> The real question, I guess, is the didactic benefit. Does this explanation
> help prepare the user to understand the coming text?
It seems from his sales figures and positive reviews that it has. Many
of the negative reviews were the result of a coordinated attack that
foreshadowed the meanKids attack on Kathy Sierra: many of the negative
reviews are by people who know nothing about C.
>
> No, it doesn't.
>
> I'm waiting for something to compile.
In this day and age? My word.
It's clear, but like most experts you avoid the small shit while
sweeping on to the grand fallacy.
You see, you've completely failed to mention that in ordinary computer
science, an "object" is nothing of the sort: it is a collection of
procedures and data in which facts about the data are selectively
exposed and made changeable as needed, etc.
Thus, you are open to the very same type of charge you hurl at
Schildt! You say he confuses the runtime. You give a C meaning to the
word "object" which is valid only inside the C community without once
mentioning that it's a term of art.
C's "objects" aren't "objects" in ordinary CS parlance. This isn't to
say that you cannot refer to them as "objects" in a formal standards
manual which defines "object" as above. But you cannot and must not do
so in a textbook lest you confuse your reader...far more than Schildt.
Let him who is without sin cast the first stone.
>
> The above does not address VLA types, but then, they didn't exist in 1995. :)
>
> > I wonder why Schildt left the world of programming in order to write
> > books on the subject. Good programmers generally earn a great deal more
> > than technical authors, particularly the latter when they take the time
> > to make sure their work is technically correct as well as fluently written.
>
> FWIW: I earned substantially more money per hour doing technical writing,
> but it wasn't as stable. Books, not so much unless they're bestsellers,
> but bespoke technical writing, by someone who knows the field, can be very
> rewarding.
>
> I believe that Schildt probably has a genuine passion for communication. It's
> a shame he was not as devoted to learning as he was to teaching.
>
> -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!
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Francis Glassborow
> Open any book on Lisp (I recommend Abelson & Sussman's _Structure and
> Interpretation of Computer Programs_) and you will quickly learn that
> there is an important distinction between a recursive function and a
> recursive process, and that the former may (but does not necessarily)
> result in the latter.
>
> I'm getting the feeling that there are significant gaps in your
> knowledge of programming language theory.
Yes, but he is unaware of them, arrogant in his belief that he knows
better than any and all of us. Do not waste time trying to enlighten him
because he knows he is right and therefore that we are wrong.
spinoza1111
wrote:
> spinoza1111wrote:
> > If you investigate the disorganized "laundry lists" of charges put out
> > by Seebach and Feather, you discover that Schildt was libeled.
>
> Utter, contrived nonsense. The list of arguments brought forth against
> Schildt are about an order of magnitude more organized than what you've
> presented here. And the only attempted libel I can spot here is you
> trying to libel Mrs. Seebach and Feather. I say "attempted" because for
I have no criticism of Peter's Mom.
> it to be actual libel, there would have to be a non-negligible chance of
> people taking you seriously. Which there is not.
>
> > The
>
> > laundry lists are padded with trivia and matters of style and
> > interpretation.
>
> There's no interpretation involved. Schildt claims the C language works
> in certain ways, the C language definition clearly says otherwise.
What definition? What Gospel? K&R, K&R2, C89, C99? Matthew Mark Luke
or John?
>
> The most prominent example is Schildt's persistent claim that 'void'
> were the correct return type for the main() function in a hosted
> environment (at the time, that was MS-DOS), which it clearly is not.
"Hey Harv, are you into trivia?" "I'm talkin' to ya, ain't I?"
>
> > Most seriously, they criticise Schildt for implying
> > that the Standard requires functionality merely when Schildt is
> > explaining how C works by using concepts which are known to be
> > necessary to implement C.
>
> The error here is in the analysis of what is, and what is not "necessary
> to implement C". You appear to share Schildt's mistaken beliefs on
> those issues, including the necessity of a stack. Others know better,
> and said so in public. That's not libel, that's a necessary statement
> of fact.
This issue has been resolved (cf my cite of Michael Scott's
Programming Language Pragmatics). You CANNOT execute the code of
procedures with recursion IN THE GENERAL CASE without something with
stack functionality at a minimum (eg., something that "is" a stack).
You CAN optimize recursion out of what I believe to be a subset of
recursive programs with heavy, almost menstrual, flow analysis as in
my example of an Hello, World program that uses a function to call
printf...by inlining. But you cannot inline in the general case,
therefore the most straightforward way of implementing a runtime is a
stack, and Schildt clearly shows this!
In Adorno's words, you are well aware through introspection of "the
secret contour of your weakness", therefore you follow the mob to see
who's getting beaten up. The apparatus you used has amplified your
capabilities without changing your soul, therefore you came in here,
mein Herr, to see the blood and glass. Get out.
>
> You claim yourself to be a teacher of literature these days. So let me
> put this in a way that should match your mindset a little better: what
> on earth do you think qualifies _you_ to make statements about the
> meanings of a text that contradict not only the words of said text
> itself, but also the publicly available statements of its authors?
>
> And how many points would a student get in one of your courses who
> backs up his arguments with nothing more than "people say this", and "it
> has been said that"?
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Dag-Erling Smørgrav
> "The ANSI C standard defines only four functions for the dynamic allocation
> system: calloc(), malloc(), free(), and realloc(). However, this book
> examines several others that are in wide use -- especially in the 8086 family
> of CPU environments."
What, exactly, is "the 8086 family of CPU environments"?
I suspect that what he really means is "this book examines several other
functions that are provided by the compiler I'm most familiar with".
> Can anyone point to an instance of any of [the _freect(), _memavl(),
> _stackavail() functions] existing in another environment?
> "Especially" implies that these functions have ever existed elsewhere,
> which would sort of surprise me.
They seem to be Watcom-specific - so he may not understand C very well,
but at least he used a quality compiler.
DES
--
Dag-Erling Smørgrav - d...@des.no
Francis Glassborow
the inclination to explain them in detail. For the ordinary working
programmer it is enough to know where they happen and what the
restrictions are to code between successive sequence points.
Francis Glassborow
the inclination to explain them in detail. For the ordinary working
programmer it is enough to know where they happen and what the
restrictions are to code between successive sequence points.
Seebs
>> "The ANSI C standard defines only four functions for the dynamic allocation
>> system: calloc(), malloc(), free(), and realloc(). However, this book
>> examines several others that are in wide use -- especially in the 8086 family
>> of CPU environments."
>
> What, exactly, is "the 8086 family of CPU environments"?
>
> I suspect that what he really means is "this book examines several other
> functions that are provided by the compiler I'm most familiar with".
To be fair, in 1995, I think all the widely available 80x86 systems were
at least at a hardware level reasonably capable of using the old segmented
model.
>> Can anyone point to an instance of any of [the _freect(), _memavl(),
>> _stackavail() functions] existing in another environment?
>> "Especially" implies that these functions have ever existed elsewhere,
>> which would sort of surprise me.
>
> They seem to be Watcom-specific - so he may not understand C very well,
> but at least he used a quality compiler.
Which is odd, because elsewhere he generally referred to things from the
Microsoft compiler family.
Could be he was using two compilers to make sure everything he checked out
was portable...
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
> On 2009-09-12, Dag-Erling Smørgrav <d...@des.no> wrote:
>
> > For MS-DOS, modulo your point about global vs. static: yes. IIRC,
> > static variables that were not explicitly initialized were allocated by
> > the simple expedient of raising the bottom of the heap at program
> > startup. MS-DOS being what it was, most of this was done by the
> > compiler's runtime library, not by the operating system.
>
> Sure. Perfectly reasonable.
>
> I think I had a compiler where they were handled by the equally simple
> expedient of simply having space for them mixed in with code that came
> from near where they were compiled, so:
>
> int foo(void) { ... }
> int x;
> int bar(void) { ... }
>
> would yield a file containing three top-level labels, one named foo, one
> named bar, and one named x... So at link time, they had sequential addresses.
I'll alert the media. Such "global" or "static" variables don't
usually get saved in the stack, so what does their existence prove?
Furthermore, they are almost never needed...programming ability being
inverse wrt the number of "global" or "static" variables used, as well
as the number of "buffers".
In old Cobol, all variables were "global" or "static". I use the
disjunction because no matter what you say, the words have been used
interchangeably...although the property of being known to all
functions at compile time ("global") is distinct from being in a
region of memory that is not saved in the stack and that contains
values available to all functions at run time.
Therefore, competent Cobol programmers would use an Hungarian style
prefix for individual procedures of Cobol (called paragraphs
barbarously enough) and the variables used only by those procedures.
It should be noted that "competent Cobol programmers" of the 1970s
were rare, as rare as men who, according to Bismarck, actually
understood the Schleswig-Holstein question: Bismarck said their were
only two, one being he, and the other being a Danish professor who
went mad. The only competent Cobol programmer I knew in the 1970s was
myself.
>
> > Your paraphrase of his discussion of memory models is not entirely
> > accurate.
>
> I am frankly surprised that it's even recognizeable. I had the good fortune
> to only once in my entire programming career have to deal with such an issue;
> after about four hours of careful study and debugging, we checked a box
> in Visual Studio (or whatever it was) and things started working.
Well, what this story communicates is merely the sort of wearisome
anti-intellectualism and incuriosity that caused me to leave the field
after thirty years, since I was tired of vigils with the incurious,
trying stuff out sullenly and randomly. Let's see if I can get this
straight: having been mollycoddled, you were told by your employers to
use Microsoft software and this depressed and offended you. You sat
around trying things in a rather passive-aggressive way and then you
checked a box. You mock Visual Studio when I would ascribe the
problems you had to passive-aggressiveness.
Early programmers didn't have the luxury of passive-aggressive
resistance to unfashionable software and hardware. Early programmers,
you young whippersnapper, had to walk to the computer centre in the
snow uphill both ways. For this reason, one seldom saw the sullenness,
anti-intellectualism, and incuriosity that seems to be the fashion wrt
Herb's platforms, which were MS-DOS and today are Windows. And it was
only in the 1980s did I see the deliberate trashing of reputations
which is the direct result of sullenness, anti-intellectualism, and
incuriosity.
"Trashing" a person is the deliberate and malignant effort to find an
interpretation of everything he says which can be used can be used
against him. "Especially" here means that while the above functions
were developed on MS-DOS, there is no reason why they could not or do
not appear on other platforms. It's not a claim that they are part of
K&R C. Quite the opposite: Herb is taking pains to point out where
these functions come from.
Herb never solved Dijkstra's challenge, how not to make a mess of it,
which I regard as important as Hilbert's challenges to math made
earlier in the 20th century. However, neither John Hennessy of MIPS
fame, nor guys like you, have done so, either. And because of the
greater prestige and power of your apparatus, you have arguably done
far more damage, in your case with the C99 standard.
"But far from finding anything inimical in the prohibitions on
thinking, the candidates - and all scientists are candidates for posts
- feel relieved. Because thinking burdens them with a subjective
responsibility which their objective position in the productive
process does not allow them to meet, they renounce it, shiver a bit,
and run to join their opponents. Dislike of thinking rapidly becomes
incapacity for it: people who can effortlessly discover the most
sophisticated statistical objections when it is a question of
sabotaging a piece of knowledge, are unable to make ex cathedra the
simplest predictions. They hit out at speculation and in it kill
common sense. The more intelligent of them suspect the sickness of
their intellectual powers, since it first appears not universally but
in the organs whose services they sell. Many wait in fear and shame
for their defect to be discovered. But they all find it publicly
acclaimed as a moral achievment, and see themselves recognized for a
scientific asceticism which to them is none, but the secret contour of
their weakness. Their rancour is socially rationalized with the
argument: thinking is unscientific. At the same time, their mental
power has, in a number of dimensions, been prodigiously increased by
control mechanisms. The collective stupidity of research technicians
is not simply an absence or regression of intellectual faculties, but
a proliferation of the thinking faculty itself, which consumes thought
with its own strength."
-TW Adorno, Minima Moralia, 1948
>
> -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!
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
No they aren't, nor have I said they are.
> the inclination to explain them in detail. For the ordinary working
There is no need, thanks. The Wikipedia entry and the standard explain
them. Your tuition is not wanted here.
> programmer it is enough to know where they happen and what the
> restrictions are to code between successive sequence points.
They're not, in fact, restrictions save on knowledge of what can
happen, and in what order, between sequence points.
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
> have an appropriate newsgroups line in your header for your mail to be seen,
> or the newsgroup name in square brackets in the subject line. Sorry.- Hide quoted text -
>
> - Show quoted text -
Dag-Erling Smørgrav
> Dag-Erling Smørgrav <d...@des.no> writes:
> > What, exactly, is "the 8086 family of CPU environments"? I suspect
> > that what he really means is "this book examines several other
> > functions that are provided by the compiler I'm most familiar with".
> To be fair, in 1995, I think all the widely available 80x86 systems were
> at least at a hardware level reasonably capable of using the old segmented
> model.
Absolutely, but there is still no such thing as "the 8086 family of CPU
environments"; at least, I've never heard of anything called a "CPU
environment".
> > They seem to be Watcom-specific - so he may not understand C very
> > well, but at least he used a quality compiler.
> Which is odd, because elsewhere he generally referred to things from
> the Microsoft compiler family.
Maybe they originated with Microsoft, and Watcom implemented them for
compatibility? They weren't availble in Borland C, though (I still have
my dead-tree manuals).
DES
--
Dag-Erling Smørgrav - d...@des.no
Jonathan Leffler
>Wikipedia contains the claim that any recursive function can be
>iteratively expressed. I do not think this is true, for example, in
>the case of recursive descent parsing. If memory serves, my old
>MacDonald-Elsevier "Monograph in Computer Science" on "Recursive
>Programming" contained the contrary claim that not all functions that
>can be calculated recursively can be calculated iteratively, and gave
>as an example, if memory serves, Ackermann's function.
I used to have a book on Fortran (as in Fortran 66) programming
techniques, and it was from that book that I learned of the existence of
Ackermann's function - and there was an illustration of how to implement
it in a language that did not have stacks for local function variables
(you got undefined behaviour if you did a recursive function call,
whether directly or indirectly). I don't have the book any more - too
many house moves.
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2008.0229 -- http://dbi.perl.org/
publictimestamp.org/ptb/PTB-7125 whirlpool 2009-09-12 15:00:04
DE6E6D3D76EE030B5BD4828BF957B9985A00E391A67598743E9817C35DD0298AB56CE5
DC1A728D03E1F6CE1902480DAC29ACA7060E86104BF9406C4CD2A93D0
Hans-Bernhard Bröker
> On Sep 12, 3:06 pm, Francis Glassborow
> <francis.glassbo...@btinternet.com> wrote:
>> spinoza1111wrote:
>>> A sequence point occurs at runtime, at an SP
>>> operator which guarantees that operators which have preceded it are
>>> executed.
>> Most sequence points are not operators.
> No they aren't, nor have I said they are.
Ah, but you did! Look above at your own statement: "A sequence point
occurs [...] at an SP operator". And since there's no qualifier to
limit what that statement applies to, you didn't only claim that for
most, but for all sequence points.
One might have assumed that a literature teacher must have at least the
capability to interpret his own writing correctly. There goes that hope
down the drain.
> Your tuition is not wanted here.
Wanted, maybe not. But it's desperately needed.
Hans-Bernhard Bröker
> On Sep 12, 5:37 am, Hans-Bernhard Br�ker <HBBroe...@t-online.de>
> wrote:
>> spinoza1111wrote:
>> There's no interpretation involved. Schildt claims the C language works
>> in certain ways, the C language definition clearly says otherwise.
> What definition? What Gospel? K&R, K&R2, C89, C99? Matthew Mark Luke
> or John?
Doen't really matter. Schildt is at odds with every one of them.
> This issue has been resolved (cf my cite of Michael Scott's
> Programming Language Pragmatics).
No it hasn't. You believe it to be resolved, but from where I sit it
clearly appears everyone else is just as sure you're wrong as they've
been from the beginning.
> You CANNOT execute the code of
> procedures with recursion IN THE GENERAL CASE without something with
> stack functionality at a minimum (eg., something that "is" a stack).
I'm afraid you underestimate the level of detail of what Schildt
actually claimed was necessary in a C runtime environment.
Function return addresses and automatic variables need some mechanism
that fits the abstract data type of a LIFO. A stack is a particular
implementation of that abstract data type, and Schildt claimed that
exactly that implementation was necessary for a C runtime. It's not.
> You CAN optimize recursion out of what I believe to be a subset of
> recursive programs with heavy, almost menstrual, flow analysis as in
> my example of an Hello, World program that uses a function to call
> printf...by inlining. But you cannot inline in the general case,
> therefore the most straightforward way of implementing a runtime is a
> stack, and Schildt clearly shows this!
No. Schildt claimed (by lack of mentioning any alternative) that a
simple, linear, contiguous stack were the _only_ way of implementing
this requirement. And he's quite clearly wrong about that.
> In Adorno's words, you are well aware through introspection of "the
> secret contour of your weakness", therefore you follow the mob to see
> who's getting beaten up. The apparatus you used has amplified your
> capabilities without changing your soul, therefore you came in here,
> mein Herr, to see the blood and glass. Get out.
Oh, so now you're running out of real arguments, you're lowering
yourself to a (thinly veiled, but still) racist line of argumentation.
Go to hell. EoD.
Seebs
> Oh, so now you're running out of real arguments, you're lowering
> yourself to a (thinly veiled, but still) racist line of argumentation.
What amazes me is that I originally thought this guy was my other kook --
someone on a BBS who had similar inability to comprehend C, was furious
with me, and eventually reverted to making racist anti-German remarks
at length because he thought this would make his point.
And at first I thought "there can't be two of them", but actually there are.
(Actually, just to give you some sense of scope, spinoza1111 appears to be
a better programmer than the other one.)
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
spinoza1111
wrote:
> spinoza1111wrote:
> > On Sep 12, 5:37 am, Hans-Bernhard Bröker <HBBroe...@t-online.de>
Excuse me, it isn't racist to link behavior to the Holocaust, to
Kristallnacht. The Holocaust, and Kristallnacht, occured in large
measure because the clerical lower middle class voted just enough for
the Nazis, who then gave them social and employment programs between
1933 and 1938 which secured Hitler's power.
Theodore Adorno courageously returned as a "Jew" to the Federal
Republic and asked why there was such a silence about the Holocaust.
There was because it became unfashionably "racist" to speak of German
behavior of the Nazi period, as if the mere appearance of the symbol
"German" alongside description of what happened, and how to prevent it
happening again, was racism and not moral seriousness.
I am German-American. My ancestors probably left Germany because of
nasty, small-minded Krauts who wouldn't give us jobs or the chance to
own or improve ducal land, and beat us up when we protested in 1848.
My uncle was killed leading Japanese American troops against Germans
in Italy in 1945, because after 1848 you people were for the most part
silent about who was a member of your national community, allowing
Hitler to rise to power by promising your grandfathers that they could
get the Jews' jobs and houses.
Racism begins on the ground, in blood and glass. It started when
Prussian census-takers gave ghetto Jews patronyms like "lover
boy" (Liebermann) even as you creeps think its funny to use
"Bullschildt" and "Nilgewater". Racism begins when your hate is
marshaled.
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Gordon Burditt
>"Bullschildt"
I fail to understand how "Bullschildt" is racist. Does anyone
seriously think Schildt is of the bovine species? That wouldn't
be racism, that would be specism. The uses of the term I have seen
(particularly in clc or clc.moderated) have been applied to his
writing, not to him personally, and because to the number and
severity of errors in his book. Do you believe that a book can
have race?
>Racism begins when your hate is
>marshaled.
Racism begins when you believe that humanity is divided into
some division called "races".
spinoza1111
No, they provide the functionality of the stack with an overelaborate
mechanism. You need two collections to do it: the queue and the
cache.
Automata theory shows that you can parse Chomsky 2 with other things
beyond stacks, but that the stack is the minimal data structure
needed. When you are interpreting function call you are parsing
Chomsky 2 in the form of expressions like a, b, c(d, f, g(h)), and
this has been shown to require ONE data structure: the stack. That it
can be done using TWO is Trivia and not interesting.
The abstract stack remains the (mathematically) simplest way of doing
things, which is why it's important to teach it. Schildt correctly
used an example or instance of the abstraction to show how C is
executed, and his audience knows that this isn't the only way to do
things.
If a teacher in evening school draws Euclid's proof that the square of
the hypotenuse is equal to the sum of the squares of the opposing
sides, the thoughtful student with a day job in computer graphics may
well ask whether we should measure the triangle and the three squares
inclusive of their thick borders as drawn on the whiteboard. Even
Euclid may have been challenged, since you get different areas for a
figure depending on whether you measure from the inside, outside, or
centreline of the borderline, which must be drawn to be visible, at a
non-zero thickness.
The putatively most accurate choice would be the centreline: but then
you need a separate algorithm to determine it. I am not being
frivolous: Derrida raised these issues early in his career with
respect to geometry.
But nonetheless, Euclid's auditors, as well as most students in an
evening class in remedial geometry, are able to disambiguate the non-
existent reality from its messier idealization. Seebach believes they
cannot and needs to have more respect for Schildt's audience.
The illusion is that Higher Mathematics, like the Higher Sodomy,
should be done only by the ruling class lest the *canaille* get ideas
Above Their Station. But Bertrand Russell discovered that there's no
such thing, mathematically, as the Higher Mathematics in the sense
that Higher Mathematics is logic plus existence assertions. His work
is dated, in part because its democratic implications bothers Higher
Mathematicians and they won't pursue or improve on foundations in this
sense.
No, I'm NOT saying that Higher Math is a conspiracy. I am saying that
the way we think about mathematics is partly determined by class
relations.
For example, when the New Math violated the class divide by applying
foundations, considered part of the Higher Sodomy, to the education of
children, an enormous *kulturkampf* was unleashed based on untested
claims that it confused kids. But after the New Math was discredited
and the requisite number of careers and reputations destroyed, Seymour
Papert discovered, or rediscovered, the simple fact that kids are
better at "advanced" math than grownups, where in Papert's case, the
advanced math was programming in Logo.
Papert was discredited in turn in the name of "the basics" of drill,
and as a result mathematical literacy continues to decline. Innumeracy
was the empirical evidence of the failure of the traditional approach
of repetitive drill in algorithms and the empirical evidence of
Papert's success was rejected along with the empirical evidence of
success in presenting sets in Catholic schools as part of math.
This was because if children could understand math, then workers could
also, and could have greater control of workplaces. This was
unacceptable to owners.
Schildt, in using the simple stack metaphor, illustrated concretely as
any professor uses concrete blackboard pictures to illustrate theory,
had like Prometheus stole the fire of the gods. Those of you who
stayed awake during Western Civ may remember the story. Aeschylus'
point was that despite the fact that humanity had benefited from
Prometheus' crime, he nonetheless had to suffer.
We re-enact myths in daily life. Therefore Morris Cohen of NYU
launched a vicious and personal campaign against ordinary teachers for
introducing New Math. Papert was attacked. And now Schildt.
In the movie Good Will Hunting, Matt Damon demonstrates that a Harvard
graduate student has not understood, but memorized and was
plagiarizing the exact words of an historian, speaking them to Damon's
Will Hunting to try to impress a girl played by Minnie Driver. Damon
mocks the grad student for paying 200,000 for knowledge he could have
gotten for "late chahges" at the public library.
I'm afraid that Seebach has dropped a lot of cash on an education, or
his father has, and this is the reason why he was so offended that
Herb was revealing "the secret of the stack" to people in junior
colleges. Since I used to be an adjunct professor at DeVry, I
acknowledge that these people are NOT well-educated in computer
science, and I think that it shows in their praxis. But the answer
isn't censorship of their textbooks. Quite the opposite.
Seebach has a strange educational theory in which the teacher must be
silent or speak the truth at all times, describing arcana such as
Seebach's examples. I hope he doesn't teach part time, because people
learn through stories.
In 1970 I was told that Roosevelt University's IBM 1401 stored 64
different characters in six bit units, couldn't add and didn't try,
was decimal, and demarcated operands using an extra "word" bit. But
this didn't cause me to forget what was written in the main text about
the IBM 7094's binary fixed length words and registers (no stack).
Instead, it made me angry that a left-wing, labor-oriented school open
to minorities, unlike the then white and male University of Chicago,
had to make do with a machine considered a print server at the
University of Chicago. But taking comfort from a reading of Turing, I
boldly went where no man had gone before, developing a data base for
the 1401 (which used a stack) and debugging Fortran. Fun job, for
which my reward was Promethean, since the controller, angry at my long
hair, refused to credit my work after I left.
>
> DES
> --
> Dag-ErlingSmørgrav- d...@des.no
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
spinoza1111
> >even as you creeps think its funny to use
> >"Bullschildt"
>
> I fail to understand how "Bullschildt" is racist. Does anyone
> seriously think Schildt is of the bovine species? That wouldn't
> be racism, that would be specism. The uses of the term I have seen
> (particularly in clc or clc.moderated) have been applied to his
> writing, not to him personally, and because to the number and
> severity of errors in his book. Do you believe that a book can
> have race?
It is proto-racist in that racist politicians marshal and organize
adolescent feelings and behavior. I believe it's worse to make fun of
a man's last name than to use swearwords, since it hurts the feelings
of members of his extended family.
>
> >Racism begins when your hate is
> >marshaled.
>
> Racism begins when you believe that humanity is divided into
> some division called "races".
You'd do well to read Sartre and Adorno on this matter. The hatred
precedes the false belief.
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
Dag-Erling Smørgrav
> If a teacher in evening school draws Euclid's proof that the square of
> the hypotenuse is equal to the sum of the squares of the opposing
> sides,
EPIC FAIL
> Even Euclid may have been challenged, since you get different areas
> for a figure depending on whether you measure from the inside,
> outside, or centreline of the borderline, which must be drawn to be
> visible, at a non-zero thickness.
Ceci n'est pas une pipe. I was taught in school that when working out a
geometric proof, one should draw intentionally incorrect freehand
sketches, rather than unintentionally inaccurate and misleading ruler-
and-compass figures. I'm pretty sure Pythagoras was well aware of the
difference between reality and its imperfect material reflection, and I
suspect that he too drew his figures freehand - be it with a quill on
paper or with a stick in the sand.
> The illusion is that Higher Mathematics, like the Higher Sodomy,
> should be done only by the ruling class lest the *canaille* get ideas
> Above Their Station.
This discussion has long since moved from "entertaining" to "absurd",
and I believe it just crossed to the other side. I do not feel inclined
to follow.
DES
--
Dag-Erling Smørgrav - d...@des.no
--
Seebs
> This discussion has long since moved from "entertaining" to "absurd",
> and I believe it just crossed to the other side. I do not feel inclined
> to follow.
It certainly does challenge us to come up with a possible way of interpreting
these posts in which they make any kind of sense.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Keith Thompson
> spinoza1111 <spino...@yahoo.com> writes:
[snip]
> This discussion has long since moved from "entertaining" to "absurd",
> and I believe it just crossed to the other side. I do not feel inclined
> to follow.
I am repeatedly dismayed by how long it takes people to arrive at
this conclusion.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Seebs
> I am repeatedly dismayed by how long it takes people to arrive at
> this conclusion.
As with most kooks, he starts out sounding like he has a point and just isn't
doing a good job of communicating it.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Clive D. W. Feather
<usenet...@seebs.net> wrote:
>>> The above does not address VLA types, but then, they didn't exist in
>>> 1995. :)
>
>
>Yeah, but it's worth noting that they have different rules. If you declare
>an automatic object of non-VLA type, its lifetime begins as soon as you enter
>the block containing the declaration; VLAs have a lifetime beginning at their
>declaration, rather than at the top of the block. Since C99 allows mixed
>declarations and code, this is actually potentially significant.
The reason we did this was so that the space required for VLAs could be
handled in a LIFO manner. Without this restriction, you can come up with
some awkward memory management problems when facing code like:
int i = 1;
loop:
int v1 [i], v2 [i * 2];
// ...
if (++i < 1000) goto loop;
--
Clive D.W. Feather | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
Francis Glassborow
> On Sep 13, 5:59 pm, gordonb.3p...@burditt.org (Gordon Burditt) wrote:
>>> even as you creeps think its funny to use
>>> "Bullschildt"
>> I fail to understand how "Bullschildt" is racist. Does anyone
>> seriously think Schildt is of the bovine species? That wouldn't
>> be racism, that would be specism. The uses of the term I have seen
>> (particularly in clc or clc.moderated) have been applied to his
>> writing, not to him personally, and because to the number and
>> severity of errors in his book. Do you believe that a book can
>> have race?
>
> It is proto-racist in that racist politicians marshal and organize
> adolescent feelings and behavior. I believe it's worse to make fun of
> a man's last name than to use swearwords, since it hurts the feelings
> of members of his extended family.
>>> Racism begins when your hate is
>>> marshaled.
>> Racism begins when you believe that humanity is divided into
>> some division called "races".
>
> You'd do well to read Sartre and Adorno on this matter. The hatred
> precedes the false belief.
That they claim that does not make it so. I very much doubt that the
slave owners of the Southern States hated their slaves (they just
considered them a lesser species), but I will lay long odds that quite a
few slaves hated their owners. I think you are confusing anti-Semitism
with racism.
However, that notwithstanding, it has nothing to do with criticism of
the technical writing and the accuracy thereof of Herbert Schildt.
Elsethread you seem to be proposing that a reviewer is not entitled to
highlight errors made by an author because that might impact on his
reputation.
Peter, Clive and myself have all listed specific errors in Schildt's
writing. You seem to be taking the view that these are unimportant
because those errors represented 'best practice' at the time. While they
might have represented common practice at the time they certainly did
not represent best practice. There were many competent programmers
writing C for a multitude of systems.
During the 1980s many universities taught Pascal. On leaving university
many graduates discovered that the world of employment wanted C
programmers. They did a rapid read of a couple of texts (often K&R) and
then started to write C from a Pascal mindset.
One of the problems with learning C from K&R is that it does not mention
such things as lint. The assumption was that every reader would rapidly
discover these tools in his work environment. Unfortunately such tools
did not make the transition from Unix to MSDOS (they should have done,
and there was no reason for them no to have done other than the
ignorance of some implementers). The result was a common practice that
was very dangerous. No competent programmer would have written code with
the potential for buffer overruns, but many programmers did just this
and then, at a latter date, blamed C rather than their lack of competence.
IMO a major cause of bad C programming was this transfer from a highly
protective language (Pascal) to one that trusted the programmer (C). The
early books from Schildt exacerbated this problem. Yes that is just my
opinion but it has the merit of not conflicting with the evidence.
David Thompson
<usenet...@seebs.net> wrote:
> On 2009-09-11, spinoza1111 <spino...@yahoo.com> wrote:
> >> Lemme be blunt, though: I don't even remember most of this stuff. I
> >> think it's been ten years since I last looked at the Schildt books. I
> >> remember being utterly gobsmacked to find an example using <> instead
> >> of != in a book nominally about C, so I went and grabbed the book,
>
> > Sounds like a trivial reason to be gobsmacked.
>
> Really?
>
> There has never been, to the best of my knowledge, any C-like language with
> that operator in it. I didn't even realize what it was until someone who
> used to use Pascal told me it was used for != in some variants of Pascal.
>
All variants of Pascal, TTBOMK. And Ada, which in syntactic flavor is
pretty close to Pascal, but also (re)uses this token for other things
besides the not-equal operator. And BASIC. And SQL.
But not PL/I IIRC, or Fortran>=90. Or C++ (of course). Or Java, perl,
awk, *sh which were at least C-influenced if not actually C-like.
Keith Thompson
> On Thu, 10 Sep 2009 23:26:16 -0500 (CDT), Seebs
> <usenet...@seebs.net> wrote:
>
>> On 2009-09-11, spinoza1111 <spino...@yahoo.com> wrote:
>
>> >> Lemme be blunt, though: I don't even remember most of this stuff. I
>> >> think it's been ten years since I last looked at the Schildt books. I
>> >> remember being utterly gobsmacked to find an example using <> instead
>> >> of != in a book nominally about C, so I went and grabbed the book,
>>
>> > Sounds like a trivial reason to be gobsmacked.
>>
>> Really?
>>
>> There has never been, to the best of my knowledge, any C-like language with
>> that operator in it. I didn't even realize what it was until someone who
>> used to use Pascal told me it was used for != in some variants of Pascal.
>>
> All variants of Pascal, TTBOMK. And Ada, which in syntactic flavor is
> pretty close to Pascal, but also (re)uses this token for other things
> besides the not-equal operator. And BASIC. And SQL.
>
> But not PL/I IIRC, or Fortran>=90. Or C++ (of course). Or Java, perl,
> awk, *sh which were at least C-influenced if not actually C-like.
Ada's not-equal operator is "/=".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"