Re: WSJ article on software liability

From: Bryan Hoover (bhoover_at_wecs.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 05:15:51 -0500

Traveler wrote:
>
> In article <42215909.96B767E4@wecs.com>, Bryan Hoover
> <bhoover@wecs.com> wrote:
>
> >Traveler wrote:
> >>
> >> In article <421FF9CA.A0C3ADC1@wecs.com>, Bryan Hoover
> >> <bhoover@wecs.com> wrote:
> >>
> >> >Traveler wrote:
> >> >>
> >> >> In article <9dru11tai75juq68cm27nqekocn8144n1p@4ax.com>, Programmer
> >> >> Dude <Chris@Sonnack.com> wrote:
> >> >>
> >> >> >Traveler writes:
> >> >> >
> [cut]
> >> > -- rather, I fancy something
> >> >more along the lines of "It's alive! It's alive!!"
> >>
> >> You mean you want something tangible? Well, somebody has to build it
> >> first. What I am proposing is a revolution, a radical approach to
> >> software construction that will require new CPUs optimized for a
> >> radically new software model. This kind of stuff does not happen
> >> overnight.
> >
> >No, I meant in the sense of being dynamic.
>
> Well, COSA is 100% dynamic since it is a signal-based (change-based)
> model. In fact, a COSA program is always "running" even during
> development. All connections are made dynamically. There are no
> compile/run cycles.
>
> >Your thesis sounds a lot like an extension of OOP. Your description of
> >system objects being connected -- have you ever looked at the code
> >associated with Delphi (the Borland programming language)? -- some of
> >the components are replete with associations (signaling lines you might
> >say) with other components.
>
> Delphi is an OOP language in the old tradition of OOP. So-called
> associations are really function calls from one object to another.
> There are no function calls in COSA. Indeed, none of the traditional
> algorithmic constructs like if/then, while, gosub, goto, etc..., are
> used.
>
> >Ian questioned whether implementation required hardware. I agree.
> >Multiprocessing programming does not required multiple processors -- the
> >principles are the same either way, and such a program will run
> >essentialy the same regardless of single or more processors. Why
> >couldn't what you propose work similarly -- for instance, "hardware"
> >objects could be represented in object encapsulations, and seamlessly
> >adapt according to the hardware envirnment.
>
> I agree. COSA can indeed work on a single processor but it would be
> too slow. Current CPUs are optimized for the algorithm. In other
> words, they have an execution pointer to code memory that is
> incremented after each instruction is executed. Instructions are
> fetched in sequence. In COSA, instructions do not follow each other in
> memory. A COSA system is more like a neural network in its operation.
> Cells are activated only when there is a need, i.e., when they receive
> a signal. This requires the use of two processing lists, one for
> inputs and another for outputs. A COSA-optimized processor would not
> only maintain the lists in the chip's cache but would execute the
> objects directly, obviating the need for a microkernel. This is
> explained in better details in the COSA Operating System page.

It might be helpfull if you could clarify (for me at least) a bit more
about how your system compares with the idea of a thread of execution.
For instance, according to my understanding, a simple combustion engine
-- a motor -- has a single driver -- think, cam shaft -- and everything
else in the system is driven on that -- the other elements don't have
their own threads of execution, or drivers -- they are connected via
gears essentially, to the single source drive, the cam shaft -- if it
doesn't turn, everything else -- the water pump, pistons, fan, lifters,
drive shaft, wheels -- stops moving as well. Likewise, the main loop of
a traditional single threaded computer program. With a multithreaded
application, it's like having multiple engines with the main program
controlling, keeping them in sync so to speak.

My cride understanding of a computer hardware system is that, similar to
a combustion engine, there is essentially a single driver -- system
clock (I think one would call it) on which everything else is driven --
perhaps there's more than one clock, in which case I imagine, there is
some system element providing for syncrhonization.

Could you give a sort of compare and constrast of your system in terms
of what's describe above? I think it would go a long way in helping to
understand what you are proposing.

Bryan

> Louis Savain
>
> The Silver Bullet: Why Software Is Bad and What We Can Do to Fix it
> http://users.adelphia.net/~lilavois/Cosas/Reliability.htm

Relevant Pages

  • Re: Performance problem on initial call of stored procedure
    ... the driver made PHENOMENAL jumps in performance for SUBSEQUENT ... It is referenced that qsqsrvr in qsyswrk handles the jdbc connections, ... the problem queries from the sql session in navigator, ... does not seem to significantly affect the execution time. ...
    (comp.sys.ibm.as400.misc)
  • Re: WSJ article on software liability
    ... Were my question beneath you Traveler? ... Bryan Hoover wrote: ... COSA can indeed work on a single processor but it would be ... > about how your system compares with the idea of a thread of execution. ...
    (comp.programming)
  • Re: thread handler
    ... About the thread handlers: ... function in the same process in execution after execution. ... connections can be served simultaneously. ... If I set the stack size to 0 than I can creat about ...
    (microsoft.public.vc.mfc)
  • Re: State Threads
    ... WN> application to handle 100K socket connections? ... In case you only want to have a web server, ... thread restores the execution context, in a TP system it would be the ... problems with blocking on disk IO, because if a thread needs to block, ...
    (comp.lang.ada)
  • Re: WSJ article on software liability
    ... COSA is 100% dynamic since it is a signal-based ... >the components are replete with associations (signaling lines you might ... they have an execution pointer to code memory that is ... Instructions are ...
    (comp.programming)