Little Engines That Could

Nanotechnology is a big deal in Michael's mind this month.


March 01, 1999
URL:http://www.drdobbs.com/little-engines-that-could/184410886

Mar99: Little Engines That Could

Michael is editor-at-large for DDJ. He can be contacted at [email protected].


Sidebar: Paradigms Past: Learning to Debug

A scientist becomes a perfect superman after injecting himself with self-replicating microscopic machines that continually repair his organs. A man rents a device that sets tiny machines loose in his brain, rewiring it so that he becomes, for a brief time, a different person. A cell-repair nanotech machine -- a "nanny" -- fed with one person's DNA and set to repairing another's cells, begins turning the second person into the first. Infoviruses systematically reprogram human genes, redirecting evolution. Society is reshaped from top to bottom by nanotechnology. Experimental nanomachines escape from the lab and destroy the world.

Mere science fiction, you say? Of course. Specifically, these are the plots of several science fiction stories appearing in Nanotech, a collection of cautionary tales in the subgenre of nanotechnology-based science fiction, edited by Jack Dann and Gardner Dozios (Ace Books, 1998; ISBN 0-441-00585-3). Science fiction writers were profoundly influenced by the publication of Eric Drexler's Engines of Creation (Anchor Books, 1987; ISBN 0-38-519-973-2). In that book and in the more technical Nanosystems: Molecular Machinery, Manufacturing, and Computation (John Wiley & Sons, 1992; ISBN 0-47-157-518-6), Drexler defined the field of nanotechnology, mapped out its challenges, and articulated its most promising avenues of research. A number of science fiction writers staked out nanotech as their chosen science to fictionalize, and a subgenre was born.

Others besides science fiction writers were influenced by Engines of Creation. Researchers around the world have been exploring the possibilities for nanotechnology since the book's publication. Last fall, Drexler's Foresight Institute brought the leading researchers together to explore the state of the art in nanotechnology today. In this month's column I'll explore the conclusions of the Foresight conference (and a couple of other little issues, such as a groundbreaking new programming language for little people). So far, none of the predictions of nanotech science fiction have come true. So far.

EDSAC Lives

But first, this: A visit to http://www .dcs.warwick.ac.uk/~edsac/ will reward anyone interested in the history of computing. It's where you can view screen shots, read the description, and download a copy of the EDSAC simulator. EDSAC was the first stored-program computer to operate a regular computing service. It was designed and built at Cambridge University, England, and it went online 50 years ago.

Closeted in a top-floor room of the university's Mathematical Laboratory, EDSAC filled dozens of racks and was flanked by three round CRTs that displayed the contents of memory in a grid of glowing spots, and a table holding the paper-tape reader and teleprinter. Unlike ENIAC, there was no bank of switches to set to enter calculations; EDSAC was a true stored-program computer, and got its input from paper tape. The simulator, which has all the controls and displays of the original EDSAC, simulates the CRT grid to show the contents of main memory, and shows the accumulator and other registers, elapsed time, and teleprinter output. User controls include Clear, Start, Reset, Stop, Single E.P., and single-digit entry. PC and Mac versions are available.

20/20 Foresight

Now, back to the nanofuture. Engineering is a clumsy discipline, because we are big and clumsy beings. It's ultimately all about moving atoms, but our fingers are too large to place each individual atom where we want it, and so are the tools that we use in place of fingers. What we need, in order to manipulate individual atoms -- or at least molecules -- and thus realize the full possibilities of engineering, are new tools. Very tiny, very precise tools.

We should be able to build these tools, but there is a Catch-22: To build such precision tools, we need the very tools we are trying to build. Or something very like them. Is there a way to bootstrap the process, and somehow get past the Catch-22 and on to doing perfect engineering, with all the wonderful benefits that this would bring? There may be.

In 1957, physicist Richard Feynman wrote:

Principles of physics, as far as I can see, do not speak against the possibility of maneuvering things atom by atom. It is not an attempt to violate any laws; it is something, in principle, that can be done; but in practice, it has not been done because we are too big.

To some, Feynman's speculation on atom-by-atom manufacturing was a call to arms. The field that has emerged as a result of their response to Feynman's challenge is called "nanotechnology." Today, to quote NASA Ames's Stephen Walch, one of the leading nanotechnologists:

A number of people are currently working on the possibility of manufacturing miniature machinery one atom at a time as Feynman had visualized it. The concept is referred to as molecular manufacturing and would have tremendous application in many areas...

Last November, researchers from all over the world gathered in Silicon Valley to share the latest developments in nanotechnology and the subdiscipline of molecular manufacturing, and to examine how close the field is to realizing any of those applications.

In the long term, nanotechnology's proponents expect it "to bring atomic precision to fields ranging from medicine to manufacturing, curing most diseases and eliminating chemical pollution." Add to that the wonders of superstrong, superlight materials and microscopic processors, and you can see why nanotechnology speaks so compellingly to science fiction writers.

Little Gems of Research

