On 9 Sep 99, at 1:17, Robert J. Bradbury wrote:
> I'd suggest you look in the mirror, for that is what *you* are.
> The *only* real question regarding nanomachines, is *how*
> difficult is "hard/dry" (diamondoid/sapphire) nanotech vs.
> "soft/wet" (protein/DNA/organic molecule) nanotech.
Do you think we're likely to understand the functioning of cells well enough that we could program them to build complex structures, and create specialized, human designed, offspring in the foreseeable future? How well is the process of human development from a single cell understood? Do we understand how a cell knows it's in the right place to become a liver cell, etc. Do we understand how we go from strings of amino acid specifiers in DNA to more complex cellular structures? (These aren't rhetorical questions - All I've got is some high-school bio and too much science fiction...)
When I think about the nanotech software question, I imagine an automaton with a general-purpose computer and mechanisms to reproduce and drop/detect some alphabet of chemical messages. Given this idealized scenario, I try to image how to go about designing a program for automaton 0 that will eventually lead to some interesting configuration of N automata. (shapes, patterns, images, etc.)
These are very hard problems to think about - the flow of the system is extremely complex and dynamic. To predict the behavior of the system at some point in time, you need to know the complete state of the system, which requires knowing how the system behaved in the previous time-step, etc. The feedback process leads to very simple programs with extremely complicated behavior.
> > How do you deal with the problem of mutation?
> Mutation of what? Your assembly instructions? These have ECC
> (Error Correction Codes) in the host computer and potentially
> in the transmission. You simply increase the size of the ECC code
> until the error rate gets low enough that the assembly must
> be reliable.
I really meant random bit-flips in the machine's local/working memory. It seems to be the small you make something the more vulnerable it is likely to be to cosmic rays, etc. You would certainly place some kind of error correction mechanism in that memory, but the shear number of possible events (number of nanites, local memory size, length of time) makes this a rather expensive proposition. Maybe you need antibody nanites that float around checking the program of anyone they bump into and destroying mutants.
> > I think it's fair to say that the development of software
engineering
> > processes has lagged eons behind machine advances and,
more
> > importantly, the growth in complexity of the systems we want to
> > build.
>
> Yes. It is interesting that we can build very complex machines that
> function quite well but cannot build complex sequences of
instructions
> that function equivalently well. Is this a problem with simply
> testing and software failure modes or is it something else?
I think there is something different about software. It's dynamic nature makes is much more difficult (if not possible) to analyze than more traditional engineering tasks, and the range of things you can do in software is much larger and much less well understood. There are also cultural problems - poor quality programming tools/languages, drifting requirements, and more demand for software than there are people who know how to produce it. (I've got a whole rant on the state of the industry, so be careful about getting me started...)
> > I recently got to visit Cray Research in Eagen, Minnesota, and
was taken
> > on a tour of the machine room.
> Cool! I'm jealous.
>
> > They run SETI at home at a low priority, so when sales isn't
trying to
> > optimize a potential customer's Fortran they're all searching for
signal.
>
> Such a waste, I need to go give them a lecture on the impact of
> nanotechnology on the development of ET and how evolving
nanomachinery
> would be the coolest application of that unused horsepower.
Well, it's not a waste if we find something...
-matt