Forgot your password?
typodupeerror
Programming Books Media IT Technology

The New C Standard 400

Posted by Zonk
from the meet-the-new-boss dept.
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.
This discussion has been archived. No new comments can be posted.

The New C Standard

Comments Filter:
  • 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 [coding-guidelines.com] 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
    • by DenDave (700621) on Friday July 08, 2005 @09:45AM (#13013406)
      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..

      • 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.
      • by mariox19 (632969) on Friday July 08, 2005 @10:57AM (#13013977)

        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!

        • "Not counting the citations at the end, the book is 1,577 pages of "guidelines." "

          Further, it's 160 pages into the book before you get the the first statement from the C standard. It covers everything from code defect lifetime to 44 pages on the psychology of human characterists. Stick to the topic, geez.
        • by Clod9 (665325)
          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 w

          • 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 :-)

    • 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.

      I haven't R'dTFB (not being insane enough to download a book-length PDF linked off the newest story on /.) but it's not obvious that that's so. The book is supposedly using a novel approach to maximizing code readability and comprehensibility,

      • ...not being insane enough to download a book-length PDF linked off the newest story on /.

        Only took me a few minutes over my DSL connection. Actually reading this thing is more problematic. It's 1600-odd pages, and consists of a section-by-section (in some places, sentence-by-sentence) commentary on the C standard. There's no PDF bookmarks or other navigation aids. Apparently you're supposed to print out the whole damn thing and read it side-by-side with the standard! Kind of arrogant to assume that any

    • by 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
    • Chicken or egg man?

      If we follow your logic, books like Code Complete are useless because we should already know this stuff before we need it. (huh?)

      Glad your brain is that big.
      Me, I rather fully appreciate this all too rare level of detail being made available. C should not be a black art, there is no reason for it to be.

      As for your statement about the appropriateness of even knowing/using C, I simply must protest. ALL of the good programmers I know have a background that includes C, whether they program
    • A good C programmer will know this info already ...
      So what about bad C programmers? God knows there's enough of those!

      I find your argument a little weird. Nobody should write books about things their target audience should already know? "Should" and "do" are two different things. That's what keeps writers in business!

    • There are lots of computers beyond PCs. Think about all this embedded stuff, 16-bit and 8-bit controllers, especially those that do real-time tasks. A friend of mine has just completed a pure C project of 11k lines for an automotive controller. This does not seem like a very big deal, but there are lots of such things. For their developers, C is a godsend, compared to assembler, and such a book a real boon.

      (And yes, I know about Forth, etc)
  • by killproc (518431) on Friday July 08, 2005 @09:36AM (#13013328)
    This seems to be an interesting topic. I'm sure you could sell a few copies on Amazon...
    • From The Inquirer link:

      I did not know until almost crunch time that it was on the limit of what non specialist printers can handle, in terms of number of pages

      When you consider that all both of the likely purchasers probably live in the same basement, AW's decision might be seen as a bow to reality.
      Less smart-assly, there is always Wikipedia.
      I, for one, would be interested in reading it, in all 1600 pages, ~8MB of its glory. But that much information begs to be introduced in smaller chunks, and I'm

  • by Anonymous Coward on Friday July 08, 2005 @09:37AM (#13013341)
    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!
    • by satan666 (398241) on Friday July 08, 2005 @09:50AM (#13013446) Homepage
      Puh-leaze! Java-this and Java-that. Why not use a language that is designed for speed: COBOL
    • 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.
      • You don't know what you are talking about.
  • Just a handful of comments, and the links are already not responding. Can anyone seed a torrent and provide that ?

    cheers
  • Mirror of pdf here (Score:5, Informative)

    by derek_farn (689539) <derek@knosoSTRAWf.co.uk minus berry> on Friday July 08, 2005 @09:40AM (#13013370) Homepage
    There is another mirror of the pdf here [mirrordot.org] thanks to the folk at mirrordot [mirrordot.org].
    • Author comments (Score:5, Informative)

      by derek_farn (689539) <derek@knosoSTRAWf.co.uk minus berry> on Friday July 08, 2005 @10:38AM (#13013819) Homepage
      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 [amazon.com], the ISBN number is 0201709171. Perhaps Addison Wesley [awprofessional.com] will change their mind if enough order are received.

      • Information on typos. Please keep sending these to me. I am keeping a log [knosof.co.uk] of these so that writers of grammar checkers have some real world data.
  • Did you consider.... (Score:5, Interesting)

    by Anonymous Coward on Friday July 08, 2005 @09:42AM (#13013383)
    ...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.
    • by mmaddox (155681)

      ...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 publi

    • You could also consider "self-publishing", as well as creative commons. . . Something like http://cafepress.com/ [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.
  • attaboy (Score:2, Interesting)

    by aendeuryu (844048)
    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.
    • Another thing that's nice to see is the authors of books that are out of print releasing PDF versions for download. I have recently read Practical Filesystem Design and The UNIX Haters' Handbook in PDF form. Both of these were out of print when I tried to get hold of copies, and both were available for download from the authors' web sites.
  • by mbessey (304651) on Friday July 08, 2005 @09:45AM (#13013407) Homepage Journal
    Good grief. I can see why the publisher bailed on this. I wonder how much they would have had to charge for it?

    -Mark
  • "The New" (Score:4, Insightful)

    by hey (83763) on Friday July 08, 2005 @09:52AM (#13013465) Journal
    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 (Score:3, Interesting)

    by LegendOfLink (574790) on Friday July 08, 2005 @09:52AM (#13013467) Homepage
    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.
    • by Kupek (75469) on Friday July 08, 2005 @09:58AM (#13013506)
      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.
    • I haven't read the book, so I have no clue whether it goes into this. But it's well-known in the field of cognition right now that experts process information within their fields very differently from the way novices process it. A common example is that a chess master can memorize a chess board setup in a few seconds, because their brain automatically breaks it down into useful chunks (moves, etc), whereas a novice has to memorize it piece by piece and has a lot more trouble. That's a pretty basic example t
      • So, are you saying that an experienced coder will not look at the "code", but the structure?

        This makes sense. I remember that e-mail that asks you to read:

        Teh qicuk bowrn fox jmups oevr teh dog.

        and magically, we know what it is. There's no deciphering of letters or rearranging. We know what it is because we don't actually read the words, we just read the structure (the first and last letter intact).
      • A while back Byte magazine had a theme issue about knowlege engineering; the biggest difference that they reported between an expert and a noob, was the expert had a greater ability to recognise what was important to the decisions he had to make and to ignore trivial data.
    • by fcw (17221) *

      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 [ppig.org] 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 autonomous

    • 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 think you're completely off here. Computers have no concept of the end state of a code snippet. Humans work exactly the opposite of computers in most cases: we visualize the final desired stat

  • by 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.

  • by winkydink (650484) * <sv.dude@gmail.com> on Friday July 08, 2005 @10:03AM (#13013558) Homepage Journal
    I don't think this C-thing is going to catch on. :)
  • C0X (Score:5, Funny)

    by zephc (225327) on Friday July 08, 2005 @10:07AM (#13013587)
    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.
  • by museumpeace (735109) on Friday July 08, 2005 @10:07AM (#13013598) Journal
    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.
  • by MatD (895409) on Friday July 08, 2005 @10:08AM (#13013603)
    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.
  • I'm suffering from a sense of Deja Moo... I'm sure I saw this last month...
  • Some lacking the elegance of the K&R book.
    Good thing this isn't the first book about C or
    it would never take off.
  • by GamblerZG (866389) on Friday July 08, 2005 @10:15AM (#13013658)
    What you really need is a new language [digitalmars.com].

    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.
    • The problem is always the same: How do I make a computer do just what I want it to do?

      In C, you can do that. Even if the solution is to invent another language compiled by a C program. Or to embed assembly code in your C code.
    • by RAMMS+EIN (578166) on Friday July 08, 2005 @11:44AM (#13014428) Homepage Journal
      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 [wikipedia.org] 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.
    • by dasunt (249686) on Friday July 08, 2005 @11:46AM (#13014451)
      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.

  • by nadamsieee (708934) on Friday July 08, 2005 @10:21AM (#13013707)
    The book's homepage can be found here: http://www.knosof.co.uk/cbook/cbook.html [knosof.co.uk]
  • by ewilts (121990) on Friday July 08, 2005 @10:46AM (#13013895) Homepage
    Have you considered making the book available through http://www.lulu.com/ [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).
  • by Roach (15003)
    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.
  • The book is listed here [theassayer.org] on The Assayer. User-submitted reviews would be appreciated!
  • Some thoughts (Score:4, Insightful)

    by mnmn (145599) on Friday July 08, 2005 @10:58AM (#13013993) Homepage
    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.

  • by Anonymous Coward on Friday July 08, 2005 @11:02AM (#13014043)
    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.
  • by blackest sun (700836) on Friday July 08, 2005 @11:14AM (#13014157) Homepage Journal
    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 [wikipedia.org] breakdown of interpretation.
    • 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 cha
  • Your book is a great mandate for a programmer to build a C programmer's editor that enforces all the rules. Emacs "c-farn-mode", anyone?
  • by Trinition (114758) on Friday July 08, 2005 @11:24AM (#13014253) Homepage

    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.

  • by tundog (445786) on Friday July 08, 2005 @11:59AM (#13014589) Homepage
    1983 called and it wants its 'new' standard back...
  • by Animats (122034) on Friday July 08, 2005 @12:56PM (#13015115) Homepage
    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 (Score:3, Funny)

    by St. Arbirix (218306) <matthew.townsend ... m ['l.c' in gap]> on Friday July 08, 2005 @01:13PM (#13015245) Homepage Journal
    Mmm, this'll be nice for benchmarking my printer.
  • by Hard_Code (49548) on Friday July 08, 2005 @09:51PM (#13018629)
    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"

Old programmers never die, they just hit account block limit.

Working...