Who Should Read This Book, and Why?

Team Fly

Page xxi

Chapter 1 begins like this:

Visual Basic .NET WAS not written by Visual Basic programmers. The entire .NET family of languages was created by C programmers. C—and its cohort OOP—is an academic language. Visual Basic is a popular language. These facts have consequences.

The authors of this book are not beholden to any organization. We're not writing for Microsoft Press, nor are we affiliated with any corporation or school. Indeed, we like to think that we're not dependent on anyone for our paycheck—other than you, dear reader—and can therefore be more objective than many of our colleagues.

We can ask heretical questions such as why OOP should be used in all programming situations as many of its proponents insist. We can question the wisdom of allowing C programmers to write the narratives and code examples for the Help system in VB.NET. We can wonder why structures are included in VB.NET if OOP experts insist that you should never use them.

We can freely applaud VB.NET when it improves on traditional VB programming features (streaming and serialization, for instance), and point out when VB.NET creates needless confusion. (Some collections in VB.NET are zero-based; some are one-based. And there's no rhyme or reason involved, no pattern you can discover, no rule you can learn, to deal with this problem.)

Another benefit of being outside programming and academic officialdom is that we can be clear. There is a lingo developing around programming, and too much of it appears to serve no real purpose other than job protection. If others cannot read your source code, or even understand your comments, then it's likely they'll respect you and you'll keep your job. Likewise, if you follow the party line and keep your geek-speak up-to-date, you'll be on the team. So the usual little closed society of a priest class is being built. Remember that only a short time ago mass was said in Latin, a language that the churchgoers couldn't understand. And if you visit a college class in music theory or film theory today, you won't comprehend most of what's being said.

When we do now and then indulge in techie jargon in this book, it's usually to let you know what's meant by the latest catchphrases. True, the term overloaded signature is used in this book, but right next to it is the parenthetical explanation (more than one argument list), just so you'll know what the heck is being discussed. And when terminology, such as strongly typed, has several different meanings, we point that out to you.

There's one final benefit derived from the authors' status as independent writers, free of any obligation to particular corporations or institutions: we can be entertaining, or at least less boring than the average computer book. Academic articles and books, including many programming books, deliberately avoid amusing or interesting writing. It's thought in some circles that if your writing isn't obscure or tedious, then you must not be discussing anything sufficiently serious. We take the position that honest, understandable, direct, and interesting writing is preferable to the alternative.

Who Should Read This Book, and Why?

This book is intended to provide solutions for programmers who are ready to take the next step up to more complex, cutting-edge, or sophisticated topics. Chapters 1 and 2 are useful if you're making the transition to VB.NET from another programming language (such as classic Visual Basic, versions 6 and earlier).

This book is, we believe, accessible to any intelligent person with programming experience. We have tried to be clear throughout the book, explaining everything as directly as possible, regardless of degree of difficulty of the various topics.

Team Fly