From: Ramez Naam (mez@apexnano.com)
Date: Tue Nov 26 2002 - 20:26:43 MST
From: Anders Sandberg [mailto:asa@nada.kth.se]
> I think there is a difference. To make a car-making swarm you
> don't try to design 10^20 assemblers of a few billion atoms
> each and then simulate the whole system at atomic precision.
> It would be as ridiculous as putting together the car atom by
> atom by STM. Instead you design one assembler "by hand",
> first by making the important core functions and simulating
> them carefully, then by adding the extras like coating,
> running the entire assembler on first simplified code and
> then more and more exact code and tricky environments.
Ahh, here again I've done what Robert Bradbury pointed out and
combined too many design issues into one, losing clarity along the
way.
You're absolutely right: at the point at which you have the assemblers
designed, you don't use atomic precision to model the whole swarm.
That having been said, modeling the behavior of the swarm to build the
car is in and of itself a /second/ daunting design problem, one that
is also far beyond our current understanding. And again, I feel that
no one has provided a plausible mathematical analysis of just how
complex this problem is.
Extraordinary claims require extraordinary evidence. So if someone
says to me that we will be able to write software that effectively
manages swarms of billions (trillions? quadrillions?) of assemblers
from the /bottom up/ and directs them to build things like cars, then
I would like some deep analysis to back that up. I appreciate the
kind of qualitative thinking you're doing here, and much of it seems
plausible to me, but it's not really rigorous enough to be convincing.
I'm not finding any fault with you or Drexler or anyone on this list
here - this is a very tough problem to analyze and I'm personally a
bit stumped as to how to go about producing the deep, rigorous,
mathematically-grounded analysis of the command and control problem
that I would like to see. If I ever make much headway, I'm sure I'll
try to publish it. :)
> I think one can learn much from programming and software design here
> (although I have no doubt that there will be plenty of hacks
> and crufy code in nanotech too - which is seriously worrying).
> Creating strict interfaces and abstraction barriers is a way of
> managing complexity, be it code or atoms.
Indeed. I spent the last several years of my life managing the
development of software projects with millions of lines of code -
projects that consumed thousands of man-years of development and
testing time. My experience in that field is that humans are
extremely bad at producing software that behaves reliably and
predictably. No software engineering methodology that I have ever
encountered has made more than a small dent in that belief. And the
command and control problems of nanotech dwarf any software
development problem mankind has ever undertaken.
cheers,
mez
This archive was generated by hypermail 2.1.5 : Wed Jan 15 2003 - 17:58:25 MST