Wednesday, August 6, 2008

COSA Is Not Dataflow

I wrote this about two years ago but it bears repeating.

Dataflow Languages Are Not New

I frequently receive emails from people who insist that COSA is nothing but a dataflow programming model and that I am just reinventing the wheel. Dataflow is not new. I have been attracted to visual dataflow languages (e.g., LabView, Prograph, etc...) for many years. I remember thinking that the graphical representation, the powerful reuse mechanism and the flow-through style combined beautifully to create a much more intuitive and easy way to develop computer applications. People have been using dataflow languages for over twenty five years. The problem is that, if the dataflow model was the panacea that would cure all that ails the software industry, it somehow failed to gain widespread acceptance. I mean, shouldn't we all be using dataflow for everything by now? The reason is obvious; something is missing. Dataflow languages tend to be rather high-level and are not as flexible as some of the more conventional languages. Adding a new, non-composite object into a dataflow language is not easy for the average user and usually requires the use of a compiled language such as C or Java.

COSA Is Not Dataflow

Let me come right out and say it: COSA is not a dataflow programming model. COSA is a signal-based, synchronous, reactive software model in the tradition of reactive languages like Esterel, Lustre, Signal, etc... There are certainly similarities between COSA components and dataflow objects in that COSA components can be made to pass queued messages (data) to one another in a unidirectional (input/output) and asynchronous manner but that's about it. COSA is much more flexible than this. Here are a few differences:
  • Above all, COSA is synchronous at its fundamental level (the operation or instruction level). As far as I know, this is not true of dataflow languages. Heck, I don't think it's true of other reactive languages either.
  • Whereas dataflow languages are algorithmic internally, COSA's elementary cells are entirely signal-based.
  • COSA solves the data and event dependency problem.
  • COSA uses fine-grained parallelism.
  • COSA is temporally deterministic, that is to say, the execution order (concurrent or sequential) of operations in a COSA program is guaranteed. As a result, COSA programs are extremely reliable.

In conclusion, let me say that COSA is more like VHDL or Verilog, neither of which fall into the category of dataflow languages. A COSA program is comparable to a logic circuit or pulsed neural network. So please, stop telling me that COSA is a dataflow language. It is not.

7 comments:

Josh said...

Forgive me if this is a stupid idea, but could something like COSA not be a good pair with a dataflow language? A tool for creating new elements? The development tools for a combined style system could be extremely powerful I believe.

I'd also like to say that while you do come off as a kook as well a genius, I really enjoy your posts and they challenge my world-view, as all good writing should. I hope you don't kill the site.

Louis Savain said...

Josh wrote,

Forgive me if this is a stupid idea, but could something like COSA not be a good pair with a dataflow language? A tool for creating new elements? The development tools for a combined style system could be extremely powerful I believe.

Maybe. I just think that the graphical dataflow languages that I've seen show too much info, which can be confusing. Things should be shown on a need to see basis only.

As an aside, I got ideas for parallel programming user interfaces that are out of this world. In one of them, the programmer wears a virtual reality outfit with special goggles and gloves, and walks through a 3-D holographic representation of the program, kinda like a plumber in a weird video game but with full tactile feedback. He/she can then observe events as they happen or reach out and fix things that need to be fixed or rip out stuff that are misbehaving or add new parts if necessary. Future stuff.

I'd also like to say that while you do come off as a kook as well a genius, I really enjoy your posts and they challenge my world-view, as all good writing should. I hope you don't kill the site.

LOL. Don't be too sure about the kooky stuff. That's where the biggest surprises will come.

msundman said...

> COSA is not a dataflow programming
> model. COSA is a signal-based,
> synchronous, reactive software
> model in the tradition of reactive
> languages like Esterel, Lustre,
> Signal, etc...

Umm.. Lustre and Signal are dataflow-languages. Besides, signal-flow is just a special case of data-flow (namely, where the data is restricted to booleans).

Louis Savain said...

Umm.. Lustre and Signal are dataflow-languages.

I think that it is a mistake to call a synchronous reactive language a dataflow language because it amounts to a redefinition of the word dataflow. Dataflow languages, as originally defined, are neither synchronous nor reactive.

Besides, signal-flow is just a special case of data-flow (namely, where the data is restricted to booleans).

Well, I have to disagree because signals in COSA are not Booleans. A Boolean is a state variable that has only two states, true or false. By contrast, a COSA signal is not a state but an event. As such, it represents a state transistion. It is a temporal marker that indicates that something just happened (changed). A COSA signal is associated with a specific time (based on a virtual clock) in such a way that a COSA program can reason about the timing (concurrent or sequential) of their actions.

In sum, a COSA signal does not have a variable representation because it is not a variable.

msundman said...

> > Lustre and Signal are dataflow-
> > languages.
>
> I think that it is a mistake to
> call a synchronous reactive
> language a dataflow language
> because it amounts to a
> redefinition of the word dataflow.

Well, the data flows in it. The creators of those languages call them data flow languages.
What's your definition of "dataflow language", and why do you think signal and lustre doesn't fit that definition?

> Dataflow languages, as originally
> defined, are neither synchronous
> nor reactive.

Dataflow implies neither synchronicity nor the lack of it. It also implies neither reactiveness nor the lack of it.
They are orthogonal concepts.

> > signal-flow is just a special case
> > of data-flow (namely, where the
> > data is restricted to booleans).
>
> Well, I have to disagree because
> signals in COSA are not Booleans.

Signals are what defines the values. The "synapses" are the "variables". At any one point in time a signal can be either present (true) or absent (false).

Louis Savain said...

Marcus,

If all that is needed for a dataflow language is to have data flowing in it, then every language is a dataflow language. I thought dataflow was about using high-level pluggable and reusable objects through which data flowed from input to output. The objects can be connected in various combinations to create different programs, kind of like a plumbing network. Of course, one of the advantages of dataflow is that the objects can work in parallel and take advantage of current multicore processors using coarse-grained, thread-based parallelism. Problem is, with threads there can be no deterministic timing.

Having said that, if the authors of Lustre and Signal are using the dataflow name for their their languages, then I will stop comparing them to COSA. I will limit my comparison to Verilog and VHDL because COSA is based on fine-grained parallelism. To my knowledge, nobody is seriously attaching the dataflow label to Verilog.

I still disagree that COSA signals are Boolean values. They are transient signals that are associated with timed events associated with changes. A COSA signal is comparable to a Boolean state transition in a logic circuit. There is a clear difference, in my opinion.

msundman said...

> I thought dataflow was about using
> high-level pluggable and reusable
> objects through which data flowed
> from input to output.

That sounds like signal and lustre to me. E.g., look at some signal tutorial and you'll see lots of things resembling electrical gates and circuits.

> I still disagree that COSA signals
> are Boolean values.

Well, call them what you want and compare them to what you want, but signals and boolean dataflows are still equivalent in every way. The only difference is the perspective from which you look at them.