I’m not familiar with either author, but the first image immediately reminds me of a textbook. the code breaks between pages, it’s slow to read and BORING!
The second image includes syntax highlighting - perhaps a programmer’s best friend. The comparison reminds me of the difference between vi and vim.
You can’t satisfy everyone. Below, I’ve included a quote from a review I wrote of “C++ How to Program” (4th Edition) by Harvey M. Deitel, Paul J. Deitel (you can look it up on Amazon if you want). The point of it is that a good chunk of the other reviewers hated the use of color in the book. Yet, the color helped with readability and understandability. It seems to be a personal choice:
“…the use of color in this book seems to be a recurring motif in the reviews here. I was very pleased with the book’s use of color. As fully explained in the preface, all that color conveys information to the reader: it’s not there for decoration. First, the code examples (and there are a lot of them) all have a light yellow background, so they are automatically offset from the rest of the text. Then, the type within the coding segments uses other colors to mean certain things: comments are in green, keywords are in dark blue, errors are in red, constants and literal values are in light blue, and all other code is in black. Newly introduced code is also highlighted for emphasis. This is very much in keeping with what various IDEs do to make code more readable (see any of Microsoft’s Visual xxx products, the Eclipse Project Universal Tool Platform (specifically, the C/C++ Development Tools), and the Bloodshed Dev-C++ IDE). Beyond that, the book also uses colors to emphasize the titles of the programming tips in the text (i.e., Good Programming Practices, Common Programming Errors, Performance Tips, Portability Tips, Software Engineering Observations, and Testing and Debugging Tips). Again, all of this is an excellent way to convey more information to the reader and is not “distracting” in any way.”
“Continuing on the example of Application.Run(), his explanation makes it sound almost as if it did nothing but call the Show() function of the form, but we all know it does way more than that. It starts the message pump, spawns and executes the the UI thread, creates the application domain, etc (and not necessarily in that order).”
No, it doesn’t. The UI thread is the thread Application.Run() is called on and the appdomain has to be created well before that. It is, however, a message pump.
[twisti]: There are two primary reasons to get coding books:
The auth is presumably an expert in the field and as such will have better advice. If the advice is bad this can typically be discovered through reading reviews. On the web you only come across code snippets that can be written by anyone. It’s much harder to determine if their proposed solution is good or not.
This is related to number one in that the author is an expert on the field (presumably). They tend to have a better idea of the order the material should be presented in. If you’re going to teach yourself something like GUI programming solely from the web you are bound to make many common mistakes that could have been avoided with a good book that approached the subject appropriately.
Jeff,
I think it was not a good idea to include your Amazon ID on the link to Nathan’s book.
I am sure that’s not the point of the article, but it may attract some atention.
I’ll also say that unless you’ve actually read the Petzold book you can’t really get a feel for how bad it is just from this blog posting. It rambles on and on explaining each intricate detail of every example. The book is basically a bunch of useless examples with a line by line description of what it’s doing. Since he uses the same examples over and over again by building on them throughout the book, you end up reading the exact same descriptions over and over again.
Don’t get me wrong. There are some really good little gems/nuggets in Petzolds book. But you are often likely to miss them because you are skipping large blocks of repetitive prose just hoping to get through the book. And even if you did stumble across one, good luck finding it again when you really need it.
So it doesn’t really have anything to do with color. It’s more about creating subchapters and organizing a book so that it is readable. And the content needs to be useful and to the point. Not repetitive and useless.
One thing I hate about Petzold’s (and most other authors) code samples is that you will almost never find them commented the way that “real” developers comment their code. Commenting is not functional block headers describing the name of the function and who wrote it. It is a brief description of inputs and outputs, plus some in-line comments describing WHY something is being done. If more authors commented their example code it might add a few lines to the listing, but it would be invaluable in both helping people disect it and instructing other programmers in proper commenting technique.
I actually have made the same decision… choosing from several books related to WPF, Nathan’s book is clearly a great choice.
To [twist]: you’re really dating yourself, if you think it’s like living in the dark ages again!
I just purchased Nathan’s book tonight and so far I’m very pleased. Excellent writer. Very clear with an economy of prose. Reminds me of Sells.
I purchased Petzold’s last C# book. In sits in some dark corner of my office.
I’m going to beat a nearly-dead horse (I don’t think it’s fully beaten yet), but using the color samples and the like to describe Nathan’s book isn’t doing his book justice. The amount of insight he gives on so much of WPF is amazing; I’ve partially read his .NET and COM book and while the feel of the two books was different, they both provide one important goal: educate the heck out of the reader with information you won’t get without a lot of experience.
The color samples are nice, the way he puts tips and sidebars is nice, but it’s his content that is the shining star. Every other resource I’ve read on WPF doesn’t cut it on the detail of the whys and the hows. Most other books spend too much time giving the “if you write code ‘x’ then ‘y’ will happen” and not enough “this is why ‘x’ causes ‘y’ to happen.”
I think the head first books take a lot of space for motivating and building pictures that more inclined people form in their head themselves. Depending on the target audience this is good or bad, it loses space for ‘actual’ content. Although I like the author’s blog I couldn’t get myself to buy one of the books – the topics aren’t mine, and the german translation (necessarily) comes closer to the silly border.
My only ‘for dummies’ book was ‘Shakespeare…’, btw.
Sam wrote:
If this book is for intermediate or advanced developers, why is he explaining basics such as “static” or “Application.Run()”? And if this book is for beginners, why does he not delve into greater detail about these things if he’s mentioning them at all?
This has been my problem with every Petzold book i’ve ever read, going back to a book on the OS/2 PM API. I’m always left with the same impression i get reading an MSDN API reference - a basic idea of how an API should be used, but little understanding of why, or what pitfalls might arise. He has a knack for imparting just enough information to get you past the easy pitfalls, but falls short of giving you anything approaching a solid understanding of the system itself, the design goals that contributed to it, or the potential problems with using an API in ways that its designers might not have envisioned.
Learning an API by reading Petzold books is like learning to drive by reading a DMV’s drivers manual. You’ll know enough to get by, but you’ll never be more than just barely competent.
Petzolds book seems to be laid in the exact same way as Code Complete by Steve Connell.
Visit a bookstore and open the books side by side. They’re nothing alike. The only thing they have in common is that neither one is in color.
As I’ve mentioned before, color is undoubtedly a nice perk, but there are dozens of other reasons to pick the Nathan book, too.
“It reads like a blog and competes toe-to-toe with anything you’d find on the web.”
You say that… as if it was a GOOD thing!?
head explodes
Can’t say anything on Petzold’s new book yet as I’m not diving into XAML for a while. His WinForms books were pretty good but you need both of them, and Petzold certainly doesn’t care for people who use the Visual Studio designers or toolboxes. You need other books for that.
I do agree that it’s strange and annoying how every single of his .NET books has these “absolute beginner” explanations of the basics of .NET and C#, as if he tried hard to pad his page count.
I’ve bought and read every book on WPF that has been published. The book by Adam Nathan is my favourite. The sells/griffiths book from O’Reilly is #2. Charles Petzold is clearly a smart guy and his book has some good material in it, but really misses the mark. I think not including screen shots in the book (which was a conscious decision he made) was a huge mistake. There are whole paragraphs of text describing what you will see from a particular piece of code - why not just SHOW the result? I also think the approach he took devoting the first half of the book to “WPF in C#” also hurts the readability of the book. The Adam Nathan/Daniel Lehenbauer book is unfairly good - it took me at least 12 months writing WPF code to figure out most of what is in here, which others can catch up on from a single reading. I eagerly await the follow-up to the Sells/Griffiths book (due out soon) and Chris Anderson’s new WPF book.
I normally name “Programming Perl” when I need a good example of a really good technical book. It does a lot of things right.
The level is absolutely correct. It doesn’t, like many others, assume you know nothing about programming. I don’t want a book with a hundred pages telling me all about “if” statements.
The structure is good – very few forward references – which makes it a good introduction and a reference.
Finally it’s very well written. Why are most technical books so dry and boring? I like a little humour to lighten these dense programming tombs.
Coloured listing and screen-shots can enhance already well structured, well written text but they can’t save an otherwise poor book.
I would also suggest avoiding any book from Jesse Liberty; O’Reilly or not.
His code rarely works, he doesn’t follow standard coding conventions (puts variable declarations at the END of the class and doesn’t use any indicator that the variable is a class level variable), and he can’t seem to convey his thoughts very well. I’m not sure why anyone would pay the guy to write a book.
I agree with “Programming Perl”. Well written, and describing the context of the language’s features (including sometimes relevant portions of Larry’s background in linguistics) in a manner that really helped them to sink in.
I’ll also mention Donald Knuth’s book on TeX. Reading it was a revelation to me in the possibilities for technical writing.
I guess I’ll also mention the old DEC documentation. Today’s online “help” – gimme a break.
@Shog9:
“I’m always left with the same impression i get reading an MSDN API reference - a basic idea of how an API should be used, but little understanding of why, or what pitfalls might arise.”
That’s exactly what I tried to say but you said it so much better in fewer words.