Jon Skeet: Coding Blog : Book reviews, General

The trouble with book reviews

skeet — Tue, 08 Jul 2008 17:07:14 GMT

I'm currently reading two .NET books: Accelerated C# 2008 (Trey Nash) and Concurrent Programming on Windows (Joe Duffy). I will, in due course, post reviews here. However, the very act of thinking about the reviews has made me consider the inevitable inadequacies.

There tend to be two kinds of people reviewing technical books: those who've bought the book as a "regular punter" - who are aiming to learn something new. Then there are those who already know about the subject matter, but are reading the book mostly to review it. I realise there are people in-between (for whom the problems below aren't such an issue) but these are the two camps this post addresses.

The purpose of a technical book is usually to impart information and wisdom. I would have left it at just information, but things like best practices don't really count as "facts" as such - they are opinions and should be treated as such. So, there are two qualities that I look for in a book:

Is it accurate? Are the facts correct, and is the wisdom genuinely wise?
Is it a good teaching tool? How well is the information/wisdom transferred from author to reader?

I think it's worth breaking these up, although there is significant overlap.

Accuracy

As I've noted before, I'm a stickler for accuracy. If I can spot a significant number of inaccuracies in the text, I find it hard to trust the rest. Now I generally don't include grammatical errors, printing mistakes etc in this. While they make the book harder to read, they don't typically leave me with a mistaken impression about the technology I'm trying to learn. There's a blurring of the medium and the message when a book may be technically just about accurate, but still leaves an incorrect impression.

Now, the reader who has bought a book primarily to learn something new has little hope of judging accuracy. They can spot typos, and if the book is inconsistent or simply implausible that can become obvious - but subtle errors are likely to elude them. Just because an error is subtle doesn't mean it's unimportant, however. I know a reasonable amount about threading in .NET, but there's a lot of Joe Duffy's book which is new to me. He could have made dozens of mistakes in the text around Win32 threading, and I'd never know until it bit me. (For what it's worth, I very much doubt that there are dozens of mistakes in the book.)

A reader who already knows the subject matter thoroughly is much more likely to spot the mistakes. However, they're unlikely to be much good at judging the other major criterion...

Teaching efficacy

I can't really remember much about how I learned to program, other than that it was over the course of several years. I started off with Basic on the ZX Spectrum, then moved on to C, then Java, then C#. Each experience built on the previous one. The way in which I learned C# wouldn't have suited a non-Java programmer nearly as well as it suited me.

How can I possibly judge how well a book will teach a subject I already know? I can make some educated guesses about particularly confusing passages, and potentially critique the ordering of material (and indeed its inclusion/exclusion) but fundamentally it's impossible to gauge it properly.

The people who don't know the topic beforehand are likely to have a better idea, but it will still be flawed. In particular, you won't know how well the material has sunk in until you've given yourself enough time to forget it. You won't know how suitable the advice (wisdom) was until you've tried to follow it. You won't know how complete the coverage is until you've used the technology in anger, preferably over the course of several projects. Even then it's easy to miss stuff: if no-one on your team knew about iterator blocks and the C# book you were reading didn't mention them, how would you know what you were missing?

Who should you trust?

This post has had a pretty depressing mood so far. That reflects my irritation with the whole topic - which isn't to say I don't enjoy reviewing books. I just have doubts as to their use. I do, however, have a few positive notes to end on, as well as some fairly self-evident advice:

If everyone likes a book, it's probably good. Likewise unanimous disapproval is rarely a good sign.
When judging reviews, see if you can work out the context. Is the reviewer reading from a perspective of knowledge, or learning? If they're criticising accuracy, they probably know what they're talking about - but may not be a good judge of the style and teaching technique. If the review is mostly saying, "I learned C# from scratch in 20 minutes with the help of this fabulous book!" then you can guess that they at least believe they had a positive learning experience, but you should treat anything they say about accuracy and completeness with care.
Blogs tend to have more "expert" reviewers than ecommerce sites - although often bloggers will be encouraged to post reviews to Amazon as well.
Look for reviews which give specific praise/criticism. In particular if they give examples of teaching techniques, you will have more of an idea as to whether it'll suit you. Reviews which basically say "I loved it!" or "That's rubbish!" aren't terribly informative.

On that note, I should probably stop. That's another train journey gone that I should probably have spent actually reading... ah well. Please comment if you have other suggestions with regards to reviewing - particularly if it could help me to review books in a more useful way in the future.

Programming "in" a language vs programming "into" a language

skeet — Wed, 23 Apr 2008 18:47:15 GMT

