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