The New C Standard

derek_farn writes "At a very late stage Addison Wesley decided not to publish my book, 'The New C Standard: An economic and cultural commentary'. Now that the copyright issues have been sorted out I am making the pdf freely available. You can download the pdf (mirror 1). The organization is rather unusual in that the commentary covers each sentence of the C Standard (actually the latest draft of C0X, excluding library) one by one (all 2022 of them). One major new angle is using the results from studies in cognitive psychology to try and figure out how developers comprehend code. The aim being to try and produce some coding guidelines that reduce costs (ie, reduce the time needed and bugs created). The book also contains the results of lots of measurements (over 400 figures and tables) in an attempt to back the arguments being made -- another unusual feature since most software related books don't publish any figures to back up what they say. Other subsections discuss common implementations and differences between the latest draft standard and C90/C++. More background on the project is available from the Inquirer.

Comments

Thinly Veiled Job Request

[Uber Banker]

Good luck to you too. Youre clearly a knowledgeable and experienced programmer, and being a knowledgeable/experienced programmer means you are probably able to write code that is minimal on bugs, fast, and effective. But what is the purpose of this book? It clearly isnt a commentary; the reference on your homepage to a blog entitled coding guidelines seems more appropriate: the book used the word shall so much when I tried to count the amount Adobe Reader hung for 2 minutes.

Your book is a style guide: a reference of background information and pointers how best to code, and know whats going on. A good C programmer will know this info already (or be on their path there), as the only reason for knowing C today is to interact on a close level with the machine, or to know exactly how things are handled, otherwise theyd be mad not to use a higher level language. A knowledgeable programmer does not need dictating to.

So Im curious, for whom do you intend this book to be most useful for (the book most certainly is useful if someone needed a reference, but given my overriding interpretation of it as a style guide for people who dont need one, it seems to be lost without an audience).

Re:Thinly Veiled Job Request

[DenDave]

So maybe it is a guideline to hobby C coders, new learners, anyone who doesn't use C as professional??

I think there is a target audience, perhaps you don't fall in the category but that doesn't mean that everyone who dabbles with C is Uber-Geek..

Re:Thinly Veiled Job Request

[ekephart]

Right, or someone like me, who is young yet fairly competent with C. As a style guide/commentary I see no harm in Mr. Jones sharing his insights. What college grad wouldn't benefit from the teachings of experience.

Re:Thinly Veiled Job Request

[Anonymous Coward]

Insight perhaps? In this day and age you are still told "this is how you do it" without being explained the reasoning behind it (the train of thought). You are just supposed to blindly accept it. This approach may have worked better before, when people were used to being dictated their thoughts, and because many people of this older generation teach the new, this way of thinking is passed on to us, because that's how they learned it.

Disclaimer: I got the PDF about a month ago and have just skimmed through it once. ;)

Re:Thinly Veiled Job Request

[iminplaya]

(Score:0, Redundant)

Do'h!

Why not self publish?

[killproc]

This seems to be an interesting topic. I'm sure you could sell a few copies on Amazon...

Why would you use this?

[Anonymous Coward]

C is over with already, geez. Slow, cumbersome, and nobody has a compiler for it. You should be switching to Java by now. It's fast, portable, and the JVM is everywhere. The Novell JVM is the fastest. Dennis Ritchie's time is past. Let the dinosaur turn into oil already and upgrade to the technology that will take us into the 22nd century and beyond. JAVA!

Re:Why would you use this?

[satan666]

Puh-leaze! Java-this and Java-that. Why not use a language that is designed for speed: COBOL

Re:Why would you use this?

[hungrygrue]

The sad thing is that half of the "l33t hax0r" kiddies here probably took this seriously. My theory is that after a few revisions, Java will become a perfectly usable language. The poor design decisions will be fixed and the JVM will be eliminated. The result will be a fast compiled language with an elegant syntax. Of course they they will have just recreated C at that point, so I guess it will never actually happen.

Re:Why would you use this?

[Anonymous Coward]

C has a lot of shortcomings, like being only weakly-typed, etc.

Maybe somebody should write a book once about why people should switch away from C to more modern languages.

You may view such things as shortcomings. I view them as power. Power that can be used for good or for ill.

