On Thu, 17 Feb 2005, John Nowak wrote:
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