From: Matt Gingell (mjg223@is7.nyu.edu)
Date: Thu Sep 09 1999 - 16:14:49 MDT
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
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:05:05 MST