[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
buggy.
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
i386-machine.
> * 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.)
mfgard
IOhannes
More information about the Pd-list
mailing list