Complexity and the Avant-Garde

Team Fly

Page xx

math (or science) and programming—just as there is often very little relationship in general between many other academic studies and the real world.

Consider the primary current computer applications: word processing, database management, Internet communications, and spreadsheets. Only spreadsheets have much at all to do with math. Programming can, of course, involve math, but it's rarely central to the programmer's task. You could write an entire word processing program without even knowing long division, much less algebra or anything beyond.

And programming obviously isn't a science. Science involves theorizing and controlled experimentation, behaviors rarely associated with programming. Sure, there's a kind of experimental hacking that goes on while trying to fix bugs—but that's not scientific experimentation by any stretch of the imagination. Debugging is much closer to searching for a lost set of keys than sending a kite up into a thunderstorm.

Programming is basically communication—albeit between humans and machines. But it is a linguistic and expressive act. It's not exactly rhetorical (we don't need to persuade the machines, at least not yet). But it's certainly descriptive, grammatical, and fundamentally communicative.

The two chapters in this book that some will consider ''unscientific" are Chapter 21, "Designing the User Interface," and Chapter 20, "Fractals: Infinity Made Visible." We agree. But then we think the entire subject of programming is unscientific, and we're not bothered by that fact.

Most of the remaining topics in this book fall into the second category: topics that are either too cutting-edge or too complex for inclusion in many books. For example, not much is written about VB.NET's splendid and extensive security features—even though security is a primary ongoing challenge for the computing community.

Security-related VB.NET programming is avoided not because the programming involved is inherently difficult or novel, but rather because the concepts underlying cryptology and other aspects of security are fundamentally complex. Many computer book authors simply don't know enough about encryption, for example, to explain its implementation in computer programming. Fortunately, cryptology has long been a hobby of one of the authors of this book.

Other topics are perhaps too new to be widely understood or implemented. Asynchronous programming, Web services, employing Office objects, using reflection, and the new .NET Compact Framework (how to squeeze programming and I/O into the highly restrictive platform of small, portable devices such as PDAs and cell phones) all fall into this category.

Several of the chapters in this book, we admit, have been covered fairly extensively in other books (database programming, debugging, printing), but we included them because we feel that we have something new to say. For example, we've yet to find any book that correctly describes how to print hard copy in VB.NET. All the programming examples we've seen either cut letters in half at the end of lines, or cut lines in half at the end of pages. This doesn't happen on every line or at the end of every page, but you'll agree that it's pretty bad when it happens even intermittently. If you've been looking for the solution to this problem, see Chapter 7.

Chapter 1 is unusual because it tackles an essential, yet widely avoided, question: Why was Visual Basic .NET designed by C programmers, and what are the implications? It's as if the Romans had been given the job of rebuilding Thebes—the result might be impressive, but it certainly wouldn't remain Egyptian.

Team Fly