Some books seem like they're churned out of a writing factory with a whole team of people working on them and standardized format. Others are a product of one individual's commitment to an idea and a goal. This book is the second type.
This is a book about Visual Basic .NET. It's not about Windows, or the .NET Framework, databases or web pages. It's about Visual Basic .NET. And it's written by the man who might just be be best qualified person on the planet to write it: Paul Vick was the lead architect at Microsoft when Visual Basic .NET was created.
Although the book is based on Framework 1.1, it's an extremely valuable resource anyway since the topics discussed don't really change that much - Framework 2.0 adds rather than changes things. Besides, it's what we're going to get. Paul has stated that, "Over the past several months, I’ve been getting questions as to whether I’m going to be updating my book, The Visual Basic .NET Language, for VB 2005. The unfortunate answer is: not at the moment."
As soon as I started reading this book, I noticed that the language was clear, uncomplicated, straightforward. In fact, Paul strips examples to their bare essentials. It's the exact opposite of the typical Microsoft MSDN documentation where examples seem to cram every obscure syntax possible into the code. In about one page (including a code example), Paul explained the difference between structures, modules, and classes more clearly than I have ever seen it.
Another example -- Here's the definition of the .NET Assembly from a different author:
"All of the files that comprise a .NET application, including the resource, security management, versioning, sharing, deployment information, and the actual MSIL code executed by the CLR. An assembly may appear as a single DLL or EXE file, or as multiple files, and is roughly the equivalent of a COM module."
Here's the definition from Paul's book:
"An Assembly is a file with an EXE or DLL extension that the .NET Framework can load and run."
Quite a difference, right? That's the way the whole book is. The Language Introduction (Chapter 1) is simply the finest short tutorial for VB.NET that I have ever seen.
I have a theory about why Paul is able to state things so clearly. It's the assurance you get from being the authority. I think lesser authorities sometimes explain too much because they're not absolutely sure about it. So they over-explain to compensate.
One thing I would have liked to see more of was explanations about "why" things were done in VB.NET. Here's one example: Since they were starting completely over and could have used the same keyword, why did they use "using" in C# and "Imports" in VB? Why does VB.NET still support a GoTo statement? Paul would know the inner workings at Microsoft, but there's never a clue about things like this. Given Paul's priceless insider viewpoint, the strictly tutorial tone throughout the book seems like a horribly wasted opportunity.
The best audience for this books is actually experienced programmers who want to "hone" their knowledge of VB.NET. Beginning programmers might find the going a bit tough at times simply because Paul assumes that you already know a lot of things. For example, most of the code examples are "incomplete" in the sense that you can't just plug them into, say, the Button_Click event in a Windows application. They're not hard to run ... but you have to understand where they fit.
All in all, I think this just might be the "best yet" book on VB.NET! If I could only have one book for VB.NET, this would be the one.
