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
On Feb 17, 2005, at 11:00 PM, Mathieu Bouchard wrote:
suppose you wanted to reply to the list but it was a mistake. (If that's not the case, just tell me)
No no, you did well.
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).
Yes yes, this I know. I have no interest in that sort of thing though. Doesn't sound fun at all!
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.
I have played with Erlang a bit, but it doesn't take flow-based programming to the level I'd like.
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.
Java is crap. Kill it!
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.
I've played with Ruby a bit. While its nice, I just don't find it any fun. It's a rather boring language I think. You can't get as creative with it as you can with Scheme or Lisp. I love the Io language btw for its conceptual purity and small footprint. Good stuff.
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_.
Lisp is great. I'm a Schemer myself though. Since most of my serious stuff is done in C or Javascript (for inlining it in Max), I figured that Scheme is a more fun toy language than Lisp. Continuations, all that fun stuff. I could be wrong though.
PureData itself is somewhat of an hybrid between a dataflow language and an imperative OOP language.
Yes. This is why I like it. I like imperative programming. It makes sense.
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.
People write externals more often than they need to. Most often the people that can write externals knew C before they started with Pd, and hence they're more used to solving problems that way. Things they might hesitate to do in Pd might be quite possible and not too messy, but they're just not used to doing things that way. Still, it is somewhat rigid, although not as much as you might think. I think.
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.
I don't know what it is, but I just love Pd/Max. I never even have to think when I'm working with it. I just think in that sort of data-centric way I guess. I like table-driven programming too. But to me, objects without a flow-centric concept (i.e. just about everything out there, Python, Ruby, Java, C++, whatever) make no conceptual sense whatsoever. Who is this god that takes data from one object and gives it to another? Just a bunch of objects floating in space with some magic hand... Forgive me... I had too much caffeine. Java suck. Espresso good.
- John
On Thu, 17 Feb 2005, John Nowak wrote:
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
Yes yes, this I know. I have no interest in that sort of thing though. Doesn't sound fun at all!
Well, the point is not to make it easy for the user to program, but to make it easy for the user to say exactly what the data flow is, including whether data is still needed or not. E.g., if you use [@ +] in GridFlow and store a large picture in the right inlet, then that picture is stuck there until it gets a replacement value, and never gets deallocated before that time. It is basically the same in the rest of PureData, but a float doesn't take much room, so it's not as convincing as a four meg piece of data.
The problem I see is that PureData makes it easy first by providing imperative-style dataflow constructs first, and then not doing anything else; while the mostly-stateless dataflow languages provide dataflow constructs that are free of many assumptions (that messages are handled in a certain order and never at the exact same time, no threads, etc). What we need is something that possibly starts with PureData but allows one to configure inlets and outlets so that they behave in a more customisable way.
I think GridFlow could eventually include such features. For example, you will be able to specify "use only once" that will reset an inlet value to default just after any use of it, and you will be able to specify which inlet(s) is/are hot. Unfortunately it's still annoying to use a lot of options in the same objectboxes because PureData still doesn't allow control on object width, whereas Max does and jMax did too.
I've played with Ruby a bit. While its nice, I just don't find it any fun. It's a rather boring language I think.
You know, a lot of fans of Ruby say that Ruby puts the fun back into programming...
You can't get as creative with it as you can with Scheme or Lisp.
... possibly that the above people are not Scheme/Lisp fans and come from a background of much more boring languages =) I have asked for more lispish features in Ruby in my first post to the Ruby list in 2000. Later I started working on a modular compiler architecture for Ruby but I abandoned by 2002. Nowadays there are several projects (by various people) to bring Ruby into such interesting areas but it's still very much experimental.
Lisp is great. I'm a Schemer myself though.
Scheme takes a very minimalist approach. This is good because it makes it easy to reimplement, and it's bad because many things are not built-in. CommonLisp appears to be rather modular though: the base language is not too big, it's mostly that the standard library is defined in the main spec, and contains a very large variety of different things.
Since most of my serious stuff is done in C or Javascript (for inlining it in Max), I figured that Scheme is a more fun toy language than Lisp. Continuations, all that fun stuff. I could be wrong though.
is it that Max has Scheme bindings and not CommonLisp bindings? I really don't know myself, but I know that this is the case in PureData.
hesitate to do in Pd might be quite possible and not too messy, but they're just not used to doing things that way. Still, it is somewhat rigid, although not as much as you might think. I think.
Well, maybe it's easier if one starts by downloading a large amount of externals and start from there, but there are still quite bad things in Pd, like not being able to handle the argument list of an abstraction as an actual list, and not even get the number of arguments, things that externals can do really easily.
As I said at the Pd convention, I believe more things should be made abstractions instead of externals (and that's half the point of the existence of my GridFlow external too). However this doesn't mean PureData is currently ready to handle that much, and there are still quite a few things that are not possible at all as abstractions, or require quite large _detours_ to get there.
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,
Apparently I am repeating myself a bit, from mail to mail...
I don't know what it is, but I just love Pd/Max. I never even have to think when I'm working with it.
Really? Are you trying to solve hard enough problems? It depends if you're in the mode of just trying to come up with whatever Pd leads you to do as you use it, or if you're in the mode of starting with a goal and then somehow try to achieve it using PureData. I've found the former is a lot easier with PureData, whereas other programming languages tend to make the latter easier.
I like table-driven programming too.
How do you define table-driven programming? (maybe it's something really simple, but the phrase isn't too common...)
But to me, objects without a flow-centric concept (i.e. just about everything out there, Python, Ruby, Java, C++, whatever) make no conceptual sense whatsoever. Who is this god that takes data from one object and gives it to another?
Apparently they call it "pointers"...
PureData has them, but they were experimental back in 1997, and apparently they never quite got out of that state. I mean, some people are doing cool things with them, but they never got to the level of prominence they were supposed to originally have. There's still something to do about them, it's just that there's more work to do.
Just a bunch of objects floating in space with some magic hand...
Think of an outlet as a pointer settable directly by the user, where the thing that the inlet points to is an inlet. Objects with inlets have multiple entry-points, which can be emulated in other languages by using auxiliary objects whenever it's necessary. In fact, PureData implements multiple inlets exactly in this way (well, I think so; it's explicitly like that in at least some important cases).
Btw, sorry for sounding strange on the chat, I really thought I had finished this mail and sent it already :-/
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
-
John Nowak -
Mathieu Bouchard