Foreword

I

suggested to my brother Todd, who is making the leap from hardware into

programming, that the next big revolution will be in genetic engineering.

We’ll

have microbes designed to make food, fuel and plastic; they’ll clean up

pollution and in general allow us to master the manipulation of the physical

world for a fraction of what it costs now. I claimed that it would make the

computer revolution look small in comparison.

Then

I realized I was making a mistake common to science fiction writers: getting

lost in the technology (which is of course easy to do in science fiction). An

experienced writer knows that the story is never about the things; it’s

about the people. Genetics will have a very large impact on our lives, but

I’m not so sure it will dwarf the computer revolution – or at least

the information revolution. Information is about talking to each other: yes,

cars and shoes and especially genetic cures are important, but in the end those

are just trappings. What truly matters is how we relate to the world. And so

much of that is about communication.

This

book is a case in point. A majority of folks thought I was very bold or a

little crazy to put the entire thing up on the Web. “Why would anyone buy

it?” they asked. If I had been of a more conservative nature I

wouldn’t have done it, but I really didn’t want to write another

computer book in the same old way. I didn’t know what would happen but it

turned out to be the smartest thing I’ve ever done with a book.

For

one thing, people started sending in corrections. This has been an amazing

process, because folks have looked into every nook and cranny and caught both

technical and grammatical errors, and I’ve been able to eliminate bugs of

all sorts that I know would have otherwise slipped through. People have been

simply terrific about this, very often saying “Now, I don’t mean

this in a critical way” and then giving me a collection of errors

I’m sure I never would have found. I feel like this has been a kind of

group process and it has really made the book into something special.

But

then I started hearing “OK, fine, it’s nice you’ve put up an

electronic version, but I want a printed and bound copy from a real

publisher.” I tried very hard to make it easy for everyone to print it

out in a nice looking format but it didn’t stem the demand for the

published book. Most people don’t want to read the entire book on screen,

and hauling around a sheaf of papers, no matter how nicely printed,

didn’t appeal to them either (plus I think it’s not so cheap in

terms of laser printer toner). It seems that the computer revolution

won’t put publishers out of business, after all. However, one student

suggested this may become a model for future publishing: books will be

published on the Web first, and only if sufficient interest warrants it will

the book be put on paper. Currently, the great majority of books of all kinds

are financial failures, and perhaps this new approach could make the publishing

industry more profitable.

This

book became an enlightening experience for me in another way. I originally

approached Java as “just another programming language,” which in

many senses it is. But as time passed and I studied it more deeply, I began to

see that the fundamental intention of the language is different than in all the

other languages I have seen.

Programming

is about managing complexity: the complexity of the problem you want to solve

laid upon the complexity of the machine in which it is solved. Because of this

complexity, most of our programming projects fail. And yet of all the

programming languages that I am aware, none of them have gone all out and

decided that their main design goal would be to conquer the complexity of

developing and maintaining programs. Of course, many language design decisions

were made with complexity in mind, but at some point there were always some

other issues that were considered essential to be added into the mix.

Inevitably, those other issues are what causes programmers to eventually

“hit the wall” with that language. For example, C++ had to be

backwards-compatible with C (to allow easy migration for C programmers), as

well as efficient. Those are both very useful goals and account for much of the

success of C++, but they also expose extra complexity that prevents some

projects from being finished (certainly, you can blame programmers and

management, but if a language can help by catching your mistakes, why

shouldn’t it?). As another example, Visual Basic (VB) was tied to BASIC,

which wasn’t really designed to be an extensible language, so all the

extensions piled upon VB have produced some truly horrible and un-maintainable

syntax. On the other hand, C++, VB and other languages like Smalltalk had some

of their design efforts focused on the issue of complexity and as a result are

remarkably successful in solving certain types of problems.

What

has impressed me most as I have come to understand Java is what seems like an

unflinching goal of reducing complexity

.

As if to say “we don’t care about anything except reducing the time

and difficulty of producing robust code.” In the early days, this goal

has resulted in code that doesn’t run very fast (although there have been

many promises made about how quickly Java will someday run) but it has indeed

produced amazing reductions in development time; half or less of the time that

it takes to create an equivalent C++ program. This result alone can save

incredible amounts of time and money, but Java doesn’t stop there. It

goes on to wrap all the complex tasks that have become important, such as

multithreading and network programming, in language features or libraries that

can at times make those tasks trivial. And finally, it tackles some really big

complexity problems: cross-platform programs, dynamic code changes, and even

security, each of which can fit on your complexity spectrum anywhere from

“impediment” to “show-stopper.” So despite the

performance problems we’ve seen, the promise of Java is tremendous: it

can make us significantly more productive programmers.

One

of the places I see the greatest impact for this is on the Web. Network

programming has always been hard, and Java makes it easy (and they’re

working on making it easier all the time). Network programming is how we talk

to each other more effectively and cheaply than we ever have with telephones

(email alone has revolutionized many businesses). As we talk to each other

more, amazing things begin to happen, possibly more amazing even than the

promise of genetic engineering.

In

all ways: creating the programs, working in teams to create the programs,

building user interfaces so the programs can communicate with the user, running

the programs on different types of machines, and easily writing programs that

communicate across the Internet – Java increases the communication

bandwidth

.

And I think that perhaps the results of the communication revolution will not

be seen from the effects of moving large quantities of bits around. We shall

see the true revolution because we will all be able to talk to each other more

easily – one-on-one, but also in groups and as a planet. I

’

ve heard it

suggested that the next revolution is the formation of a kind of global mind

which results from enough people and enough interconnectedness. Java may or may

not be the tool that foments that revolution, but at least the possibility has

made me feel like I

’

m doing something meaningful here by attempting to teach

the language.

(

|

|