Modern languages are all about protecting the programmer from having power. They limit the programmer, tying him or her down. This was done because so many programmers are idiots, true, but never forget that the problems modern languages were meant to solve are all people problems, not computer problems.

It is people that seem to need object oriented structures, because the language needs to help protect the programmers from their failure to organize data structures in a sensible way and communicate that structure to other programmers. People that seem to require strongly-typed languages, to prevent their errors of inattention while they write code. But all these features are unknown to the CPU -- they've all been stripped away in the compiler, and reduced back to the purity of sequential code. A purity that most programmers can't handle. A purity that C comes closest to (besides assembly, of course).

As a programmer working professionally for nearly 20 years now, I find it unutterably sad that so many new programmers are let out of colleges having so little idea of how computers actually operate. They're not programmers anymore -- they're a priesthood who poke at the black boxes in certain ways and the boxes "magically" do what they're supposed to. They have as little idea of what's going on as a 5-year-old playing with a gyroscope (and I apologize to any really bright 5-year-olds out there for the comparison).

The reduction of the use of C in our profession marks the decline of real knowledge in the average programmer.

Re:Why would you use this?

[The_Wilschon]

maintainability and enhanceability, at least, are entirely dependent on the quality of the programmer. I'm working on extending a package here at work, most of which is written in java. It is very poorly organized and I'm being forced to completely rethink the design. If it were well designed, I ought to be able to copy a couple of files and change some constants and be done. (the extension is nothing more than adding a new version of a particular custom electronics board while continuing to use the old board as well.)

Using java does not automagically give you all of these benefits. In the hands of a competent programmer, they may be easier to acheive with java. However, in the hands of an incompetent programmer, the best you might get would be portability and mobility. That is, as long as you stick with virtual machines and class libraries from one vendor.

There is no silver bullet.

Re:Why would you use this?

[groomed]

Christ you're an insufferable prat. And I say that not to insult you, but to inform you, lest it had escaped your notice.

Do you honestly believe that any of what you just said hasn't occurred to the original poster? A veteran of almost 20 years?

This discourse is so tired and worn-out that its only purpose is to serve as joke fodder on the Internet. And this is how it's been for ages, all the way back to when the first "Real Programmers don't eat quiche" jokes were being forwarded across Bitnet.

Let me quote Dijkstra:

Functional programming, structured programming, logical programming, constraints programming, p-code systems, object oriented programming, iterative development, patterns, open source development, pair programming, Extreme programming, managed code: each of these was heralded as the sine qua non of software development at its inception, only to get bogged down in messy detail once people actually started to build real-world systems with them. Bits and pieces survive here and there and percolate up in newer languages and designs, until every hint of the original glamour has vanished and they become just another fixture for pigeons to shit on.

And this is how progress is made, slowly and erratically, like a blind man groping about in the dark.

Fred Brooks was right: there is no silver bullet.

Re:Why would you use this?

[Iffy Bonzoolie]

Well, you aren't really giving the same info twice: First you are declaring that littleBoy is a reference to a ThermonuclearBomb. Second, you are pointing that reference at a new ThermonuclearBomb. But your example is very simplistic so it seems redundant. Perhaps your heirarchy looks like this:

NuclearBomb inherits Bomb
AtomBomb inherits NuclearBomb
HydrogenBomb inherits NuclearBomb

Bomb littleBoy = new AtomBomb();

Now littleBoy is declared as a reference to any kind of bomb. You are then assigning specifically an AtomBomb to it.

Adding all sorts of language shortcuts because you don't want programmers to type as much is inelegant. It makes the language harder to learn and read. Part of the elegance of Java is the eschewing of fancy syntactic candy-coated shortcuts in favor of a regular, predictable syntax.

-If

Re:Why would you use this?

[Col Bat Guano]

You may view such things as shortcomings. I view them as power. Power that can be used for good or for ill.

Modern languages are all about protecting the programmer from having power. They limit the programmer, tying him or her down. This was done because so many programmers are idiots, true, but never forget that the problems modern languages were meant to solve are all people problems, not computer problems.

No, it was done because most programmers are people, and most people aren't 100% perfect robots that get everything right all the time. Have you never suffered from out out of bounds error in an array? Just specifying checks for this in a langauge -helps- you, not hinder you. The amount of work you don't have to do chasing down problems that pop up a long way away from the source of the problem is amazingly less, when the program tells you where it (you!) went wrong.

