In the matter of Herb Schildt: the question of a "bad" book

[Kenny McCormack]

socialism. Most economies are mixed to some extent. Even the US has
social medicine now...

No, it doesn't. We've taken one very small step away from a system of
total corporate welfare for insurance companies. Hardly the right wing
boogeyman some would make it out to be.

--

No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

 

[Seebs]

There's a difference between books on computer science, and books
which document something artificial. A lot of computer books are in
the latter category, including descriptions of how to use various
Windows appliactions, descriptions of chip architecture, and language
primers Since computer technology is constantly changing, these books
tend to go out of date. C is an unusually stable language, but the
problem is that you can't do many of the things you want to do with
just the core language, so often a primer will document a particular
compiler or target platform.

C in particular has the interesting trait that, while you often need to
go outside the core language at some point, the bulk of the code in any
given project is usually perfectly ordinary standard C which merely makes
calls to a few functions which are outside the core language.

However, even if we granted the "particular target platform" defense (and
I don't; books purporting to cover a particular platform or compiler are
the exception rather than the rule), Schildt's book would still be crap,
because he got the I/O model wrong, got structure layout wrong, and so on.

The complaint here isn't just that what he says isn't necessarily true
everywhere; it's that much of it isn't true *anywhere*.

I don't think it is really possible to write a classic that is
essentially a description of someone else's invention. As the Soviets
found with their "production novels", some themes just don't lend
themselves to high art.

Perhaps, but many authors have written books on C which are not particularly
error-prone, and not all of them were dmr. Kim King's _C: A Modern Approach_
is a very solid book, well-written, clear, and frankly I think it's a better
book from which to learn C than K&R. H&S is generally well-regarded. These
people don't seem to have trouble writing well and clearly about someone
else's invention.

I've done a whole lot of technical writing, and what matters is not who
invented it, but whether you understand both the material and the audience.

-s

 

[Ben Bacarisse]

There's a difference between books on computer science, and books
which document something artificial. A lot of computer books are in
the latter category, including descriptions of how to use various
Windows appliactions, descriptions of chip architecture, and language
primers Since computer technology is constantly changing, these books
tend to go out of date. C is an unusually stable language, but the
problem is that you can't do many of the things you want to do with
just the core language, so often a primer will document a particular
compiler or target platform.

I don't see how describing the faults of a large class of CS books
invalidates my point. Some are better than this, even some of those
that are about someone else's invention.

I note that you make no remarks about the book in question; only general
statements about a whole class of dull CS books. Are you hinting that
C:TCR is in this category -- that is was rapidly obsolete and that it
documents a particular compiler or platform? Maybe you are hinting that
it is not one of these. I can't tell. At the moment your position
seems to be that one should have rather low expectations of C books and
this makes criticism of any of them pointless.

I don't think it is really possible to write a classic that is
essentially a description of someone else's invention. As the Soviets
found with their "production novels", some themes just don't lend
themselves to high art.

Thank goodness, then, that no one has made that claim.

 

[Tim Streater]

Welcome to the light side, Tim.

I have no problem with Keith putting me in his kill-file. I said some
months ago that I was here largely for the beer. Occasionally (as when I
rebutted Spinny's absurd attempts to claim that C is not portable) I'll
refer to my experience of using C 20 years ago. So by and large my posts
here are going to be off-topic.

 

[Kenny McCormack]

I have no problem with Keith putting me in his kill-file. I said some

N.B. Kiki only *pretends* to have a killfile. This was proven well by
HfC a while back. So, like me, welcome to Kiki's virtual killfile.

months ago that I was here largely for the beer. Occasionally (as when I
rebutted Spinny's absurd attempts to claim that C is not portable) I'll
refer to my experience of using C 20 years ago. So by and large my posts
here are going to be off-topic.

That's cool. As I say, welcome.

P.S. If you accept both of the following premises, you are inexorably
led to the conclusion that C is not portable (in the CLC sense of the term):

1) To be portable (in the CLC sense of the term), it must be
strictly conforming (or whatever term the regs use).
2) Very few useful, real world programs are "strictly conforming".
(That is, use no extensions not guaranteed by the standard(s))

With, of course, exception granted for the very few useful, RW programs
that *are* "strictly conforming".

--

No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

 

[Tim Streater]

