Re: Nanotech CAD software and politics (was Re: Military and nanotech)

Chris Phoenix wrote:

> Are they going to have to be accessible *at the same time*?  That would
> be very difficult for a designer to grasp.  If I have a "virtual
> material" to fill a volume with, I know what it does; I don't have to
> see what it's made of while I'm deciding its volume.  (Of course, if its
> properties change as its bounding volume changes, I'm in trouble.  But
> I'd rather just avoid those.)

That is exactly why you need a heirarchical view of the information/data 
structure/program.  There will be times when you have to look at an 
object and its environment, and other times when you will need to look 
at two heirarchical levels simultaneously.  But a good language design 
should make those cases exceptional and mutually exclusive.  This all 
goes unde the name of "information hiding" in computing literature.  A 
better name might be limited data views.  The whole structure is there 
to look at, but you want the programming tools--and language is a 
programming tool--to let you ignore what you consider to be unnecessary 
details while working on part of the design.  The compiler is 
responsible for making sure that if your code is legal with respect to 
what you see, all the "hidden" details are correct too.

> I'm not sure interfaces have to share space with multiple objects. 
> Perhaps they simply share a common surface, and half of the interface is
> attached to each object.  

What is an interface?  If you define it to be the surface between two 
adjacent structures you are right.  But I think a better definition 
includes any mechanism needed to convert signals crossing the interface. 
  For example, an interface between rod logic and electronic circuts 
could include sensors and actuators.

> No offense intended! :-)

None taken, I tend to think more like a hardware engineer than most 
software engineers due to my background.  (I know how to use a 
screwdriver AND a soldering iron.  And a brazing torch and a furnace, 
and a milling machine, and a punch press and...)

> I think human-scale MNT products won't have to worry about volume
> limitations.  They'll have far more volume than necessary to incorporate
> the active nanomachinery that fits their power budget.  
> 
> For a few products, such as some (but not all) medical devices and spy
> devices, it may be important to squeeze things as small as possible. 
> These things may merely be comparable to modern structures in
> complexity.  I'm not sure that automated design aids will be
> necessary--so they may not be widely accepted.
> 
> On the other hand, if you have all the space in the world, it's easy to
> write an automated design tool.  So maybe that mode of working will be
> the norm for most projects, and the algorithms will get smarter as
> people try to do more sophisticated and compact projects.
> 
> I wonder whether it'd be possible to make a design tool where you simply
> specify the top-level qualities, and *everything* gets put in place
> automatically, assuming it fits?  Is this what you've been arguing for
> all along?  Maybe so...