Languages that protect you don't have to be seen as the enemy.

Mirror of pdf here

[derek_farn]

There is another mirror of the pdf here thanks to the folk at mirrordot.

Did you consider....

[Anonymous Coward]

...going to another publisher?

I used to be a development editor (10-15 years ago) - a real one; i.e. a software developer recruited to improve developer-level books, not a editor carrying the title. I would have been interested in providing up-front assistance to you and helping you get it ready for someone else. Most of the non-textbook (IDG, Que, SAMS, etc.) publishers prefer to have things come in chapter-by-chapter so things can be directed along the way, but with feedback prior to submittal, you could have gotten around that. You could have made some money that way.

Re:Did you consider....

[mmaddox]

...publishers prefer to have things come in chapter-by-chapter so things can be directed along the way...

I agree. Having done a few myself, it seems that most monolithic tomes that come it have problems making it through the process, generally because the authors are too emotionally invested in their work to accept criticism and editing. That's anathema to the publishing world, where at LEAST three re-writes are the norm. You could get away with it 5 or 6 years ago, when publishers were starving to publish anything and everything tech-related, but that time is long-gone.

How much editing did you get? How far did you get before notification?

Re:Did you consider....

[mopomi]

You could also consider "self-publishing", as well as creative commons. . . Something like http://cafepress.com/, which sends you a check for anything over their costs - some profit for themselves. You determine the price, AND you continue to own the copyright, so you can still provide free downloads of the PDF, if you like.

I have no affiliation with Cafepress besides having bought a couple of t-shirts from them.

Re:Did you consider....

[tcopeland]

> You could also consider "self-publishing"

Right on! You can get a run of 1000 copies of a soft cover book printed by someone like BookMasters for $5K or so, even for a monster like this one. Just stick with a 4 color cover and black/white in the text. And if you can charge $40 or so for this tome, you can cover your printing costs after selling only 150 copies.

[plug]
That's what I'm doing with PMD Applied; seems to be working out well so far.
[/plug]

attaboy

[aendeuryu]

Not really much more to say than that. Sorry you couldn't get it published conventionally. Writing's hard, though, so it's really dead cool of you to give it away.

One Thousand Sixteen Pages?

[mbessey]

Good grief. I can see why the publisher bailed on this. I wonder how much they would have had to charge for it?

-Mark

Re:One Thousand Sixteen Pages?

[Anonymous Coward]

