Evolution
Evolution binds the otherwise unrelated topics I discuss this time. On one hand, a science fiction novel shows what might happen if fate should bring together the right mixture of nanotechnology, bacteria, viruses, solar power, agent software, adaptive self-organizing systems, rapid evolution, and corporate malfeasance. On the other hand, products I have been reviewing (and using) for more than fifteen years, continue their steady evolution.
Prey by Michael Crichton (Harper Collins, NY, 2002, 382pp, ISBN 0-06-621412-2, $26.95)
In this novel, Michael Crichton, already famous for his earlier works, The Andromeda Strain and Jurassic Park, places current technologies into a completely plausible situation, then develops the story into an engrossing thriller. Somewhere in the process he crosses the line from believable to unbelievable. I'm not sure of the exact point in the book when I started to feel that way, but by the time I did, I was already hooked.
I should say at the outset that I did not read this book. I listened to it in 45-minute chunks while driving. George Wilson's reading nicely conveys the matter-of-fact tone in which the protagonist, Jack Forman, a programming manager, recounts his attempts to rein in a project that has gone badly and dangerously out of control.
Forman, fired for blowing the whistle on questionable corporate accounting practices, has been an unemployed house husband for many months when his former company calls him to consult. They have sold Forman's software to another company, which is having trouble with it. The new company, it turns out, is Xymos, the firm for which Forman's wife is a marketing director. She looks at Xymos as her last chance to make a fortune, and she has cut a few corners to bring the story to this point. She should have read some of the project management books that I reviewed recently in this column. They could have saved her from a lot of trouble, but then there would be no story.
Forman heads for the remote desert facility where the problem is, and he finds that Xymos has used agent software that Forman's team had developed at the first company. The software produces agents that exhibit predator-prey behavior, but Xymos has put the agents to another use -- a military contract to create a spy camera made from a swarm of billions of nanomachines.
Unable to solve the problem of how to prevent air currents from disrupting the swarm's structure, Xymos has turned swarms loose in the desert to see if a solution emerges as they evolve. Through a series of plausible circumstances, the swarms can use solar power and already carry with them their means of manufacture when Xymos turns them loose. They multiply and evolve at a rapid rate. Adaptive behaviors emerge. Humans become their prey, and it looks as if they have a good chance of wiping us out. From this point, the novelist takes over and carries the story forward to its conclusion.
Prey reminds me of a book that was one of my favorites when I was an avid science fiction fan, about 50 years ago. Hal Clement was a high school science teacher who wrote science fiction in his spare time. He built his stories on real science. They were realistic and believable to a large degree. In his novel Needle, two members of an alien race come to Earth -- one a fugitive and one a pursuing police officer. Members of this alien race live by symbiosis, a relationship in which they and their hosts help, but never harm each other. The fugitive has violated this rule. This contributes to the danger that leads to the book's exciting conclusion. In Prey, one strain of the evolving swarms of nanomachines develops a behavior much like symbiosis, contributing added suspense to the climax.
When I read Prey, I thought of many books and concepts that I have reviewed in this column over the years.
Daniel Dennett, in Consciousness Explained (Micro Review, Mar/Apr 1992) talks about the parallel architecture that the billions of neurons of the brain have organized themselves into. Adaptive self-organizing systems are at least as ancient as humans, but we have only begun to understand such systems in the last decade or so. Prey reminds us that humans are not necessarily the only creatures capable of pursuing their own goals powerfully and efficiently, to the detriment of their fellow Earthlings.
Mitchel Resnick, in Turtles, Termites, and Traffic Jams -- Explorations in Massively Parallel Microworlds (Micro Review, Nov/Dec 1994), says that no leader directs birds to fly in formation or ants to form trails from their nests to food sources. Instead, large numbers of independent entities, each following simple rules, produce the large scale patterns that we observe. This is the principle that makes Crichton's Prey plausible.
The theme of that Nov/Dec 1994 column was decentralization. In addition to Resnick's book I talked about object-oriented programming and the Internet, two areas that have evolved enormously since then, both seemingly without any central direction.
In my July/Aug 1997 column, I reviewed George Dyson's book Darwin Among the Machines: The Evolution of Global Intelligence.
Dyson tries to understand many of the themes that underlie Prey. He starts with the work of Thomas Hobbes, over 350 years ago. Hobbes' Leviathan is a group intelligence representing the future of human society. Hobbes believed that life arises from the physical behavior of the underlying objects. The parts of the body give rise to a person whose life and thought are of a higher order than those of its heart, nerves, or muscles. Similarly, people, their institutions, and their machines give rise to a group intelligence of even higher order. This, of course, is what happens with the swarms of nanomachines in Prey.
Dyson's book is short, but intricate and profound. It covers a lot of ground quickly. One subject he touches briefly is the work of Thomas Ray in creating Tierra, a globally networked habitat in which digital organisms can interact and evolve.
In the end, Dyson says:
In the game of life and evolution there are three players at the table: human beings, nature, and machines. I am firmly on the side of nature. But nature, I suspect, is on the side of the machines.
In my July/Aug 2000 column, I looked at Bill Joy's article in the April 2000 issue of Wired. Joy cites three technologies in which our progress is outpacing our ability to control them: genetics, nanotechnology, and robotics. He calls attention to some of the possible consequences of these technologies -- plague, intelligent germ warfare, out-of-control self-replicating robots, and many others. Michael Crichton relies heavily on all three of these technologies, and on some of the possible consequences Joy calls attention to, to create the nighmare scenario in Prey.
Joy's object in writing his article was to get people thinking about these issues. I hope that Crichton's book will contribute to that end too.
Prey is an enthralling thriller, but it is also an elaboration of many threads of thought in computer science and in the ethics of science. I highly recommend it.
Real Evolving Programs
Thinking about the rapid sort of evolution that Crichton allows his swarms of nanomachines to engage in made me think about some current software products that have evolved more slowly, and ostensibly under human control, over many years. In my June 1996 column, for example, I detailed the goals, evolutionary steps, and false starts that led from C to Java. The evolution of Java continues unabated, but still largely under the control of Sun Microsystems.
Unix provides another example. In Design of the Unix Operating System (Micro Review, October 1987), Maurice Bach describes a design process carried out under the control of AT&T Bell Laboratories, but beginning to break free. By the time Eric Raymond wrote The Cathedral and the Bazaar (Micro Review, Nov/Dec 1999), however, the open source movement and Unix had collided to produce Linux. Development of Linux is much more like a self-organizing system than Unix development under Bell Labs ever was.
BASIC
In 1967, before the invention of the microprocessor, I wrote BASIC programs on a General Electric timesharing system. The original BASIC was a very primitive language. Kemeny and Kurtz meant it only as a teaching tool. Every variable name was global, and represented by a single uppercase letter. Subroutine calls had no arguments; the routines took their input from global variables.
In the middle 1970s I wrote sophisticated clinical laboratory reporting programs, running on a DTC Microfile (an Intel 8080-based machine). I developed these using Microsoft BASIC, a much more robust language, but still burdened by the limitations of the original. In the years that followed, Microsoft ported BASIC to many microprocessor-based computers. My book Inside BASIC Games (Sybex, 1981) presents BASIC source programs that run virtually unchanged on Apple II, Comodore PET, and Radio Shack TRS-80 computers. Meanwhile, a huge number of commercial packages, programmed in BASIC and running on CP/M systems appeared. When IBM brought out the Personal Computer in 1982, BASIC was the most important software available on it.
With 16-bit microprocessors and the widespread use of Unix and C, BASIC faded in importance, but by the time I reviewed Microsoft Word for Windows 2.0 (Micro Review, December 1992), Microsoft had given BASIC a new role: letting users customize its packaged software. Then, with Visual Basic (Micro Review, October 1993), Microsoft reincarnated BASIC as a tool to allow developers to produce applications with graphical user interfaces (GUIs) to run on Windows.
In COM and DCOM -- Microsoft's Vision for Distributed Objects (Micro Review Mar/Apr 1998), Roger Sessions describes the position to which BASIC had evolved at Microsoft. He predicts a future in which programmers use Java, and to a lesser extent C++, to implement the logic of applications and use Visual Basic to implement the user interface. If we look at Microsoft's current plans for .NET, this prediction seems to be on target, though Microsoft would probably prefer that you substitute C# for Java in this scenario.
MKS Toolkit
MKS Toolkit 8.5 (MKS, Inc, www.mks.com, $359.00 and up)
This is the latest version of a software package that has a long evolutionary history. Mortice Kern Systems (now simply MKS, Inc) was founded to bring Unix style tools into the Microsoft environment. I reviewed MKS Toolkit 4.1 for DOS in the Jan/Feb 1993 Micro Review. By that time the product was already essentially in its current form. It provided the Korn shell, the vi editor, awk, make, tar, pipes, uucp, and all of the popular Unix utilities.
The toolkit's subsequent development has been in the direction of improving the symbiosis -- creating the Unix environment more completely and less disruptively, and adapting to the evolving host environment. Over the years the package has also picked up X.11 and Motif, and popular utilities like Perl and Tcl.
The latest version provides a secure shell for remote access, a much cleaner interface with Windows services, and a communications suite aimed at improving interprocess communication and notification.
Interestingly, the entry level toolkit still costs only about 20% more than the 1993 version, but MKS has implemented a tiered pricing structure in the last few versions. Professional or enterprise developers pay much higher prices, though the entry level version has all of the features that most developers would need.
The 1993 version came with a thick stack of manuals. The current version comes with a thin stack, but installs many PDFs and help files, which contain a great deal of information. The Cross-Platform Developer's Guide, supplied in both PDF and hardcopy, gives a good deal of insight into how hard it is to achieve symbiosis with a host like Windows.
There are other sets of Unix tools for the Windows environment, but for the nitty-gritty details of porting Unix programs into Windows systems, MKS Toolkit is still your best bet.
Visual SlickEdit
Visual SlickEdit 8 (SlickEdit, Inc, www.slickedit.com, $299)
This product has an interesting history. In the beginning, there were two notable programming editors: Bill Joy's vi and Richard Stallman's emacs. They are enormously powerful, but hard to learn, and both are in use today.
In the Nov/Dec 1988 Micro Review, I wrote:
The best program that I use on the PC, and the only one I would recommend unreservedly to anyone is the Brief editor (from Underware). It is the best editor I have ever used. It is modeless, meaning that commands always work the same way, regardless of what you're doing. It is easy to use immediately.
Not long afterward, Underware went out of business, and Brief is no more. Enter Visual SlickEdit (or simply SlickEdit, as it was first called). In my review of Visual SlickEdit 2 (Micro Review Sep/Oct 1996), I quote the manufacturer as saying that Visual SlickEdit emulates Brief so well that even its mother couldn't tell the difference. Visual SlickEdit also emulates vi and emacs, but soon after I started to use it, I moved to the Visual SlickEdit native user interface.
You can trace this product's origin to the vision of the company founder, Clark Maurer. His goal was to give programmers a single powerful, completely reliable, programmable editor that runs on every platform and supports every programming language. Maurer devised a macro language, Slick-C, used it for most standard extensions of the basic editor, and gave users access to it to design their own extensions.
Maurer's basic design approach for the product was to reach out to working programmers, to find the repetitive tasks and the error-prone situations in their daily routines, and to provide safe, automated support for those activities. Every version of this product that I have seen since then seems to have had that same goal. Features like language-specific tagging, auto-completion, a code beautifier, powerful tools for comparing and merging files, and support for builds are examples that subsequent versions have offered. The product supports XML, including schemas, and provides a native Java debugger. The latest version makes it easier for programmers to work with other programs for building and debugging software. You can run Ant scripts directly from the editor.
In their wonderful, must-read book The Pragmatic Programmer -- From Journeyman to Master (Micro Review, Jan/Feb 2000), Andrew Hunt and David Thomas stress the importance of obtaining a powerful programming editor and mastering its features completely. Doing this with Visual SlickEdit will more than repay the effort.
