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.