(It's actually 1616 pages)

From the back of K&R: "C is not a big language, and it is not well served by a big book."

I guess K&R must be rolling over in their graves (or soon will).

Re:Again...?

[saider]

This is ANSI C. It gets refreshed every so often to incorporate some changes. One of the easiest changes to spot is the following...

for(int i = 0; i MAX_COUNT, i++ )

In the olden days, you'd have to declare i before using it in the code. The newer standards let you declare variables at their first use. This serves to clean up the code a little and also lets the programmer see what type it is without having to scroll up to the top of the function.

There's lots of other little changes like that in the various "standards".

Actually....One Thousand Six Hundred and Sixteen

[Rolan]

1616 pages....

1616

[mnemonic_]

That's the number of the beast multiplied by 2.426! Incredible!

"The New"

[hey]

I don't know if I trust a style guide with "The New" in the title. Nothing stays new forever.
What about when the next version of C comes out?
You'll have to go back a revise the title! Why not do it right the first time and call it "C90/C++ Style" or something.

Maybe times when cleaning up other people's files I have run into files with "new" in the name... dated years ago. A sure sign it can be deleted.

Interesting outlook

[LegendOfLink]

One major new angle is using the results from studies in cognitive psychology to try and figure out how developers comprehend code.

I believe that developers comprehend code just like a computer, one line at a time. We store things in memory (short-term memory) and "run" them through our minds, simulating what the computer might do. Of course, our human syntax checkers can sometime don't catch, but the logic is there.

I've always thought that there must be a better way to write high-level code than writing a large code using snippets of simple logic. Of course, we can only write code similarily to the way our minds work. When we solve problems, we just don't think about it and it happens, we run through several scenarios, if-then situations, and logic tests before we come to conclusions.

The better question is how to get a computer to produce code autonomously by asking it the final objective. For example, it would be nice to have the computer figure out the "how" as opposed to us programming it in.

Re:Interesting outlook

[Kupek]

Computers don't comprehend code, they just run it. Comprehension is an entirely different act than execution. While we build up our comprehension one line (or word) at a time, we're still using our recollection of all previously related code to understand what this new piece of code does. And then, once we think we understand what's going on, I think we often mentally throw out the code itself, and just remember what it does.

Re:Interesting outlook

[fcw]

I believe that developers comprehend code just like a computer, one line at a time.

Only novice programmers do this; experienced programmers have richer mental models, and many more ways of comprehending code. There's a lot of research on this already.

The psychology of programming is an entire field of study which attempts to understand everything from simple code comprehension to team dynamics in software engineering groups.

The better question is how to get a computer to produce code autonomously by asking it the final objective.

"Programming by Example" languages do this, as do declarative ones.

For example, it would be nice to have the computer figure out the "how" as opposed to us programming it in.

That's what domain-specific languages, such as SQL, have been doing for a generation. Even HTML is like that -- it describes some content and structure, and it's up to the browser to do the heavy lifting of presenting it to the user, and letting them interact with it.

Re:Interesting outlook

[tolkienfan]

Absolutely, we throw out the code.

We constantly compare the actual written code with our understanding of the intent of the code. We also frequently read incorect code as if it were correct - assuming it matches our model.

We do it with natural language too. Our mind fills in gaps, and silently corrects for syntax and grammer. It's a real bummer when you're proof-reading text, or diagnosing programs.

The way in which we actually create code is much more complex than GP suggests.
For a start we use different approaches to different problems. Most problems have been solved before, so it's a case of recalling an algorithm and applying it to the current context.
When it comes to a problem we haven't solved before, we have to match it, or parts of it, to algorithms we know. This process is very sensitive to the manner in which it is described or understood.

We seldom make great leaps, and actually invent something.

If we knew exactly how the process worked, we'd already have coded programs to do it for us.

I'm not an estheticist...

[Anonymous Coward]

and haven't read the book yet, but based on first impression would you trust a book on standards if the layout of the book itself doesn't seem to follow a publishing standard - besides the pdf file format.

I'm waiting for D

[winkydink]

I don't think this C-thing is going to catch on. :)

Re:I'm waiting for D

[Umbral Blot]

Wait no more

C0X

[zephc]

It seems that some men love C0X, but most men want nothing to do with C0X. The men that like C0X say there's nothing like the feel of the thick C0X standard in your hands.

Nice to have on the bookshelf...for a few of us

[museumpeace]

My occasional run-ins with languages go back to the days of BLISS and kicking around the Strawman and Ironman RFPs. I think there is a lot of value in a work like this for CS professors and software CTOs and maybe some flavors of project technical leads but at 1600 pages, not many of the rest of us would run out to buy it. ACM would seem a likely home for such a book...it reads like one of their Computing Surveys articls that got out of hand. [any book with > 1400 reference citations is definitely in the academic tome category...not sure I can fault AW's decision as a purely business decision. ON the other hand, the contents here are a musty treasure and I downloaded it immediately. I am grateful for this.]
Also, choosing to make deep commentary on the suitability of a computer language as a tool for solving problems but then going light on the dominant OO languages is just too big an omission. e.g. on pg 24:

Your author's experience with many C developers is that they tend to have a C is the only language worth knowing attitude. This section is unlikely to change that view and does not seek to. Some knowledge of how other languages do things never hurt.

There are a few languages that have stood the test of time, Cobol and Fortran for example. While Pascal and Ada may have had a strong influence on the thinking about how to write maintainable, robust code, they have come and gone in a relatively short period of time. At the time of this writing there are six implementations of Ada 95. A 1995 survey[571] of language usage found 49.5 million lines of Ada 83 (C89 32.5 million, other languages 66.18 million) in DoD weapon systems. The lack of interest in the Pascal standard is causing people to ask whether it should be withdrawn as a recognized standard (ISO rules require that a standard be reviewed every five years). The Java language is making inroads into the embedded systems market (the promise of it becoming the lingua franca of the Internet does not seem to have occurred). It is also trendy, which keeps it in the public eye. Lisp continues to have a dedicated user base 40 years after its creation. A paper praising its use, over C, has even been written.[398]

The references for the other languages mentioned in this book are: Ada,[625] Algol 68,[1347] APL,[634] BCPL,[1113] CHILL,[636] Cobol,[614] Fortran,[620] Lisp[630] (Scheme[693]), Modula-2,[626] Pascal,[619] Perl,[1375] PL/1,[613] Snobol 4,[504] and SQL.[621]

Since we all mostly program in OO paradigms these days, the author's perspectives on C++, though they would lengthen an already long book, should have been prominently featured instead of downplayed.

shoulda used booksurge

[MatD]

You could have published your book yourself through booksurge, and sold it on Amazon.com. At least that way, you'd actually get payed for all the work you did on it.

Re:can anyone set up a .torrent ?

[mwilliamson]

Sure, here ya go.
http://puffin.tamucc.edu/cbook1_0a.pdf.torrent

Re:Again...?

[Swamii]

The GP undoubtedly put a less-than operator in there, but Slashdot tried to interpret that as an html tag. And as another poster mentioned, it should be

for(int i = 0; i < MAX_COUNT; i++)

Re:Again...?

[Skye16]

it shouldn't be visible outside of this for loop. I'd be very unhappy if it was.

You don't need new standards

[GamblerZG]

What you really need is a new language.

Before modding me down, think about it. Any programming language is about solving problems, and problems you solve today are different from the ones someone had back in the days of C creation. Moreover, the ways you deal with programming changed as well. IT industry needs new languages, including low-level and compiled ones.

Re:You don't need new standards

[RAMMS EIN]

Agreed, we need a new language. All this writing applications in C is no good. Just think about all the security flaws that could have been avoided if we used a language in which buffer overruns, format strings, pointer arithmetic, unsafe casts, and memory leaks just didn't exist.

C also suffers from lack of flexibility. Try implementing a Java-style class system in C; although you can make something that works the same, using it will always be more cumbersome. Because of this, C will always be pretty low-level, it is just not adaptable enough to be used for really high-level things.

On the other hand, C isn't ideal for low-level programming either. Try writing properly tail recursive functions in C, or try composing a function call. Or, do something with the registers in your CPU.

And then there's the syntax of the language. Try writing a parser that can correctly parse any valid C program. Or try to write a program that does transformations on C programs, both reading and writing C code.

Re:You don't need new standards

[dasunt]

Before modding me down, think about it. Any programming language is about solving problems, and problems you solve today are different from the ones someone had back in the days of C creation. Moreover, the ways you deal with programming changed as well. IT industry needs new languages, including low-level and compiled ones.

I thought about it.

You first declared that we need a new language based on the assumption that we are solving different problems from a decade ago. (C99 was released about that long ago, and GCC supports much of the C99 spec).

Yet, thinking about it, you didn't tell us how problems are different from a decade ago.

Nor did you tell us how these problems present difficulties in the upcoming C0X spec.

The amazing thing about C is that it has survived several 'languages of the year'. It obviously has some advantages. It seems to me that C is a proven tool in the programmer's workshop. It doesn't solve all problems, but no tool does. However, it solves a lot of problems very well.

Re:You don't need new standards

[2901]

And then there's the syntax of the language. Try writing a parser that can correctly parse any valid C program. Or try to write a program that does transformations on C programs, both reading and writing C code.

If that kind of thing matters to you, you should look at Common Lisp. The built-in programmable parser is powerful enough to parse all CL programs and is configured to do so by default. Defining source-to-source transformations with DEFMACRO is an important technique

Not Again...

[uberdave]

No. This is obviously the NEW C standard they've been talking about. I haven't read the article, but clearly they've loosend up on punctuation. Also, any comparisons to directives starting with MAX must automatically default to a "less than" comparison.

Re:Not Again...

[Kloog]

Hopefully they will soon apologize and bring back the old standard as "C Classic."

The Book's WWW homepage

[nadamsieee]

The book's homepage can be found here: http://www.knosof.co.uk/cbook/cbook.html

Re:Cool but to what point?

[hungrygrue]

Yea, C is a dead language. Which explains why it is also the most widely used programming language, and why there are more lines of code in active use than any other programming language.

Author comments

[derek_farn]

I have been receiving two kinds of email:

• Requests for a dead tree version of the pdf. I have invested the possibility of self publishing. The problem is that these companies are not set up for high page counts (1,616) and an A4'ish page size (ok, and self-publishers are currently offering a less than stunning deal; the ROI is small).

  People could try ordering from Amazon, the ISBN number is 0201709171. Perhaps Addison Wesley will change their mind if enough order are received.

• Information on typos. Please keep sending these to me. I am keeping a log of these so that writers of grammar checkers have some real world data.

Re:Author comments

[Anonymous Coward]

"Dead tree version" is a waste of words.

Why can't you just say "paper version"? It's called PAPER. Get with the times.

Availability through LULU

[ewilts]

Have you considered making the book available through http://www.lulu.com/? It's a print-on-demand service that allows people an easy way to get a properly bound printed copy of your book, and for you optionally to get some money for your efforts. No cost to you to get set up either.

No, I don't work for lulu or have any financial connections to them. I just know one of the guys that works there (Jeremy Hogan, formerly from Red Hat).

I will publish your book

[Roach]

I work for a publisher and would like to speak to you about publishing your book.

If interested I will provide you my contact info.

At over 1600 pages?!

[mariox19]

Not counting the citations at the end, the book is 1,577 pages of "guidelines." Who's got that kind of time for a hobby? Who, having a job as a programmer, even has the time to read a book like that?

How about somebody writing a book called The New Writing Standard for Books on Programming? Most of the programming books I own are unecessarily long winded, but this book takes the cake!

Re:At over 1600 pages?!

[lisany]

Not counting the citations at the end, the book is 1,577 pages of "guidelines." Who's got that kind of time for a hobby? Who, having a job as a programmer, even has the time to read a book like that?

1577 pages? Ever hear of Lord of the Rings?

Re:At over 1600 pages?!

[Pollardito]

Not counting the citations at the end, the book is 1,577 pages of "guidelines." Who's got that kind of time for a hobby? Who, having a job as a programmer, even has the time to read a book like that?

if you don't have time, just wait for the 30 CD audio version

Re:At over 1600 pages?!

[Clod9]

I thought others must be exaggerating, but they're not. This really does win the prize for long-winded writing.

It's no wonder they didn't publish it, it's impenetrable. Not worthless, but just too detailed. It needs some completely different organization to carry the quantity of information it has.

My guess is, he set it all down and they probably asked him to reorganize it, and he balked, and instead offered what he had up in PDF form to us. Editors really do a valuable service, one that's missing from what you'll see here.

Re:At over 1600 pages?!

[pommiekiwifruit]

Well, that Donald Knuth guy still hasn't finished writing his book "The Art of Computer Programming" so he's got a way to go before getting the "gets side-tracked" award :-)

And IIRC John Harrison (the Chronometer guy) wrote multi-page paragraphs, so some georgian and victorian writers can get fairly lengthy :-)

