anon.1 (abc.delete@this.def.com) on May 10, 2017 8:09 am wrote:
> j (B1FF.delete@this.B1T.NET) on May 9, 2017 2:58 am wrote:
> >
> > Are there any decent languages that actually lend
> > themselves to a dataflow sort of output? All that
> > comes to my mind is LabVIEW, which I'm not convinced
> > qualifies as decent. Are we stuck with compilers
> > trying to autoparallelize languages like C as
> > state-of-art?
> >
>
> Pretty much any pure functional language is a dataflow language. State is immutable (write once, read many times),
> functions always return the same value for the same inputs and have no side effects. The style lends itself
> to easily identifying independent units of work. I believe some functional languages like oCaml and/or Haskell
> support autoparallelization. Google made this famous with its mapReduce paradigm for distributed systems. Functional
> languages have been used to program academic experimental dataflow machines. Verilog/VHDL can also be viewed
> as dataflow (everything is parallel by default unless you state otherwise). Compilers convert intermediate representation
> code into static single assignment (SSA) format -- a write once read multiple times format -- which is then
> used to do dataflow analysis and it's for similar reasons. The trouble with pure functional programming has
> always been how you deal with exceptions and I/O in a manner that the end-user can debug easily (determinism).
> Having only limited experience in this, I can't comment on state of the art.

Thank you for the insightful reply. It hadn't dawned on
me that a functional language could be considered to be
driven by dataflow, despite actually haven written a
little bit of lisp *way* back in the day.

I guess that any sort of autoparallel execution will result
in indeterminate behavior, but then, so do hardware caches.
And most people seem to regard them as something they approve
of.

j