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 (which
enables the genetic 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 that 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 all books 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 this language is
different from 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 of which 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
programs1. 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 cause programmers to eventually “hit the
wall” with that language. For example, C++ had to be backwardscompatible
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
unmaintainable syntax. Perl is backwards-compatible with Awk, Sed,
Grep, and other Unix tools it was meant to replace, and as a result is often
accused of producing “write-only code” (that is, after a few months you
can’t read it). On the other hand, C++, VB, Perl, 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 for the
programmer. 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 “showstopper.”
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 the Java
language designers are working on making it even easier). Network
programming is how we talk to each other more effectively and cheaper
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 between people. 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 that
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 by
attempting to teach the language.
.
.
Click Here to Download
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 (which
enables the genetic 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 that 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 all books 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 this language is
different from 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 of which 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
programs1. 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 cause programmers to eventually “hit the
wall” with that language. For example, C++ had to be backwardscompatible
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
unmaintainable syntax. Perl is backwards-compatible with Awk, Sed,
Grep, and other Unix tools it was meant to replace, and as a result is often
accused of producing “write-only code” (that is, after a few months you
can’t read it). On the other hand, C++, VB, Perl, 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 for the
programmer. 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 “showstopper.”
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 the Java
language designers are working on making it even easier). Network
programming is how we talk to each other more effectively and cheaper
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 between people. 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 that
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 by
attempting to teach the language.
.
.
Click Here to Download
ไม่มีความคิดเห็น:
แสดงความคิดเห็น