Some thoughts

[mnmn]

I havent read the book. But some thoughts on that post:

The aim for C should not simply be to reduce the time spent on code, the simplistic economic view. Leave that to Java. C is for a clear and thorough understanding of the code's execution, more so than C++. The execution flow can very clearly be seen in this structured language which does not try to be smart or do things behind the wall in the compiler. C is brutal and raw, therefore low level and powerful. Leave it to that. C is great for kernel level programming, drivers and embedded systems, and other places where you get anal about control over whats happening. C is awesome when you need to mingle the code with assembly in tight spots and still keep things readable.

Please do not turn it into Java. Programmers who need to spend less time can just use Visual Basic or equivalents.

I like the idea of commenting on all parts of the standard. But you said you used a cognitive analysis of some sort. More so than that, I'd look for comments from experienced developers, maybe people who worked on various kernels and drivers, integrated various languages with C, developed C libraries and worked on a hundered-file projects.

Pretty Damn Impressive

[Anonymous Coward]

I've only been skimming it for a little bit now, but this book seems extremely interesting.

It probably would have gotten a lot more love during editing by the publisher, as, IMHO, it's fairly difficult to approach and digest in its current form. Maybe I just don't get it yet, but it does seem to suffer a bit due to its organization.

That said, the information in here is absolutely enthralling. I went over a few of the more subtle parts of the standard that I know fairly well, and I was impressed. The explanations are good, but what I really find compelling are the examples, historical anecdotes, references to different machines and architectures, and juxtapositions with other languages. You can tell that this guy knows this stuff, but more importantly, he's *lived* it.

