The New C Standard 400
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.
Thinly Veiled Job Request (Score:2, Interesting)
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).
Did you consider.... (Score:5, Interesting)
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.
attaboy (Score:2, Interesting)
Interesting outlook (Score:3, Interesting)
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:Did you consider.... (Score:3, Interesting)
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:1616 (Score:1, Interesting)
calc.exe gives 2,4264264264264264264264264264264
Amazing, 426 is repeating itself!
You don't need new standards (Score:5, 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.
Re:Again...? (Score:1, Interesting)
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.
Re:Why would you use this? (Score:2, Interesting)
I will publish your book (Score:2, Interesting)
If interested I will provide you my contact info.
Pretty Damn Impressive (Score:4, 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.
we all mostly program in OO paradigms (Score:1, Interesting)
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.
Manifestation of liturgical commentary. (Score:4, Interesting)
Re:You don't need new standards (Score:4, Interesting)
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.
Re:You don't need new standards (Score:5, Interesting)
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:Interesting outlook (Score:2, Interesting)
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.
Surely the next language was supposed to be "P"? (Score:1, Interesting)
Why Addison-Wesley rejected this (Score:5, Interesting)
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.