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

IOhannes m zmoelnig zmoelnig at iem.at
Fri Jan 11 09:57:03 CET 2008

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?

> * No strings.

you mean, like C?

> * 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 
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.

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

> * 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.

and that true programming languages exclusively run on mainframes.

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

which modifications?

how is this with other programming languages?

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

compared to C, i consider Pd-patches _quite_ portable...
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 

> * Lacking some other useful programming constructs.

which ones?
"useful" is usually rather context specific.

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.)


More information about the Pd-list mailing list