From: Samantha Atkins (email@example.com)
Date: Sat Aug 10 2002 - 03:25:16 MDT
Ben Goertzel wrote:
> Having read the web page, but NOT studied the code or tried to use the
> system, I think the approach is badly wrong-headed...
> The argument that massively parallel brainlike systems are more "reliable"
> than algorithmic systems is a play on the multiple senses of the word
> Simple, toy systems of this nature may display nice failure-recovery
> properties. But really complex massively parallel agent systems can be
> terribly hard to debug, as I know from long experience. And the kind of
> reliability that brains have is not the kind we want from software systems,
> in a mission-critical context. Actually, brains have bad unreliability
> problems: they go nuts, they die, they delude themselves, they react
> terribly to minor modifications in their chemical substrate, etc.
> Also, he claims that algorithmic programming can be replaced by simple
> visual programming using his interface. Yeah, right. It's OK for
> UI-focused or physical-simulation-focused stuff I guess, but not for serious
> AI coding for instance...
> I think that the solution to the software reliability problem is clear,
> well-known, and less sexy than COSA.
> 1) Formalize the requirements for the program using mathematics
> 2) Formalize the software design using a specification language like Z
> 3) Prove that the specification fulfills the requirements, mathematically
> 4) Translate the software design into a mathematically simple language like
> Haskell or Scheme or ML
> 5) Prove that the software design correctly implements the formal design
> These proofs can be carried out by humans together with automated
> theorem-proving tools
> All this is known technology. It is not used much in practice, because it
> takes more time (hence more money) than doing software development the
> standard way.
> We have not taken this approach for Novamente, because we don't consider it
> worth the time; we don't need a provably correct system right now. However,
> I would like to take this approach for Novamente 2, if there is one (if
> Novamente 1 doesn't end up writing Novamente 2 ;).
> You'll find this sort of method is used for mission-critical military
> software more often than anywhere else, which is sensible.
> As AI advances, it'll be possible to efficiently do this kind of
> theorem-proving for regular software projects, hence software reliability
> should increase due to AI's contributions, even before AI's render human
> software engineering obsolete...
> -- Ben Goertzel
>>From: firstname.lastname@example.org [mailto:email@example.com]On Behalf
>>Of David Hart
>>Sent: Friday, August 09, 2002 9:00 PM
>>Subject: project COSA
>>"COSA is a reactive, signal-based software construction and execution
>>environment. The goal of Project COSA is to improve software reliability
>>and productivity by at least one order of magnitude ... Software
>>creation consists of connecting elementary concurrent objects (cells)
>>together ... Cells can be combined into high-level, plug-compatible
>>components and/or applications..."
>>Self-examination, introspection and self-modification are design
>>considerations of COSA.
>>What are SL4 list members' opinions on the approach and technical merits
>>of COSA? ("Silver Bullet" and other emotive arguments aside)
>>CTO, Atlantis Blue
THis site is not remotely written in language that I consider
that of any group or approach that can give any real benefit to
the "software problem" much less the "at least one order of
magnitude" improvement claimed in the second sentence of the
abstract. This is a very wild assertion and the rest of the
site does not support it. There is a lot of verbiage re-hasing
the problem, telling us that everyone but this group has been
blind and or have plotted to obscure the truth - typical crank
talk. The truth sold here is partially useful for some types of
problems but is seldom useful by itself except on relatively
small subsystems. Visual Programming has been tried in many
systems and again is usually found unworkable except for fairly
small problems. Much of the rest of the piece I noted in
skimming simply borrows liberally from existing software
techniques (although not that many) with a twist of terminology
here and there.
In short, COSA is a hopeless hash probably worth even less time
than to write or read this.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:40 MDT