[PD] very much a work in progress..

[Mathieu Bouchard]

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