The comments about this book not being useful to a "good C programmer" completely miss the mark. A good C programmer -- one that has a true love for programming -- will most likely find this book captivating.

Re:Again...?

[tomhudson]

... which brings us to the obvious question - why can't they fix it (slashcode) so that we can insert code samples properly?

in php its no big deal to make sure that anything you stuff in a db is safe - just do an $valueToStore = htmlentities($valueFromPoster). So either do the same in perl, or convert to php.

Manifestation of liturgical commentary.

[blackest sun]

At a glance, this is impressive not so much for content as for format. In essence this book is a Talmudic http://en.wikipedia.org/wiki/Talmud breakdown of interpretation.

Re:Manifestation of liturgical commentary.

[Franciscan]

Talmudic? Exactly. Here is a prodigious mind at work. A fascinating book, interesting perhaps only to the very small sub-set of human beings who have the following interests: (i) heavily interested in C (ii) not at all interested in C++ (iii) into scholarly discussions of human intellectual processes, metrics, studies, and quantifiable discourse on subjects dear to the heart of a language lawywer. (iv) wants detailed line by line commentary on the C standard. If I were the technical editor in charge of reviewing his book, I'd have a hard time making a case that there are a lot of people who want to read this book out there. If I really wanted to piss the author off, I'd suggest he try to get it published as "C99 for Dummies". Warren

