Re: Cells compared to Flow-Based Programming

On Fri, 30 May 2008 17:48:59 -0400, Paul Tarvydas
<tarvydas@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

George Neuner wrote:

On Thu, 29 May 2008 11:26:53 -0400, Paul Tarvydas
<tarvydas@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Do you happen to know anything about hardware design? TTL, say. On a
circuit board populated with TTL chips, are the chips all synchronized or
are they asynchronous?

TTL is not asynchronous in the manner that software people generally
use the term.
<snip>

Maybe I don't follow what you mean.

Then let's try this.

In software, asynchronous does not mean "parallel" but rather means
"not sequential" and there is the notion of independence. It's based
on the ideas in Hoare's book, "Communicating Sequential Processes" - a
good read if you haven't already. An electronic version is at
http://www.usingcsp.com/cspbook.pdf.

My objection to your TTL reference was that, although it's true that
the components operate in parallel, the cascade logic itself is
sequential. Each basic block (NAND, NOR, etc.) represents a
sequential function. A connected web of blocks can only represent a
sequential function or an oscillating function (which is really just a
brawl of 2 or more sequential functions). Achieving non-sequential
logic as in the software model requires multiple webs with little or
no signal interaction between them.


My point was that from the perspective of a single component, the arrival of
inputs is not predictable - inputs can arrive at that component "at any
time" in "any" order. The inputs to a chip do not all arrive at the "same"
time like parameters to a subroutine do.

Ok. It was unclear to me that that is where you were going with the
argument.


Furthermore, as you point out, one can calculate the propagation time for a
signal through a circuit largely due to the fact that the components of the
circuit are independent (unlike software, where subroutines depend, deeply,
on other subroutines).

A chip can be characterized before it is used in a circuit. Circuits made
from pre-characterized chips are easier to design. Software built with
subroutines does not work this way due to the tangle of dependencies (maybe
it is theoretically possible, but I never see anyone doing that).

Software can be analyzed in a similar way (see Gries, Barendregt,
etc.). It's just that few developers know how to formally proof
software and even fewer bother to do it except when the results will
be published. It's also the case that some popular programming
languages have features that impede easy analysis.


Do hardware people achieve better success rates in
their designs than software people do in their designs?

Yes. But the reason is because they don't invent new logic ...

[If that's true, why was my National Semiconductor catalogue from the
late '70's so much thinner than one from the '80's?]

Because the complexity of "standard" parts has been increasing. That
does not refute my argument that hardware developers simply combine
standard parts - all that's happened is that what was previously board
level macro circuitry has been proven useful enough to be integrated
into a standard IC.

I think you'll agree that the vast majority of hardware designers are
content to pick parts out of catalogs rather than do materials
chemistry to build senary logic gates.

Software developers, OTOH, do invent ad-hoc symbolism and accompanying
predicate systems every time they write a program - usually
under-specified, almost always incomplete, rarely coverage tested and
limited to "expected" inputs.


they reuse standardized components having known behaviors. Even when the
components are interconnected in novel ways, the behavior of the
result is predictable.

Yes. My point is that this is a good model / goal for building software.

I agree.

The problem of standardized software components will be solved as soon
as everyone can agree on a common paradigm neutral, multi-language,
cross-platform, immutable, type safe, modular delivery system.

I don't see that happening in my lifetime (and I expect to live
another 30-40 years).


Do chip designers offer some kind of guarantee that their chips will work
as specified in the data sheets?

No. They offer "warranty" ... which is a very different concept from
"guarantee".

If I understand correctly, a warranty is time-limited, a guarantee is a
statement of fact ("it will operate thusly").

Historically "warrant" was limited to the lifetime of the giver.
However, companies have (potentially) unlimited lifetimes.

There is a legal difference between "warranty" and "guarantee". A
warrant is a statement of authority to take action in matters related
to whatever is warranted. A guarantee is a promise of responsibility
for an obligation.


What, then, is a data *** and what is the purpose of the "test circuit"
often supplied on a data ***? What is the purpose of a truth table
supplied in a data ***?

A data *** is just a piece of paper. The warranty that the data
*** is a good faith description of the operation of a part and that
the company will replace parts that do not conform to the description
is what gives meaning to the data ***.


Every hardware designer I knew used data sheets as statements of operation
(which I think is called a "guarantee"). They knew not to rely on
non-specified behaviour and they knew to complain bitterly if the specified
behaviour was not delivered.

If everyone jumped off a cliff would you do it too? Those designers
were relying on an incorrect understanding of the meaning of the
documents.


Do software designers offer equivalent guarantees?

No. But some select few do offer warranty.

A software attempt at datasheets is the set of Java library reference
manuals. In my experience they fall far short of the sort of utility that
hardware datasheets provide(d). I claim that this is because software
subroutines (classes, et al) are too wound together and too interdependent
to allow a clean characterization of operation and behaviour as is possible
for hardware. I think that using reactive software components and circuits
built using reactive software components is a step in the "right"
direction.

The best software "data sheets" I've seen were for Intel's Integrated
Performance Primitive libraries.

Component software is a great idea but intractably hard in practice.
Honestly I can't care much about the lacking in Java's documentation
because Java as it exists now is not a suitable candidate for a really
useful componentized software platform. Neither is .NET, or Corba, or
COM or anything I've yet seen.

George

--
for email reply remove "/" from address
.