[PD] very much a work in progress..

John Nowak john at johnnowak.com
Fri Feb 18 05:18:04 CET 2005


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





More information about the Pd-list mailing list