Now that the copyright issues have been sorted out

[Trinition]

Now that the copyright issues have been sorted out...

As I was reading this sentence, my heart stopped and my mind jumped for joy. I thought the RIAA/MPAA/etc. had finally given up, congress had rolled back copyright terms, and the GPL was finally successfully tested in court.

Then I read the rest... *sigh* oh well.

Re:Again...?

[Thuktun]

... which brings us to the obvious question - why can't they fix it (slashcode) so that we can insert code samples properly?

Using &lt;, &gt;, and &amp;, along with consistent use of the Preview button, you can quote what you need to get it to work.

Know thy tools.

1983 called...

[tundog]

1983 called and it wants its 'new' standard back...

The silver bullet is competence

[smose]

The common thread, as I read it:

In the hands of a competent programmer... you get something usable.
...in the hands of an incompetent programmer... you get crap.

There is no silver bullet.

It sounds to me like the silver bullet is competence, which is acquired through a combination of aptitude, training, and experience. Silver bullet methodologies attempt to negate the importance of aptitude by relating experience into best practices for training. Silver bullet languages attempt to negate the importance of aptitude by making the languages more robust against stupidity. Yet, in the hands of the inept, silver bullets invariably embed themselves in the nearest available foot.

Some people just don't get it, whatever "it" is.

bored now...

[h4x0r-3l337]

I got bored just reading the slashdot article about this book. No wonder Addison Wesley decided not to publish it.

Why Addison-Wesley rejected this

[Animats]

It's clear why Addison-Wesley rejected this. The author is a terrible writer. He has a fondness for run-on sentences, fails to use commas appropriately, and makes several grammatical mistakes per page.

I'm up to page 132, and so far, it's an introductory cognitive psychology text. A bad one.

There are 1616 pages of this drivel. Even for someone interested in programming language design, this is a painful read.

There's room for a good book in this area, but this isn't it. A more useful approach might be to start from Amit Yoran's statement that "About 95% of software bugs come from 19 common, well-understood" programming mistakes", and evaluate language designs against that.

1616 pages

[St. Arbirix]

Mmm, this'll be nice for benchmarking my printer.

19 known problems cause most bugs

[Animats]

I've been trying to get that information. Yoran said that when he was head of the National Cyber Security Division at the Department of Homeland Security. He quit shortly thereafter, and his replacement is a TV producer. At this point, it's not even clear that there is a National Cyber Security Division at DHS. It's no longer in their table of organization.

Apparently, there were objections from Microsoft when DHS started to point out that Microsoft was the problem. What's left of the "National Cyber Security Division" actually seems to be CMU's CERT plus a front man, Andy Purdy, in Washington.

Mother of God

[Hard_Code]

Wow, if you are thrilled by language specifications, they you will shit your pants at the bonus 80 pages of experimental psychology background!

But seriously, good work dude ;)

"Sir, none of our techniques are breaking the prisoner"
"I was worried about this, they must have trained him on The New C Standard"