Despite being a writer by profession, and regularly castigating my colleagues for being recalcitrant in reviewing stuff I write, I actually dislike doing reviews myself. When I was an independent author (before I signed my life away to Microsoft), I was often approach by companies offering to pay me to write reviews of their products for their Web sites and literature. Even taking into account the presumed integrity of the author, this type of review seems somehow to be tainted when compared to an independent review by someone who doesn't stand to gain from it.
Yet I depend on reviews and reviewers, of both the technical and editorial kind, not only as part of my daily job creating guidance, but also when buying stuff generally. If I'm looking to buy a new ADSL modem or NAS drive, I'm likely to check out the reviews from real users to see if the one I fancy (the product not the reviewer) is actually any good. A typical example is when recently researching mobile Internet connection dongles and packages (which, from the majority of reviews, all seem to be equally useless). If I'm looking to buy a book, I'll read the independent reviews from readers. Only when I'm buying something as personal as music do I tend to avoid being swayed by the opinions of others. But that's mainly because, underneath this suave and intellectual exterior (?), I'm really still a heavy metal fanatic with a weird taste in classic rock music.
So I always feel that I should do my bit by contributing reviews where I think I can add some useful feedback to the discussion. And there's no point in writing a review unless you tell the truth. OK, so my blog is not generally known for being exceptionally high in factual content, but I do try very hard to be fair and even handed. So, let me start by saying that the latest book I've been reading is not actually bad - in fact, in general, it's well-written, informative, useful, and I didn't find any glaring errors in it.
And as you are obviously now waiting for the "but", here is comes. I bought "Accelerated VB 2008" (APress, ISBN 1590598741) based on reviews and the publisher's blurb in order to provide the equivalent training for VB as I undertook with Jon Skeet's "C# In Depth" book (see Syntactic Strain). According to the aforementioned blurb, it covers precisely what you need to know to use VB 2008 (a.k.a. VB 9.0) and .NET 3.5 effectively. This includes the newer and more advanced features such as generics, operator overloading, anonymous methods, and exception management techniques. And a whole paragraph of the description talks about the coverage of LINQ, extension methods, lambda expressions, and other VB 9.0 features.
Yes, the book covers these. But the really new and exciting stuff only gets a very brief summary in the introduction (5 pages), and just the final chapter of 43 pages. And the new topics I'm interested in get about a page each, yet there are 14 pages on using LINQ with XML. It's not that the VB 9.0 stuff isn't covered at all, but it certainly feels like it was added as an afterthought. OK, so there is a whole chapter earlier in the book devoted to generics, which is really quite good, and there is certainly adequate coverage of other VB 8.0 features. But it feels like the book is actually "Accelerated VB 2005 updated to VB 2008". And having been an independent author in a previous life I know that this is what happens. As soon as a new version of a product is announced, the publisher is hounding you to update your previous book to the new version. In three months. And without them paying you much money.
I guess this is the core difference between the two books I've been using. "C# In Depth" feels like it's telling you a story, and the features of the versions of the languages are partially intertwined throughout so you understand how each addition to the languages serves a specific purpose and simplifies or extends previous features. "Accelerated VB 2008" feels more like a tutorial that aims to cover advanced uses of Visual Basic without really explaining the evolution and purpose of the language. For example, there's a whole 45 page chapter devoted to threading, which seems to me to be a feature of the .NET Framework rather than a feature of Visual Basic.
Perhaps I expected something different because I was looking for a book that covered the new language features in depth, whereas "Accelerated VB 2008" feels more like it is aimed at bringing VB programmers who basically still write like they are using VBScript into the real world. But it surfaces issues that I suppose I always recognized are part of the overarching view of programmers and programming languages (at least in the Microsoft world). It's like VB programmers have to be protected from reality; and must always be reminded how you define a class, use an interface, and handle exceptions - irrespective of the "advancedness" of the book.
Again, I must repeat that this is not a bad book. It is really quite good, and will be a useful addition to the Visual Basic programmer's library - especially if (like me) you are still a bit vague about generics, delegates, lambdas, and similar topics. It also helped me more clearly see how the process of creating and updating documentation is a lot harder than it may at first seem. When I work on updates to the guidance for new versions of our deliverables here at p&p (such as Enterprise Library) I try really hard to interweave the new features with the existing content. In the previous two versions, for example, we've completely reordered the sections and topics, added new overviews and "how to" sections, and modified the structure to give the new features the appropriate precedence alongside the existing ones. And it really can be tough to do when there's already over 1,000 pages of it.
And while Jon's "C# in Depth" book did wind me up with its repeated use of the term "syntactic sugar", "Accelerated VB 2008" also has one overarching feature that I found extremely annoying. Like so many other books, they insist on printing complete listings of the example code, even when it covers two or more pages, with the explanation only at the end of the listing. The result is much page flipping to understand what's going on. But worst of all, when there is a minor change to one line of code to illustrate a feature of the language, they print the entire code again with no highlighted line or indication of where the change is until you read the text after the listing. After a while I started just believing what the text said because it seemed too much effort to go back and try and find the changed line.
So here's a challenge. Is there a book out there that covers the language features of Visual Basic 8.0 and 9.0 without describing how to declare variables, write a class, handle exceptions, and interact with the basic .NET Framework classes? One that explains in detail how features such as extensions, lambdas, LINQ, and generics work, and which makes it easy to understand their purpose and usage? Or am I just expecting publishers to commission books that focus only on stuff that I've been to idle to learn about so far? Maybe a market sector consisting of one person is not a viable business proposition...
Oh, please. Fix the typo.
Give me a clue... which typo?