P.S. If you accept both of the following premises, you are inexorably
led to the conclusion that C is not portable (in the CLC sense of the term):

1) To be portable (in the CLC sense of the term), it must be
strictly conforming (or whatever term the regs use).

Strictly conforming to what? In the 1985-1988 timeframe when we were
coding that stuff, it conformed to K&R, and the compilers we used under
VMS and VM/CMS (can't now remember if they were vendor-supplied or not).

That was good enough for me at the time. To interface to OS functions we
wrote the thinest possible layers in assembler for each platform.

 

[Kenny McCormack]

Strictly conforming to what? In the 1985-1988 timeframe when we were
coding that stuff, it conformed to K&R, and the compilers we used under
VMS and VM/CMS (can't now remember if they were vendor-supplied or not).

That was good enough for me at the time. To interface to OS functions we
wrote the thinest possible layers in assembler for each platform.

Understand that my comments are only in regard to the dynamics of this
newsgroup. No external reality is implied or to be inferred.

(I didn't write the rules; I'm just conforming to them. The regs were
the ones who divorced this newsgroup from reality. Why? You'll have to
ask them. In any case, the definition of "SC" that is in force around
here is "conforming to ANSI/ISO C89/90". In particular, note that C99
and any later standards are viewed with suspicion at best.)

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

 

[Seebs]

Strictly conforming to what?

Talking to Kenny is only marginally more productive than talking to Spinny.

In general, the real division isn't "strictly conforming" but "what is
your question really about". Consider the infamous:

if (fd = open("foo", O_RDONLY) != -1) {
}

This behaves surprisingly to many users. However, while it does include
a UNIX system call, it has nothing to do with UNIX. The problem is just
as visible in:
if (ret = fn_returns_neg1_on_fail() != -1) {
}

and has nothing to do with open(), and a great deal to do with precedence.

The underlying question is not whether your code is strictly conforming, but
whether the topic of your discussion is the C language.

-s

 

[Keith Thompson]

The underlying question is not whether your code is strictly conforming, but
whether the topic of your discussion is the C language.

And "strictly conforming" is very often a red herring anyway. C99 4p5:

A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.

Very few real programs are strictly conforming, and plenty of programs
are portable without being strictly conforming.

Hmm. A footnote attached to that paragraph says:

A strictly conforming program can use conditional features (such as
those in annex F) provided the use is guarded by a #ifdef
directive with the appropriate macro. For example:

#ifdef __STDC_IEC_559__ /* FE_UPWARD defined */
/* ... */
fesetround(FE_UPWARD);
/* ... */
#endif

Which is true, but I would think that if the program's output
depends on the rounding mode (which it presumably does; otherwise
why bother setting it?) then it's not strictly conforming.

 

[Seebs]

A strictly conforming program can use conditional features (such as
those in annex F) provided the use is guarded by a #ifdef
directive with the appropriate macro. For example:

#ifdef __STDC_IEC_559__ /* FE_UPWARD defined */
/* ... */
fesetround(FE_UPWARD);
/* ... */
#endif

Which is true, but I would think that if the program's output
depends on the rounding mode (which it presumably does; otherwise
why bother setting it?) then it's not strictly conforming.

The obvious reason to bother setting it is that it allows you to write
a strictly conforming program which calls fesetround(FE_UPWARD).

.... Which is to say, I have no clue. Looks pointless to me. I suspect
the *intent* is to say "don't depend for your correctness on implementation
defined behavior".

Which is to say:

int a[UCHAR_MAX];
a[CHAR_MAX] = 0;

this would not be strictly conforming, because, depending on an
implementation-defined choice, it may invoke undefined behavior. The intent,
I think, is that
printf("%d\n", (int) CHAR_MAX);
is not really strictly conforming, but everyone knows it has to work.

-s

 

[chrisbazley]

Hi Jacob,

I think C is a GOOD language, maybe because I detest fashion and "old fashioned" stuff makes it even
more interesting for me. I prefer simplicity and power, two things that modern languages avoid like
the pest.

Your posting is one of the most perspicacious that I have seen on this
group for a long time - especially your point about fashion. I like C
for the same reasons as you and think it will probably always have a
niche.

[snip]

OK, the regulars like those discussions. They can go on destroying the C language and this group as
they have been doing for years. They will produce hundreds of messages about Schild, Wikipedia
biographies or whatever.

I must shamefacedly admit that I derive occasional amusement from
witnessing these ridiculous flame wars, although I wouldn't count
myself a regular. On that note, I'm off to do something more
productive!

Cheers,

 

[spinoza1111]

[...]

The underlying question is not whether your code is strictly conforming, but
whether the topic of your discussion is the C language.

And "strictly conforming" is very often a red herring anyway.  C99 4p5:

    A strictly conforming program shall use only those features
    of the language and library specified in this International
    Standard. It shall not produce output dependent on any
    unspecified, undefined, or implementation-defined behavior,
    and shall not exceed any minimum implementation limit.

Very few real programs are strictly conforming, and plenty of programs
are portable without being strictly conforming.

This usually where the "cynical Puritan" winds up: preaching some
ridiculous theory or isomorph of salvation which is unattainable and
senseless. The point in C "standardization" was to destroy competence
and the ability to know in order to increase the profits of vendors,
and it results in this useless bullshit...theology for the half-
educated.

 

[spinoza1111]

Talking to Kenny is only marginally more productive than talking to Spinny.

In general, the real division isn't "strictly conforming" but "what is
your question really about".  Consider the infamous:

        if (fd = open("foo", O_RDONLY) != -1) {
        }

This behaves surprisingly to many users.  However, while it does include
a UNIX system call, it has nothing to do with UNIX.  The problem is just
as visible in:
        if (ret = fn_returns_neg1_on_fail() != -1) {
        }

and has nothing to do with open(), and a great deal to do with precedence..

Wow. Precedence. Deep!

And no substantive discussion, just the grave (and ridiculous)
implication that Petey knows SO much that he is a bit overwhelmed, and
cannot actually divulge the Eleusinian mystery lest like Schildt he
blaspheme, and be torn apart by dogs.

The underlying question is not whether your code is strictly conforming, but
whether the topic of your discussion is the C language.

Meaning "I know what you are talking about".

 

[spinoza1111]

    A strictly conforming program can use conditional features (such as
    those in annex F) provided the use is guarded by a #ifdef
    directive with the appropriate macro. For example:

        #ifdef __STDC_IEC_559__ /* FE_UPWARD defined */
            /* ... */
            fesetround(FE_UPWARD);
            /* ... */
        #endif

Which is true, but I would think that if the program's output
depends on the rounding mode (which it presumably does; otherwise
why bother setting it?) then it's not strictly conforming.

The obvious reason to bother setting it is that it allows you to write
a strictly conforming program which calls fesetround(FE_UPWARD).

... Which is to say, I have no clue.  Looks pointless to me.  I suspect
the *intent* is to say "don't depend for your correctness on implementation
defined behavior".

Which is to say:

        int a[UCHAR_MAX];
        a[CHAR_MAX] = 0;

this would not be strictly conforming, because, depending on an
implementation-defined choice, it may invoke undefined behavior.  The intent,
I think, is that
        printf("%d\n", (int) CHAR_MAX);
is not really strictly conforming, but everyone knows it has to work.

-s

This is the Final Absurdity: that in C, there is in fact an
unattainable notion of "strictly conforming" which is not even useful
save as a club with which to beat the Nonconformists.

It's like the notion of the Puritan Elect taken to the extremes that
notion was in fact taken to in the 17th century. By the time the
Americans were through with that notion, they were burning women at
the stake.

 

[Peter Nilsson]

This is the Final Absurdity: that in C, there is in fact
an unattainable notion of "strictly conforming"

It's been defined since 1989 and it's far from unattainable.
In fact, there's quite a lot you can do with strictly
conforming code.

which is not even useful...

Even if restrictive, it's extremely useful. Whilst it applies
to programs as a whole, it is quite transferrable to modules,
or functions, or single statements, or even single expressions.

If you don't have _some_ gauge of what is well defined, then
you don't have a useful programming language. You can argue
whether there is a better gauge, but in 20+ years, no one
has produced one that satisfies all the people all of the time.

 

[Nick Keighley]

And "strictly conforming" is very often a red herring anyway.  C99 4p5:

    A strictly conforming program shall use only those features
    of the language and library specified in this International
    Standard. It shall not produce output dependent on any
    unspecified, undefined, or implementation-defined behavior,
    and shall not exceed any minimum implementation limit.

Very few real programs are strictly conforming, and plenty of programs
are portable without being strictly conforming.

<snipsnipsnip>


Dan Pop: "When was the last time you've implemented a real life
application as a strictly conforming program?"

Richard Heathfield: "About 20 minutes ago. It was a new, heavily
optimised pig-launching routine, which gets us a 70% range increase
on previous porcine aeronautic programs."
(posted on clc)

 

[Nick Keighley]

I would say that it is possible for books about C (or, indeed, any
technical subject in CS) to be written by authors who apply their skills
to other areas (in addition to the style and presentation).  The results
will usually be better books than those produced under the ethos
[pile-em-high-and-sell-em-cheap] you describe.

There's a difference between books on computer science, and books
which document something artificial.

computer science isn't artificial?

A lot of computer books are in the latter category,

books about "artificial" things?

I think you have an odd definition of artificial

from dict.com

Artificial \Ar`ti*fi"cial\, a. [L. artificialis, fr. artificium:
cf. F. artificiel. See Artifice.]
1. Made or contrived by art; produced or modified by human
skill and labor, in opposition to natural; as, artificial
heat or light, gems, salts, minerals, fountains, flowers.
[1913 Webster]

Artificial strife
Lives in these touches, livelier than life. --Shak.
[1913 Webster]

2. Feigned; fictitious; assumed; affected; not genuine.
"Artificial tears." --Shak.
[1913 Webster]

there's more but that cover the essentials.

On reflection I think you're a Platonist. Mathematical objects are
real. Hence CS, being largely mathematics, has an objective reality.
DOS or an 8086 are merely human constructions, hence "artificial". Me
I think CS is artificial- in that its an abstraction having no
physical reality. Whilst an 8086 is made of real silicon atoms and is
as real as they come.

including descriptions of how to use various
Windows appliactions, descriptions of chip architecture, and language
primers

I think the word you wanted was "ephemeral".

I actually agree with you. I binned (not even charity shopped) most of
my DOS stuff ages ago. I have an attic full of Mac (when Mac's ran on
68000s and 128K was a LOT) books which I need to pluck up the courage
to bin. My university CS books are still relevent.

Since computer technology is constantly changing, these books
tend to go out of date. C is an unusually stable language, but the
problem is that you can't do many of the things you want to do with
just the core language, so often a primer will document a particular
compiler or target platform.

which is fair enough ***so long as you tell people what you are
doing***. K&R itself has a Unix based chapter. But to pretend (or not
know) that somethign is standard when it isn't is wrong.

I don't think it is really possible to write a classic that is
essentially a description of someone else's invention.

Plauger's library book? I think you are very wrong.

As the Soviets
found with their "production novels", some themes just don't lend
themselves to high art.

"The Soul of A New Machine" Tracey Kidder

engineering as literature: Antoine de Saint-Exupéry, Neville Shute,
Ayn Rand

 

[Nick Keighley]

<snip>

C is an unusually stable language, but the

C in particular has the interesting trait that, while you often need
to [...]

odd that you snipped there. It's almost as if you were trying to
distort what he was saying

reinsert:-
[...go outside the core language at some point, the bulk of the code
in any
given project is usually perfectly ordinary standard C which merely
makes
calls to a few functions which are outside the core language. ]

It has nothing so "in particular" about it at all in that respect.

trying writing in some other languages

Nearly ALL the useful things its used for outside of linux type command
line commands require external libraries that are not part of the core
language.

that doesn't contradict what he said. Yes you need other libraries (or
you write some nasty non-portable code) but that still leaves the bulk
of the code in perfectly ordinary standard C. Do you dispute that you
can write code like this? I've seen plenty.

*snip lots more rubbish*

 

[Nick Keighley]

[...] Most economies are mixed to some extent. Even the US has
social medicine now...

No, it doesn't.  We've taken one very small step away from a system of
total corporate welfare for insurance companies.  Hardly the right wing
boogeyman some would make it out to be.

I was trolling. From this side of the pond it looks like a small step
towards common sense. Remember I was responding to someone who thinks
"communism" has never been shown to work.

 

[spinoza1111]

I would say that it is possible for books about C (or, indeed, any
technical subject in CS) to be written by authors who apply their skills
to other areas (in addition to the style and presentation).  The results
will usually be better books than those produced under the ethos
[pile-em-high-and-sell-em-cheap] you describe.

There's a difference between books on computer science, and books
which document something artificial.

computer science isn't artificial?

A lot of computer books are in the latter category,

books about "artificial" things?

I think you have an odd definition of artificial

from dict.com

Artificial \Ar`ti*fi"cial\, a. [L. artificialis, fr. artificium:
     cf. F. artificiel. See Artifice.]
     1. Made or contrived by art; produced or modified by human
        skill and labor, in opposition to natural; as, artificial
        heat or light, gems, salts, minerals, fountains, flowers.
        [1913 Webster]

              Artificial strife
              Lives in these touches, livelier than life. --Shak.
        [1913 Webster]

     2. Feigned; fictitious; assumed; affected; not genuine.
        "Artificial tears." --Shak.
        [1913 Webster]

there's more but that cover the essentials.

On reflection I think you're a Platonist. Mathematical objects are
real. Hence CS, being largely mathematics, has an objective reality.
DOS or an 8086 are merely human constructions, hence "artificial". Me
I think CS is artificial- in that its an abstraction having no
physical reality. Whilst an 8086 is made of real silicon atoms and is
as real as they come.

including descriptions of how to use various
Windows appliactions, descriptions of chip architecture, and language
primers

I think the word you wanted was "ephemeral".

I actually agree with you. I binned (not even charity shopped) most of
my DOS stuff ages ago. I have an attic full of Mac (when Mac's ran on
68000s and 128K was a LOT) books which I need to pluck up the courage
to bin. My university CS books are still relevent.

Since computer technology is constantly changing, these books
tend to go out of date. C is an unusually stable language, but the
problem is that you can't do many of the things you want to do with
just the core language, so often a primer will document a particular
compiler or target platform.

which is fair enough ***so long as you tell people what you are
doing***. K&R itself has a Unix based chapter. But to pretend (or not
know) that somethign is standard when it isn't is wrong.

I don't think it is really possible to write a classic that is
essentially a description of someone else's invention.

Plauger's library book? I think you are very wrong.

As the Soviets
found with their "production novels", some themes just don't lend
themselves to high art.

"The Soul of A New Machine" Tracey Kidder

engineering as literature: Antoine de Saint-Exupéry, Neville Shute,
Ayn Rand

Not one of these three writers would be what I consider literature as
opposed to beach reading trash.

That's because engineering is a social activity not something that
expresses one's "soul". Michelangelo could put his whole being into
the Sistine Chapel. Sure, Pope Julius sounds like a modern manager in
the film when he says "Michelangelo, when will you make an end?"

But the important difference is that Michelangelo gets to say, given
the technology of the time, which required someone to paint the
ceiling by hand, "when I am finished". Managers do not allow
programmers that free rein for the most part because most programmers
would abuse it.

Anyone who thinks a real modern pilot is like a Lindbergh or Saint-
Exupéry is nuts, since modern piloting is like driving a bus; the
aviation writer William Langewiesche documents in his recent book "Fly
by Wire" how hero pilot Chesley Sullenberger had to rely on the A380's
built in and software controlled "refusal" to go outside its design
limits created as comfortable an airplane crash as one could expect;
the video of the crash shows the plane lifting its nose perfectly, and
according to Langieweische, this is the A380's software, not
Sullenberger.

And the "heroic engineers" in Rand are just laughable as fictional
characters. Her fantasy that certain individuals are "productive" and
others are not is utterly nonsense, for a railroad engineer (her
ideal) needs a vast amount of financial and engineering support, most
of it extracted from people by paying them less than the value of what
they produce.

Real literature about real people today is mostly not about work,
since at work we do what the boss tells us to.

Sure, I helped to design a new machine. I did the firmware assembler
and compiler for a new switch. It was at best "fun", but I wouldn't
compare it to raising kids or learning how to play Bach.

A computer programmer who "feels like" an Artist is like a recording
of a live performance.

Louis XIV tried to make the artists working on Versailles into a
production "team". He hired Nicholas Poussin but wanted Poussin to be
a manager of large groups who would make bus-sized canvases
celebrating his useless wars. Poussin fled Paris for Rome to do
smaller paintings simply because Poussin knew that he'd have no
autonomy.

Any art process which has victims (such as Hollywood, with its
victimization of screenwriters and female actresses) is not to that
extent Art.