[PD] poor performance when saving an abstraction when many copies are loaded in a patch

[Chris McCormick]

On Fri, Jan 11, 2008 at 09:57:03AM +0100, IOhannes m zmoelnig wrote:
> Chris McCormick wrote:
> >Here are some other reasons why you might not want to use Pd to develop
> >a large scale application (and why I won't call Pd a 'programming
> >language'):
> >
> >* No hash/map/table type, or array type that holds anything except floats.
> 
> data structures?

Pd datastructures are a pretty poor compromise when one is used to the
types of data structures that regular programming languages supply, and
the ease with which you can use those data structures. In javascript,
Python or C I can just say something like:
t = ["hello", "goodbye", "pants land", ["a", "b", 'c']];

Doing a similar thing in Pd is a pain.

> >* No strings.
> 
> you mean, like C?

In C I can dynamically allocate an array of chars terminated by a \0
*with spaces* as easily as:

char *mystring = "pants pants pants.";

There is nothing even close to this in Pd. Yes, I know about symbols
and [makefilename], but my point is that it's not the kind of thing I'd
want to worry about when working on a large, complex application; it's
more like a nightmare. For art installations though, I will happily
compromise because Pd offers me so many great ways of producing sound
and vision and integrating with hardware.

> >* No introspection.
> >* Dynamic patching is unsupported, hacky, and occasionally buggy.
> 
> hmm, it is both unsupported and hacky. i don't know why you thin it is 
> buggy.

Because I have experienced crashes that I can't easily explain, only
when doing dynamic patching. Maybe if I looked closer that wouldn't be
the culprit, but that's the way it seems to me now. There was a post
just recently about someone experiencing a crash because of this.

> apart from that: how does this qualify to prevent Pd from being a 
> "programming language" and how does it prevent Pd from allowing to 
> develop large scale applications.

You're right, introspection isn't neccesary for Pd to qualify as a
programming language. It doesn't prevent Pd from being used to develop
large scale applications, it just makes it much harder (These days I
wouldn't program a large scale application in C either, I'd do it in a
high level language and then re-write my tight-loops in C).

> do you consider statically typed languages as real "programming 
> languages" and why so?

Of course.

> >* Audio processing is hard coded into it instead of being supported by the
> >core language as a library like in 99% of other programming languages.
> 
> now that is a real bummer argument against bein a real programming 
> language and bein unable to be used for large scale applications.
> 
> please do not forget that most programming languages are text-based 
> instead of graphical schnickschnack.

Most programming languages aren't highly optimised for the singular task
of doing DSP processing though. This doesn't prevent Pd from being used
to develop applications, it just makes it slower and/or more awkward in
some cases where a general purpose programming language would do better.
The whole DSP bit is bloat if you're not using it for the task at hand.
On the other hand, in the case of DSP, it doesn't get much better than
Pd.

> and that true programming languages exclusively run on mainframes.

Say what?

> >* It's not easily portable to embedded systems without many modifications.
> 
> which modifications?

The PDa source code is different enough from the mainline Pd source code
that it makes it quite hard to integrate mainline Pd releases back into
PDa.

> how is this with other programming languages?

That depends on the implementation and target platform really. I found
Python particularly difficult to port to the Nintendo DS, but I found
other programs were as easy as using the --host= flag with the configure
script. However, Lua, the Java VM, and Scheme have been ported to heaps
of platforms so it should in general be something that doesn't require
a fork of the codebase like PDa.

This isn't something that would stop most people from using Pd as a
programming language, just those of us targetting embedded systems and
systems with no OS.

> are you talking about programs written in Pd or the engine that runs 
> these programs?

The engine.

> compared to C, i consider Pd-patches _quite_ portable...

Yep, although regular Pd patches won't just run without any changes in
PDa always since some objects don't work in PDa. Also, numbers behave
differently, which is pretty annoying.

> and then, i have never tried to port a java-vm to an embedded system. 
> don't know how many modifications this takes compared to the plain 
> i386-machine.

The Java-VM has been ported to heaps and heaps of systems, so there
is probably an implementation out there for whichever system you want
(there have even been CPUs developed that directly speak the bytecode)
I wouldn't use Java for much though because most of what it's good at can
be done by other languages that are less syntax heavy, type restrictive,
and more introspective.

> >* Lacking some other useful programming constructs.
> 
> which ones?
> "useful" is usually rather context specific.

Yes, you are quite right. How about inheritance and polymorphism for
starters? Can anyone help me out with the other programming constructs
that Pd lacks? I know there are more.

> having said all this, there are tasks where i would not chose Pd (but 
> often i keep wondering why i did NOT chose Pd; most of the time it turns 
> out to be because of the end-users expect a GUI-interface which they are 
> used to and which is hard to do in Pd, with no toolkit; even the most 
> "sophisticated" GUIs build in Pd do not look like "ordinary" applications.)

I'd love to see a Pd-like dataflow language that I could use for every
day development. A dataflow language with a bit more object orientation
than what Pd has would map really well to a lot of game development
problems, I think. I also think that the dataflow way of programming
is more intuitive and more anthropomorphic which makes it easier to
program and to teach others to program. On top of this, systems are
becoming more and more parallel, which dataflow maps to very nicely
(although Pd doesn't).

Best,

Chris.

-------------------
http://mccormick.cx