The devil is in the interface

In the last three sections I have considered three systems that can make anything, including copies of themselves: the programmable organism, the computer with a "box" attached, and the economy. In the first and third cases, I was concerned with calibrating the complexity of the system. In the second case, my point was that the computer-plus-box has an interface which will be at least as difficult to use as the computer by itself. The interface problem applies to the other systems as well.

Let's go back to the general purpose, programmable organism. Consider just one of its subsystems, say the programmable ants.

The hypothesis is that you can control the ant genome (or the nanite genome) -- you can go in there and tweak it so the ants go out and build a different kind of structure, instead of what they are naturally wired to build. The question is: How would you have access to the genome? The user would have to be able to pick out certain genes, and modify them in certain ways to produce certain effects. There would have to be some kind of interface. It would be comparable to the interface of any other complex machinery.

Reprogramming a genome would be done at some kind of workstation, or perhaps an array of workstations, with monitors and control panels. Depending on the scale of the project, it might be comparable to an airplane cockpit, or it might resemble the NASA control room where the engineers sat during the Apollo flights.

 

Or it might just be one monitor with a command-line interface, plus a room full of apparatus (think of the labs in which genetic engineering is done now).

To get some idea of what is involved in this, see the IBM Systems Journal, vol 40, #2, 2001, particularly these articles:
(1) Transparent access to multiple bioinformatics information sources,
(2) GeneX: An Open Source gene expression database and integrated tool set,
(3) An integration platform for heterogeneous bioinformatics software components.

In the future, it will be easier to program cells than it is now. Someday there will be an IDE for cell programming, with a high level language instead of low-level DNA code. (This will be the topic of another Web site.) In any case, there will always be an interface.

Now, consider the economy. The concept of a genie machine was introduced on page 81 of Engines of Creation -- "What you ask for, it will produce." The economy will already produce whatever you ask for. That little word "ask" makes it look so simple -- the question is, how do you ask? As usual, the devil is in the details -- in this case, the details of the process of asking.

If you want a new BMW M5, well, they are rolling off the assembly line all the time. You just go to the nearest BMW dealer and ask for a car. Very simple. Of course, there is one little problem. You have to write a check. Then the car is yours.

The economy, like anything else, has an interface. The BMW dealer is part of the interface to the BMW factory, but only part. There is a lot more to it than that. If you have that kind of money, then you must have a job, or property, to generate an income. You must have a bank account and a credit rating. You have filled out quite a few forms, and spent years establishing yourself as an economic entity. Homeless people who have no property don't have to fill out forms -- everybody else does. The economy will produce whatever you ask for, but you have to push the right buttons, and you have to be in a position to push them. The more you ask the economy to give you, the more complex your interface with it. If you ask for jet planes and yachts, you can have them, but then you will have to hire accountants and tax lawyers, not to mention doing something to generate the money.

In the future, the BMW factory may be more automated than it is now. Some of the work may be done by robots. This possibility is considered in later sections. It doesn't alter the situation in any essential way. The economy will always have an interface. It will produce whatever you ask for, but when you ask, you have to have your credit card with you. That's how the interface works.

One night I was surfing and came across a site for a project at the University of Illinois where they use Mathematica to teach calculus. I thought the following paragraph was apropos:

Many prospective students are concerned that if they take C&M classes, they will not actually learn how to do any of the math, since 'The computer does all the work for you.' Fortunately, this is simply not true. Students cannot just present a problem to Mathematica and have the computer solve it from beginning to end. They must understand the problem well enough to be able to give Mathematica the right instructions to solve it. In cases where Mathematica has a higher-level function that is capable of doing all the work (such as Mathematica's Integrate command), students learn to break it apart and see how the computer does the work on a lower level. Mathematica is not a magic wand that can be waved at a math problem; it is a tool that requires as much thought and care to use effectively as pencil, paper, and calculator.

Mathematica will produce whatever you ask for in the realm of mathematics. If you ask for an animated graph of a complex function, it will generate the animation for you -- but you have to know how to ask, just like you have to know how to ask the Shape Shifter for what you want, or the programmable organism, or the computer with a "box" attached, or the economy.

There are no magic wands and never will be. All systems have interfaces. Whether the system is scattered over the face of the earth, or compressed into a desktop box, it still has an interface. It's not a question of what can or can't be done with atoms. It may indeed be possible to have nanotech systems that can "grow" rocket engines and many other things, but the more they can do, the more expertise required to use them. If you have a system that can do literally anything, then the interface will be as complex as the world itself.


next page: nailing down a conclusion about universal assemblers

back to the table of contents

home