Re: Followup: Software required for Nanotech Robert I. Eachus (eachus@spectre.mitre.org)
Search tool
15 May 1996 15:46:03 -0400

In article <4n6965$kv0@foglet.rutgers.edu> Dan Clemmensen <dgc@shirenet.com> writes:

> The "software development breakthrough" will be the result of
> advances in software development tools. Since these tools are themselves
> software or (in the case of new computers) the result of the use of
> software tools, It seems to me that we have the basis for an inevitable
> feedback loop as we apply software developent tools to the development of
> other tools. I believe that this feedback will result in the emergence of
> a "superintelligence" (SI), probably as a human-computer collaboration.

> This SI will emerge prior to the assembler breakthrough, because the
> software tools required for the assembler breakthrough are IMO sufficient
> for SI, while they are necessary but not sufficient for nanotech without
> SI.

I missed the original post, but I have been saying the same thing for years--and working on the software breakthrough for decades. Right now I would guess that the best software development enviroments are a factor of one thousand better than when I started programming. (If you want to challenge that, be warned that I have a GP manual in my attic. GP was AFAIK the first commercial assembler, for the Univac I. If it wasn't, well I also have a SOAP manual for the IBM 650 up there. But even though I used it first, I think it came later.)

In the last 15 years there has been a revolution in software brewing that will lead to another factor of 1000--but it is only starting to happen. OO techniques are at the heart of it, but to break free from the low-level requires reusable components, and this is just now possible. However, just as circut boards are built up out of standard chips, and mnt assemblers will be built out of subassemblies, we need the libraries of software components. That is where the next five years or so will focus. (And no, I am NOT talking about class libraries, this is a new and better design paradigm, but requires new libraries. Just like moving from discrete components to integrated circuts, or RTL to TTL.

For those software engineers following this, the problem with "vanilla" OO is that reuse is normally by refinement, not by assembly. What we need are libraries of components and ways to assemble them to make NEW object classes, then add further to refine the classes. Mixins seem to be the way to go, but you need a technology which allows mixins to "snap-together" to build something which is more than the sum of its parts.

Not to get into language wars, Ada 95 seems to have all the necessary support right, and I hope the final C++ standard will do the same. Eiffel may also be in the running and there are other languages that I am not sufficiently familiar with, such as Sather. Of course mixins are originally a LISP concept, but Scheme not Common LISP seems to be the current LISP flavor of choice for this sort of stuff. (The verdict is definitely still out on "true" multiple inheritance as in Smalltalk.) 

--

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...