Read "Godel, Escher, Bach" if you want to understand what you are 
asking.  The closer you insist on getting to the smallest and lightest 
possible device to do what you want, the harder the problem of finding 
an acceptable design becomes.  At the limit, the problem of whether or 
not you can design a device using 123,234,345,456 atoms or you have to 
use 123,234,345,457 is NP-hard, and probably NP-complete.  (In other 
words if you can find a polynomial-time algorithm to solve one such set 
of problems, P=NP.  The question of whether or not P=NP is probably the 
hardest unresolved question in mathematics.  (If P=NP is unsolvable, it 
is unsolvable whether or not P=NP is unsolvable, so mathematican's can't 
get away from the problem that way.)

On the other hand, for any realistic problem the computational effort 
required will reach a minimum somewhere near 2x the hard (and hard to 
find) lower limit.  So it should be fairly easy to take "rough" designs 
and sweat most of the weight and bulk off of them before construction. 
Let's take a space ship as a case in point.  Would you rather build a 
100 ton space ship, or a 10 ton space ship with otherwise identical 
specifications?  The "extra cost" of design work to reduce the weight to 
10 tons will probably be much less than the cost differential of 
building the 100 ton design.  Is it going to be worth the effort to get 
it down to 9 tons?  Maybe.  Seven tons? Probably not.  Six tons?  You 
had better be planning on putting one in every garage.  Five tons?  It 
may take decades to determine whether or not it is possible.

> In that case, I can see why you'd want to spend a lot of effort
> designing the specification language.  But I think, for the diversity of
> products that people will want, and the diversity of properties they
> will want to specify, and the variety of levels at which the properties
> will have to be implemented, the difficulty of this lies somewhere
> between automated theorem proving and strong AI.  If you can't program
> the low-level computers from the high level, then you're reduced to a
> few canned properties, or you have to let the designer go in and "lay
> out the board" by hand all the time.

No, the sanity checks are just that, sanity checks.  If you want to 
design a house with 1500 square feet of living space on one level, but 
require the outside dimensions to be 30 by 40 feet, stop right there. 
But 35 by 45 could be possible depending on other layout requirements. 
So you have to do the computationally intensive process of trying 
various layouts to see if they meet all requirements.  Make the 
acceptable footprint 40 by 50, and you will probably get lots of designs 
that meet all your requirements, and it may be that one of them has a 35 
by 45 footprint.

> But I think that, rather than building a single unified design language,
> you'll have to build a modular framework, a "property-solving engine",
> and let people define their own properties during their design process. 
> Want to try to specify everything in advance?  All possible mechanical
> and programmatic behaviors?  No...

You misunderstand.  The purpose of a good design language or programming 
language is not to limit possibilities but to make it possible to 
describe just about anything in the problem domain.  In this case, the 
problem domain is three dimensional structures made out of atoms and the 
  electromagnetic forces they generate.  If you want to engineer 
something made out of quarks and held together by the color force, that 
is out of scope.  But that is about it.

> Actually, I've never participated in a code review.  I'm vaguely aware
> that they're a good idea.  At EFI when I was there (91-97), we generally
> had one person per function (e.g. serial comm, PostScript interpreter,
> UI, networking), and each person wrote code and then debugged it, and
> then we integrated it, and after very little more debugging, it worked. 
> This started to fray a bit when we put a full real-time operating system
> into our product, but we still developed working products much faster
> than anyone else in the industry.  We simply made sure to hire only
> excellent programmers.
> 
> Are you shocked?  Does this explain my liking for brute-force
> quick-and-dirty methods?

Ask yourself a different question.  Did programmers "own" code, or was 
there an informal code review process.  If you needed a value generated 
by Joe's code, what did you do?  Make it a requirement for that module? 
(best) Put in a comment that this variable is also used by module xyz? 
Or tell Joe what your needs were and expect him to take care of it?

Informal code reviews can be appropriate for a small group.  But that 
process breaks down if someone starts "hoarding" their code--not letting 
others look at it.

> But I don't think we're on track yet.  As I said, I don't know of anyone
> in the US who's putting resources toward MNT.  There are lots of
> enabling technologies being developed, but if no one is trying to
> integrate them, they might as well not exist (from the MNT point of
> view--they're very useful in their own right).  
> 
> I don't think, as some do, that all scientists should be responsible for
> all implications of their work.  But I do think it's important for at
> least some technically-aware people to be thinking about the politics
> and policy implications.  There's a massive political, economic, and
> social disruption coming, and I see only two choices: to face it
> uninformed and scared, or to have a few technically-minded people like
> me spend time educating people and policy-makers about what's coming.

Definitely.  As I said elsewhere, I have something to say on this, but 
it needs more work. However, the emergence of nanofabs as a possible 
intermediate step between today and Drexlerian assemblers makes me much 
more optimistic about the final outcome.  Even so, if we want things on 
the right track, we have to know what that track is.

> Nice to have my conclusions supported... But note that I actually listed
> three very different kinds of development.  Open Source is fundamentally
> different from Commercial.  See CRN's recent paper at
> http://CRNano.org/systems.htm .  (I'm realizing as I write this that no
> one has described a system of precepts/ethics for international
> administration.  This needs thought...)

> So even those focused on research need to worry about politics, if only
> to avoid it.
> 
> Yes, it won't be easy to design a system that's resistant to sabotage or
> being pulled off-track.  An awaremess of the appropriate precepts to
> follow for the purpose of the system may help a lot.  I don't know if
> it'll be enough.

 From experience, the problem is money.  If the wrong person sees a way 
to make himself (or herself) filthy rich by subverting the project, you 
have troubles.  (Making everyone on the project rich is NOT a problem. 
The problem is when one person decides that he or she doesn't want 
others getting a share.  Not a fair share, any share.)

-- 

                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.