Slashdot Mirror

← Back to Stories (view on slashdot.org)

The New C Standard

Posted by Zonk on 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.

18 of 400 comments (clear)

  1. Thinly Veiled Job Request by Uber+Banker · · Score: 2, Interesting

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

  2. Did you consider.... by Anonymous Coward · · Score: 5, Interesting

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

    1. Re:Did you consider.... by mmaddox · · Score: 2, Interesting

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

      --

      What'dya mean there's no BLINK tag!?

  3. attaboy by aendeuryu · · Score: 2, Interesting

    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.

  4. Interesting outlook by LegendOfLink · · Score: 2, Interesting

    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.

    --
    IGB: More fun than eating oatmeal!
    1. Re:Interesting outlook by tolkienfan · · Score: 2, Interesting
      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.

  5. Re:1616 by Anonymous Coward · · Score: 1, Interesting

    Actually I've found a nice pattern in the number 1616/666:

    calc.exe gives 2,4264264264264264264264264264264

    Amazing, 426 is repeating itself!

  6. You don't need new standards by GamblerZG · · Score: 5, Interesting

    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.

    1. Re:You don't need new standards by RAMMS+EIN · · Score: 3, Interesting

      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.

      --
      Please correct me if I got my facts wrong.
    2. Re:You don't need new standards by dasunt · · Score: 4, Interesting
      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.

  7. Re:Again...? by Anonymous Coward · · Score: 1, Interesting

    The bonus question is: what is the lifetime/visibility/scope of 'i'?

    Depends on the standard, and how compliant your compiler is to the standard.

    If the standard doesn't specify then it's up to the compiler writer; most will probably make it the same as the current scope (which will strike most programmers as wrong).

    Odds are the spec requires that the scope be only within the loop, so then it's up to the compiler to actually be compliant to the spec.

    There are numerous compilers that fail to live up to specs they allegedly comply to. MS Visual C++ 6.0 for instance -- you can do the above in C++ code, but the variable's scope is the same as the parent function. Bloody annoying. Fixed in 7.0 at least.

  8. Re:Why would you use this? by hungrygrue · · Score: 2, Interesting

    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.

  9. I will publish your book by Roach · · Score: 2, Interesting

    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.

  10. Pretty Damn Impressive by Anonymous Coward · · Score: 4, Interesting

    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.

  11. we all mostly program in OO paradigms by Anonymous Coward · · Score: 1, Interesting

    we all mostly program in OO paradigms

    Uh. Got any proof?

    Take some inspiration from the book you just read: provide some proof and a reference.

    In fact, most programming remains function oriented.

    Sorry. Nice try, though.

  12. Manifestation of liturgical commentary. by blackest+sun · · Score: 4, Interesting

    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.

  13. Surely the next language was supposed to be "P"? by Anonymous Coward · · Score: 1, Interesting

    IIRC 'b', and its replacement 'c', were both derived from BCPL, so the next in line should be 'p'.

  14. Why Addison-Wesley rejected this by Animats · · Score: 4, Interesting
    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.