In the shorter term, progress in nanotechnology is most obviously recognized in the Foresight Institute's Feynman Prizes, of which it awarded two at last fall's conference, one for theoretical and one for experimental work.

The theoretical Feynman Prize went to Xerox PARC's Ralph Merkle and the aforementioned Stephen Walch for developing computational models of molecular tools.

Merkle, nanotechnology pioneer Eric Drexler, and others have articulated one particular model for nanomanufacturing, in which atoms are moved into place via reactive tools on the end of a probe. Merkle and Walch did the math for this model, to determine which reaction sequences work and which don't for the specific problem of placing a single carbon atom or two carbon atoms on the surface of a diamond. Diamond, having nice properties for manufacturing and a stable crystal structure, is a target building material for much nanoresearch. Since nanomachines would be able to manufacture diamond in any quantity, cost would not be an issue. Merkle and Walch cleared a trail a significant distance in the direction of such nanomanufacturing. Merkle's work can be seen at http://nano .xerox.com/nano/.

M. Reza Ghadiri of Scripps Research Institute got the experimental Feynman Prize for "his groundbreaking work in constructing molecular structures through the use of self organization, the same forces used to assemble the molecular machine systems found in nature." In Ghadiri's lab, researchers have designed and built a number of self-assembling nanotubes. Ghadiri's work is described at his web site (http://www.scripps.edu/pub/ghadiri/), and you can watch an animation of the replication process at http://www.scripps .edu/pub/ghadiri/html/selfrepli.html. These tiny tubes may one day prove useful as nanoscale wires or drug delivery systems.

A Biopowered Nanomotor

In other work reported at the conference, a team of nanoresearchers at Cornell is hard at work trying to integrate organic and inorganic machines into hybrid systems. By "organic machines" they mean biological molecules like F1-ATPase, a protein that can reasonably be described as a motor. F1-ATPase gets into a spin over the synthesis/hydrolysis of ATP, generating a force of over 100 pN and twirling around at something short of its calculated no-load rotational velocity of 17 rps. This organic machine has a diameter of less than 12 nm, smaller than any inorganic machine that anyone has yet been able to build.

But they're getting close. The Cornell researchers, whose work is described at http://www.foresight.org/, are working with nanodevices that are on a scale compatible with F1-ATPase. If they can combine manufactured, inorganic devices with these organic motors, there may come a day when, as they predict, "F1-ATPase motors will pump fluids, and open and close valves in microfluidic devices, and provide mechanical drives for a new class of nanomechanical devices." F1-ATPase occurs naturally in practically every living organism, and is automatically synthesized by the machinery of life. If it can be integrated with inorganic nanomachinery, it could be the key to creating a transparent interface between the organic and inorganic worlds. The researchers have come a long way. They have already figured out how to manipulate the protein's coding sequence, produce large quantities of the protein, and "place specific 'handles' on the enzyme for the precise attachment to nanofabricated devices and substrates." Now they're looking into issues like heat dissipation, but basically, all the tools are now in place to build biological-motor-powered mechanical devices within a living cell.

If all the details work out, "these efforts will provide a significant step toward the seamless integration of nanoscale technologies into [a] living system, and are central to the creation of organic/inorganic intelligent systems," they say.

Nanomanipulators

The nanoresearchers who gave presentations at the conference routinely fiddle with exotic microscopic structures with names such as fullerenes, buckyballs, bucky horns, and nanotubes in their quest for control of the very small. But it's more accurate to say they try to fiddle with these little doodads. In fact, manipulation of such nanoscale devices is more or less the near-term goal of nanotechnology.

One session at the conference demonstrated achievement of that goal. Washington University student Min Feng Yu showed a movie (you can see it at http://www.foresight.org/) of a real breakthrough -- the direct manipulation, independently in all three dimensions plus rotation, of a 5 nm-diameter nanotube.

It was done by connecting the tube to two atomic force microscope tips. The technique can be used to assemble nanodevices, but more subtly, it is now possible to manipulate the tubes so as to study the effects of strain and force on them. This is important because knowing the structural properties of the materials is crucial to being able to build with them.

Nansistors

Dozens of other researchers described their small advances at the conference. Cees Dekker of Delft University of Technology in The Netherlands described a field-effect nanotube transistor, a TubeFET. Mark Akeson of the University of California at Santa Cruz described how he has developed a device for reading nucleic acid strands; the most obvious application being sequencing of individual DNA strands at very high rates.

Fotis Nifiatis at CUNY won the Distinguished Student Award for research in molecular self assembly.

Stepping back from the excitement the conference generated among its attendees, it is clear that there is still a long way to go before the full possibilities, or any possibilities, of the application of nanotechnology will be realized. Considering what some of those possibilities are -- and I don't think that the science fiction writers are overreacting -- maybe we should be glad of that. But Drexler's original outline of the field acknowledged that the road would be a long one, and so far the work seems to be right on track.

ToonTalk

ToonTalk is a programming language and environment for children. Currently it only runs under Windows. You can download a trial version of it from http://www .toontalk.com/.

Ken Kahn has been developing ToonTalk for years, and released it just recently. It draws on a number of computer games and programming models, including Rocky's Boots, Zelda, and other adventure games, the concurrent constraint programming language Janus, Carl Hewitt's Actor programming language, Logo and Smalltalk, and Jaron Lanier's Grasp language. It is worth a look, particularly for the remarkably successful way it makes abstract programming concepts visible.

In ToonTalk, you, the programmer, are represented in the model by an animated character. You program by moving about ToonTalk's world as you would in a computer game, picking up objects and manipulating and combining them.

Often what you pick up are boxes. Boxes are the data cells of ToonTalk, and can contain any kind of data. Boxes click together like Lego blocks to construct data structures akin to arrays or tuples. There are primitive data types such as numbers, and instances of these types can be dropped into boxes. Tapping the contents of a box with a wand makes a copy of it, and dropping one thing on another combines them in a meaningful way (adding numbers, for example).

In addition to the wand, there are a number of colorful tools for operating on the things you construct. A vacuum cleaner turns out to be a good way to make cut-and-paste visible, but it has another use that is rather subtle. Dropping the number 1 in a box and then turning the vacuum cleaner on it sucks out the value of the number, leaving a box with an unspecified number in it. This technique of sucking out the value is a clever way of making visible the general idea of a variable, a parameter placeholder, or a template.

The tutorials use this trick well. Concrete problems are posed, involving fixed values. Then concrete elements are replaced with abstract placeholders, generalizing the problem.

The functionality of programs is embodied in robots and cities, robots representing methods and cities representing programs or computations. A cartoon thought balloon above a robot's head shows what's on his mind. To give him ideas about particular data structures and what to do with them, you drop boxes into his thought balloon and do things to their contents, abstracting the concrete actions to construct a general method. The chief decision tool is a scale.

The tutorials and demos supplied with the full release version show how to combine data structures and methods into objects by pasting boxes and robots to the backs of pictures. Full objects are represented by houses. The demos also show how to spawn new processes (the metaphor is a truck) and they demonstrate techniques in logic programming, string manipulation, and recursive data structure construction. Robots can be combined in teams, and you can save your programs in a notebook. ToonTalk is a true concurrent programming language supporting the dynamic creation and termination of communicating asynchronous processes. The communication metaphor involves pigeons and nests. Pigeons carry messages between objects, and an object will only welcome a pigeon carrying a box that matches the (template) box in the object's nest. The most remarkable thing about ToonTalk is how far Kahn has gone in animating the construction of programs and the action of the constructed programs. This is by no means easy, one reason being that if you can see the program running, it's obviously running too slowly. ToonTalk's solution? Robots, like employees in the Bizarro world, work really fast when nobody's watching them.

DDJ


Copyright © 1999, Dr. Dobb's Journal
Mar99: Paradigms Past: Learning to Debug

Dr. Dobb's Journal March 1999

Paradigms Past: Learning to Debug


When EDSAC, the Electronic Delay Storage Automatic Computer, went online in 1949, no one had any significant experience in computer programming. The first program to run on the machine, written by the guy who caused it to be, Maurice Wilkes, was trivial: It computed the squares of the first n integers. Wilkes coded up the program in EDSAC's 18-instruction machine language, a clerk punched the paper tape and fed it to EDSAC, and the program ran flawlessly. The same with the second and third programs, which printed a more complicated table of squares and a table of prime numbers. No one thought it should be otherwise: You spent the necessary time to get the program right, then you gave it to the computer and it ran. The idea that there might be logical or transcription errors in the submitted code, or that the erroneous output of the computer could be used to find the errors, apparently hadn't occurred to anyone.

That era of blissful ignorance ended quickly and dramatically with the next program Wilkes submitted to EDSAC. According to Ivars Peterson, mathematics and physics writer at Science News and author of several books on mathematics and computing, you could just about build a course in debugging around all the errors Wilkes made in his first nontrivial program for EDSAC.

The problem Wilkes set for EDSAC was solving the Airy equation, a second-order differential equation that explains rainbows and has found application in quantum gravity and string theory. Peterson describes, at http://www.maa.org/ mathland/mathland_7_8.html, Wilkes's first attempt to program the solution to the Airy equation. There were 20 mistakes in the 126-line program.

Some were keypunching errors, like punching a V for a U. In some places Wilkes apparently wrote instructions in a skeletal form and then forget to add flesh to the bones. There were instructions in the wrong order, and missing instructions. It seems clear that Wilkes neither checked the program before giving it to the keypunch operator, nor verified the punched version.

Of course, the program didn't work, and Wilkes had to try to find the errors and correct them. He had many opportunities to find and correct his errors in this program over the succeeding days. The keypunch machine was on the floor below, and Wilkes later recalled, "It was on one of my journeys between the EDSAC room and the punching equipment that...the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."

Wilkes had discovered the debugging cycle.

-- M.S.


Copyright © 1999, Dr. Dobb's Journal

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.