From: jcoffin{at}taeus.com
To: c_echo{at}yahoogroups.com

At 01:23 AM 8/5/2003 +0100, you wrote:

>  * Author: CHARLES ANGELICH

[ ... ]

>Hello Jerry -
>
>Not actually accessing this echo via a FIDO BBS seems to impose
>no need to address your replies to the person you are replying
>to.

More accurately, rather than eliminating the need, it (mostly) eliminates 
the _possibility_.

>It would be helpful if you could use a FIDO BBS to access the
>echo and use real names.

When I could do so I did -- for years I was 1:128/60.2, and for a while 
after that I was 1:128/77.3.  Eventually, however, direct Fido connections 
became impractical for me.

>Where I come from addressing a person
>as "You" would be considered rude behaviour.

Somehow a Biblical quote about the log in thine own eye springs to mind here.

>JC> It's your loss -- as you might guess from the bit I quoted,
>JC> the introductory material is often quite interesting
>JC> (though I can't remember much that seems to me like it
>JC> would mean much to a librarian).
>
>Library of congress numbers and others.

I've yet to see a preface or introduction that listed the library of 
congress number of the book.

> >> Not known to me. It's still K&R not R&K.
>
>JC> Which has little to do with anything -- many fine books
>JC> about C don't list dmr as an author at all.
>
>What is a "fine book"? A pretty cover, lots of pictures? IMO if
>the book fails to mention who the authors of C are it's not
>"fine" it's superficial and I would question how much research
>actually went into producing the book.

You started by saying that you were surprised to learn that Brian Kernighan 
didn't help invent C.  Now you say that any book that didn't tell you this 
had to be superficial and probably poorly researched.  The conclusion seems 
to be inevitable: you lack any real knowledge of C, since all of the books 
you're read on it are superficial and poorly researched.

Consider, for one example, _The UNIX Programming Environment_, but Brian 
Kernighan and Rob Pike.  There's no question in my mind that both Brian 
Kernighan and Rob Pike know (and knew when they wrote the book) that Dennis 
Ritchie was the person primarily responsible for the C programming 
language.  Nonetheless, I can't seem to find any mention of this particular 
fact in the book.  The closest it comes is mentioning that Dennis wrote the 
first C compiler for the UNIX system (though, of course, you'd have missed 
this reference, since it's in the preface).  I seriously doubt that Dennis 
himself would agree with your characterization of the book as superficial 
nor would he agree that it lacked research.

>JC> I've never seen a specific reason given for Brian Kernighan
>JC> being listed first, but they might easily have simply put
>JC> them in alphabetical order. It's also been pointed out that
>JC> Brian Kernighan was the larger contributor to the book, if
>JC> not to the language at all.
>
>Information from Kernighan would lead me to think otherwise:

Perhaps you should work on your reading skills.  I said that Brian wrote 
most of the _book_ not that he invented most of the language.  Considering 
the quote already given from Dennis, that Brian wrote almost the entire 
book, and that Dennis contributed only one chapter plus an appendix, this 
seems incontrovertible.  Your quotes all seem aimed toward proving that 
Brian didn't invent the language, which is (of course) in direct accord 
with what I wrote above.

>  Please note that last sentence. ;-)

Noted -- it seems to agree precisely with what I said.

>Any of this sound at all familiar?

Of course.  What part lead you to the mistake of believing that something I 
said was wrong?

[ ... ]

>Yes, actors gush lists of names when accpeting their awards.
>It's an established form of psuedo humility.

So now you're likening Dennis Ritchie with an actor?  You're truly a piece 
of work!

>While fiddling with OBERON I recall reading that Wirth had a
>colleague who collaborated in much of what Wirth had done.

I suspect you're thinking of Jürg Gutknecht, but depending on when you 
look, he worked closely with quite a few other people as well -- just for 
example, one of the initial proposals for what (eventually) became Algol 68 
was written primarily by Niklaus Wirth and C.A.R. Hoare.

I feel obliged to add that although Niklaus Wirth wrote one of the initial 
proposals for the Algol 68 committee, he quit the committee in disgust part 
way through the process, and seems to take quite a dim view (to put it 
nicely) of the language the committee eventually produced.  Regardless of 
the language itself, a dim view of the process used to produce it seems 
quite easily justified.

There's certainly a great deal of contrast between the Algol 68 definition 
and the C definition.  The Algol definition was done almost entirely in the 
"ivory towers", so to speak, and it wasn't until several years later that 
there was even a _reasonably_ complete implementation of the language (and 
I'm not sure there's ever been an implementation that was complete and 
accurate to the degree we routinely expect of C compilers).

C was nearly the opposite.  B was largely an attempt at paring BCPL down to 
the point that a compiler for it could be fit into a PDP 7.  The first 
compiler for B produced threaded code.  Dennis Ritchie seems to have gotten 
involved primarily with writing a B compiler that would produce native 
code.  As time went on, he started to add various features to the language 
itself, and eventually it became NB (New B) and quickly progressed from 
there to C.

Ultimately, however, two factors dominated the language design: providing 
the features needed for the projects being worked on (primarily UNIX) while 
remaining easy enough to implement to fit the compiler onto the machines 
available (e.g. less than 64K of RAM at the time).  At the time, the 
compiler was considered the real definition of the language, so nothing was 
considered part of the language until or unless it was implemented.

In fairness, this had both good and bad points: it kept from producing an 
unimplementable behemoth, but it also lead to some strangely non-orthogonal 
features as well as a few clear mis-steps (e.g. what we now know as +=, -=, 
etc., were originally =+, =-, and so on because it made the parser a bit 
easier to write).
         Later,
         Jerry.

--- SoupGate-Win32 v1.05