[PD] very much a work in progress..

[Mathieu Bouchard]

On Thu, 17 Feb 2005, John Nowak wrote:
> >> http://johnnowak.com/n-syntax.html
> Essentially, it is. :-) I posted just for fun.

I suppose you wanted to reply to the list but it was a mistake. (If that's
not the case, just tell me)

> Well, there really *aren't* any textual dataflow languages as it
> stands. I've searched quite a bit and I've never seen any of them. (If
> you know of any, PLEASE inform me!) I think that alone is a reason to
> go for it.

AFAIK, the theory-oriented experiments in dataflow languages tend to work
in a way quite different from PureData. For example, there are no active
inlets, and no long-term state, so you have to send exactly one value to
each inlet before something happens, and if you send more than one value
to the same inlet it's a collision (not allowed). There are a few possible
variations on the theme. Anyway: I recall that Raphael A Finkel's
"Advanced Programming Language Design" (or a title like that) mentioned
dataflow languages called POST and SISAL, and I recall they were textual.
(disclaimer: I read that book in 1997).

Apart from that, there is a language design called CSP = Concurrent
Sequential Processes, which is about doing parallel imperative programming
using message pipes (and not with shared memory, so mutexes are not
required here). These are the most dataflow of otherwise "ordinary"
languages. They don't usually have inlets and outlets but have similar
concepts: mailboxes, and pointers to them, respectively. I think I recall
Erlang is the most prominent example of that kind of thing.

(Don't confuse it with CPS = Continuation Passing Style).

IMHO, what I prefer is not the languages that fit purely in a paradigm,
but those that are impure. Although this may seem clear, this requires
explanation: Java is a quite impure OOP system, but is so for sloppy
reasons in a way that makes it rigid, as the non-OOP part is weakly done,
not integrated, and despite those problems, completely unavoidable, so you
have those problems in your face all along. Ruby may be more thoroughly
OOP than most others, but it is also more thoroughly something else (a
more "functional" style) than most others, and those concepts are quite
integrated together. CommonLISP is firstmost an hybrid of imperative
"structured programming" and functional programming, but it includes
well-integrated extensions to the base language, that implement: OOP,
logic(backtracking), and _dataflow_.

PureData itself is somewhat of an hybrid between a dataflow language and
an imperative OOP language. I wouldn't know exactly where it stands in
terms of flexibility, but I have the impression it is quite rigid, given
how often complicated patches are required to do simple things, and how
often people need externals, and how often people need to _write_
externals. If we all love PureData so much, then why doesn't it get a good
nudge in the proper direction? Because writing abstractions _ought_ to be
better than writing externals, but unfortunately it's not the case often
enough, due to the difficulty in getting things right, or getting them to
work at all.

_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju