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.