I'm currently reading Steve McConnell's Code Complete (for the first time - yes, I know that's somewhat worrying) and there was one section was disturbed me a little. For those of you with a copy to hand, it's in section 4.3, discussing the difference between programming in a language and programming into a language:

Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.

Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Now don't get me wrong - I can see where he's coming from, and the example he then provides (Visual Basic - keeping the forms simple and separating them from business logic) is fine, but he only seems to give one side of the coin. Here's a different - and equally one-sided - way of expressing the same terms:

Programmers who program "in" a language understand that language's conventions and idioms. They write code which integrates well with other libraries, and which can be easily understood and maintained by other developers who are familiar with the language. They benefit from tools which have been specifically designed to aid coding in the supported idioms.

Programmers who program "into" a language will use the same ideas regardless of their target language. If their style does not mesh well with the language, they will find themselves fighting against it every step of the way. It will be harder to find libraries supporting their way of working, and tools may well prove annoying. Other developers who come onto the project later and who have experience in the language but not the codebase will find it hard to navigate and may well accidentally break the code when changing it.

There is a happy medium to be achieved, clearly. You certainly shouldn't restrict your thinking to techniques which are entirely idiomatic, but if you find yourself wanting to code in a radically different style to that encouraged by the language, consider changing language if possible!

If I were attacking the same problem in C# 1 and C# 3, I could easily end up with radically different solutions. Some data extraction using LINQ in a fairly functional way in C# 3 would probably be better solved in C# 1 by losing some of the functional goodness than by trying to back-port LINQ and then use it without the benefit of lambda expressions or even anonymous methods.

Accents and Conventions

That's just between different versions of the same language. Between different actual languages, it can get much worse. If you've ever seen Java code written in a C++ style or vice versa, you'll know what I mean. I've previously referred to this in terms of speaking a language with an accent - you can speak C# with a Java accent just as you can speak French with an English accent. Neither is pleasant.

At the lowest level, this is likely to be about conventions - and I'm pretty sure that when Steve writes "Invent your own coding conventions, standards, class libraries, and other augmentations" he doesn't actually mean us to do it in a gratuitous fashion. It can be worth deviating from the "platform favoured" conventions sometimes, particularly if those differences are invisible to clients, but it should always be done with careful consideration. In a Java project I worked on a few years ago, we took the .NET naming conventions for interfaces (an I prefix) and constants (CamelCasing instead of SHOUTY_CAPS). Both of these made the codebase feel slightly odd, particularly where Java constants were used near our constants - but I personally found the benefits to be worth the costs. Importantly, the whole team discussed it before making any decisions.

Design Patterns

At a slightly higher level, many design patterns are just supported much, much better by some languages than others. The iterator pattern is a classic example. Compare the support for it from Java 6 and C# 2. On the "client" side, both languages have specific syntax: the enhanced for loop in Java and the foreach loop in C#. However, there is one important difference: if the iterator returned by GetEnumerator implements IDisposable (which the generic form demands, in fact) C# will call Dispose at the end of the loop, no matter how that occurs (reaching the end of the sequence, breaking early, an exception being thrown, etc). Java has no equivalent of this. Imagine that you want to write a class to iterate over the lines in a file. In Java, there's just no safe way of representing it: you can make your iterator implement Closeable but then callers can't (safely) use the enhanced for loop. You can make your code close the file handle when it reaches the end, but there's no guarantee that will happen.

Then consider the "server" side of the iterator - the code actually providing the data. Java is like C# 1 - there's no specific support for implementing an iterator. In C# 2 and above, iterator blocks (i.e. methods with yield statements) make life much, much easier. Writing iterators by hand can be a real pain. Reading a file line by line isn't too bad, leaving aside the resource lifetime issue - but the complexity can balloon very quickly. Off by one errors are really easy to introduce.

So, if I were tackling a project which required reading text files line by line in various places, what would I do? In Java, I would take the reasonably small hit of a while loop in each place I needed it. In C# I'd write a LineReader class (if I didn't already have one!) and use a more readable foreach loop. The contortions involved in introducing that idea into Java just wouldn't be worth the effort.

At a much higher level, we get into whole programming styles and paradigms. If your natural inclination is to write imperative code, you're likely to create a mess (or get very frustrated) in a functional language. If the problem really does call for a functional language, find someone else to help you think in a more functional way. If the problem suits imperative programming just as well as it does functional programming, see if you can change the environment to something more familiar.

Conclusion

I'm not suggesting that Steve's point isn't valid - but he's done his readers a disservice by only presenting one side of the matter. Fortunately, the rest of the book (so far) is excellent and humbling - to such a degree that this minor quibble stuck out like a sore thumb. In a book which had more problems, I would probably barely have even noticed this one.

There's another possibility, of course - I could be competely wrong; maybe I've been approaching problems from a restrictive viewpoint all this time. How about you?