Otherwise, think about converting some of the abstractions to subpatches
Please don't interprete what I'm gonna say as sarchastic or offensive to whom wrote the above sentence (which however has been suggested by more than one person). Just take it as a general and (hopefully) constructive discussion about PD issues...
Would you ever say to someone writing an application in C++:
"Think about converting some of your functions to macros"???
That is just not an option. And converting abstractions to subpatches is much more limiting than that.
Inefficiencies in handling a great number of instances of abstractions are a great obstacle to applying "good" programming practices to PD patches. Using and reusing a great number of abstractions with many many levels of nesting is the only reasonable way (I can think of) of developing a large, complex, scalable, reusable "application" in PD.
This reminds me about a discussion I lounched in the list some months ago about whether PD can be considered an environment for "production" development, or just a tool for "prototyping". I do use it in production, that is I use it to develop "applications" that have to be used on stage, and I don't rewrite them in any other language: I just develop them in PD and run them in PD. And that causes me a lot of frustration because I often find out that PD starts to be somewhat unstable and unreliable when things get "big". At least (or especially) when GUI is involved. Note that I do take all the care to make sure that cpu or memory usage does not increase more than it should when making things "bigger" (e.g. always switch~ing off any audio processing stuff that is not really being "used", etc.)
I would love to provide examples or specific information useful for debugging, but when I get that kind of problems, I've never been able to isolate them. In one case I had a big, complex, structured patch with a lot of stuff inside. Just adding one more instance of an abstraction there were tens of instances of (and the whole patch worked great up to that moment), made it crash on open.
Now a practical question: it has been mentioned that PD manages the patch structure with linked lists which make it inefficient in renewing it when saving an abstraction that is used many times. Does this linked-list implementation cause other efficiency issues that may affect the working of things during the normal flowing of data (i.e. running the patch) or is it "only" an issue when saving?
Hi Matteo,
matteo sisti sette wrote:
Otherwise, think about converting some of the abstractions to subpatches
Please don't interprete what I'm gonna say as sarchastic or offensive to whom wrote the above sentence (which however has been suggested by more than one person). Just take it as a general and (hopefully) constructive discussion about PD issues...
No offense taken. But since I have neither skills nor time to get involved in PD development, I have to stay focused on certain things. For me, these are using PD for live performance, and trying to explain to new PD users how to get things done. If other people have time, energy and skills to tinker under the hood, that's fine for me too. But the response "if you don't like it, fix it yourself!" really doesn't work in all situations. Not for newbies who come to PD as their first and only programming language (as I did years ago), and not for me with no time to take on any more projects nor C/C++ know-how to make a significant contribution. So I focus on work-around strategies for all of PD's innumerable inconsistencies and idiosyncrasies. Whether that's proper, or "good programming" in the general sense I don't know, since I rarely if ever compare PD to any other language. But it's "good programming" in the PD sense, which is the only one that matters to me right now.
best! d.
Please don't interprete what I'm gonna say as sarchastic or offensive to whom wrote the above sentence (which however has been suggested by more than one person). Just take it as a general and (hopefully) constructive discussion about PD issues...
No offense taken. But since I have neither skills nor time to get involved in PD development, I have to stay focused on certain things.
Yes of course. I didn't mean to criticize your suggestion: I meant to "criticize PD" that makes that suggestion necessary.
Of course that IS a valid workaround in a lot of situations where the use of abstractions is not very extensive; it is just not feasible when you're developing some complex large scale application that you need also to mantain or further develop in the future.
I do very much appreciate workarounds, and often need them too. I just think that the existence of a workaround is not an "excuse" to underestimate the importance of an issue - especially when the workaround only applies to a restricted range of cases.
Bye m.
On Thu, Jan 10, 2008 at 02:42:12PM +0100, matteo sisti sette wrote:
Yes of course. I didn't mean to criticize your suggestion: I meant to "criticize PD" that makes that suggestion necessary.
Of course that IS a valid workaround in a lot of situations where the use of abstractions is not very extensive; it is just not feasible when you're developing some complex large scale application that you need also to mantain or further develop in the future.
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.
- No strings.
- No introspection.
- Dynamic patching is unsupported, hacky, and occasionally buggy.
- 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.
- It's not easily portable to embedded systems without many modifications.
- Inconsistencies in the syntax as discussed many times on this list
before.
- Lacking some other useful programming constructs.
It's great to use Pd for what it totally rocks at: making interesting graphics and music, but I wouldn't encourage it to be used as a general purpose programming language, because it simply isn't good enough at that job.
There have been [code] patches submitted in the past to rectify some of the above points, but Miller doesn't seem to be interested in turning Pd into a general purpose programming language, which is probably a good idea since it's so good at what it does already, and doing that might ruin it completely.
Long live Pd, the greatest and most fun audio visual mangling tool I know of!
Best,
Chris.
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
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.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
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.
I think, from the beginning Pd was meant to be extended by classes written in other languages where adaequate. Pd has support for more languages like this than any other similar progam I know. C is the natural choice here, but if Pd would include Lua support natively, it would invalidate almost every single argument against Pd that you mentioned: scriptability would be there (even for audio with Vessel for Lua), a hash/map-type is natural to Lua with its table data structure, string processing would be easier etc.
In the end, it then would boil down to the differences between graphical progamming and text based programming. Some things are hard to do in graphical languages regardless of their features.
Ciao
Frank Barknecht _ ______footils.org__
hi again.
Chris McCormick wrote:
- 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.";
as you have shown, there is no string type in C. you (ab)use arrays of bytes (chars) as "strings". miller has often argued, that strings in Pd are as simple as arrays of floats. (true, a float is not an ideal representation of a glyph; but neither is a char)
i do not say, that i would handle strings in such a way.
- 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.
correct. but they might be optimized for other tasks. like list handling, or formulas or business (well, the latter is _rather_ a joke).
each and every language is good in something and bad in something else. being good in something no-one else is good in, should imho be regarded as a feature rather than a bug.
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?
this was a joke, because it seemed to me, that your arguments became arbitrary.
- 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.
this is a problem of the implementation not of the "language".
it is also a social problem as to how to get which changes into pd-vanilla. (e.g. i still think that it would be (or rather have been) possible to get the PDa changes into pd proper; it was not done though)
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.
otoh, there are few powerful DSP/music-centric languages available on embedded systems apart from Pd. choose one of SC3, max/msp, OSW, chuck and try to run it.
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.
please file a bug-report for PDa :-)
Also, numbers behave differently, which is pretty annoying.
true.
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)
that's not the point. just because somebody already did the work, it doesn't mean that it has not been a pain to do.
Yes, you are quite right. How about inheritance and polymorphism for
correct. but Pd is not an OOP-language (despite using "objects") even though OOP-languages are still quite modern, there _are_ other useful languages that are not OOP.
and i would be interested to hear ideas on how to get OOP into a patcher-like languages.
mfg.a IOhannes
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
and i would be interested to hear ideas on how to get OOP into a patcher-like languages.
Are you? then search the archives.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
and i would be interested to hear ideas on how to get OOP into a patcher-like languages.
Are you? then search the archives.
the only thing i can find is you demanding parent and child objectclasses sharing the same $0.
i don't understand how this relates to inheritance of classes (rather than instances)
gfmadsr. IOhannes
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
the only thing i can find is you demanding parent and child objectclasses sharing the same $0.
no, i asked that objects share the same $0. objectclasses themselves don't have a $0.
i don't understand how this relates to inheritance of classes (rather than instances)
I've never spoken about inheritance among instances themselves.
The idea is that you want to include the behaviour of a superclass into a class, because that's what the concept of superclass is about. Because the behaviour of an abstraction is in the patch of that abstraction, you need to load both the patch for the superclass and the patch for the subclass and connect them together. Inheritance requires that both those loaded parts are considered as one instance. If you give them separate $0 values, then it's not inheritance: the usual name for that is then «composition», and it's the normal way of doing pretty much everything in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote:
the only thing i can find is you demanding parent and child
objectclasses sharing the same $0.no, i asked that objects share the same $0. objectclasses themselves don't have a $0.
indeed, my mistake.
i don't understand how this relates to inheritance of classes
(rather than instances)I've never spoken about inheritance among instances themselves.
but $0 is a concept for instances and not for classes.
i agree to the rest.
fgmasdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
On Fri, Jan 11, 2008 at 12:28:16PM +0100, IOhannes m zmoelnig wrote:
Chris McCormick wrote:
- 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.";
as you have shown, there is no string type in C. you (ab)use arrays of bytes (chars) as "strings".
Sure, of course, but everyone does this all the time. Are you saying that every type composed of ints/chars/other subtypes is an 'abuse'?
How is it any different to 'abusing' ints to make a vector?
int *myvec = {4, 3};
miller has often argued, that strings in Pd are as simple as arrays of floats. (true, a float is not an ideal representation of a glyph; but neither is a char)
It's all very well saying that it's possible, but it's very impractical, and it makes Pd much less easy to use for string processing than almost all other popular languages. For example, which GUI element can I use to get string input (with spaces) from the user into an array of char-floats? That's my only point - that Pd is not that great as a general purpose programming language, for this and other reasons listed.
each and every language is good in something and bad in something else. being good in something no-one else is good in, should imho be regarded as a feature rather than a bug.
Yes, completely true, and exactly my point.
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.
this is a problem of the implementation not of the "language".
True. It would be great if the implementation was a bit better on this front. I know that it's much better to submit code than to complain (sorry!), but I also think it's important to vocalise the weaknesses of any piece of software so that others will be informed about what it's good and bad at, and not have false expectations.
Yep, although regular Pd patches won't just run without any changes in PDa always since some objects don't work in PDa.
please file a bug-report for PDa :-)
Yes, good call.
that's not the point. just because somebody already did the work, it doesn't mean that it has not been a pain to do.
Yep, point taken. (Generally however, the more times something is ported, the easier it becomes to do it next time assuming the changes required to do so are incorporated).
I hope discussing the weaknesses of Pd can be seen as a positive thing that will help people and the language itself. It's a really amazing piece of software; I think we all know that. I am not sure how I ever did work without it.
Best,
Chris.
Hallo, matteo sisti sette hat gesagt: // matteo sisti sette wrote:
Using and reusing a great number of abstractions with many many levels of nesting is the only reasonable way (I can think of) of developing a large, complex, scalable, reusable "application" in PD.
I do agree with that, but I also would say, that with carfully designed and implemented abstractions it shouldn't be necessary to change them in a situation when hundreds of them are in use. Instead in a perfect world, an abstraction is built and tested thoroughly beforehand, with a *-help.pd file, and then it stays how it is when building larger applications. (A kind of bottom-up approach.)
Of course the world isn't perfect.
Another possible remedy: Especially with dsp-abstractions it can help to disable audio before saving a multi-use abstraction.
Ciao
Frank Barknecht _ ______footils.org__
I usually open the abstraction with 'help' rather than 'open', pd crashes less often when saving.
Quoting matteo sisti sette matteosistisette@gmail.com:
Otherwise, think about converting some of the abstractions to subpatches
Please don't interprete what I'm gonna say as sarchastic or offensive to whom wrote the above sentence (which however has been suggested by more than one person). Just take it as a general and (hopefully) constructive discussion about PD issues...
Would you ever say to someone writing an application in C++:
"Think about converting some of your functions to macros"???
That is just not an option.
hmm, since when are macros bad?
especially in C (not so much in C++) i could imagine situations where
i would tell somebody to "convert some of your functions to macros".
And converting abstractions to subpatches is much more limiting than that.
Inefficiencies in handling a great number of instances of abstractions are a great obstacle to applying "good" programming practices to PD patches. Using and reusing a great number of abstractions with many many levels of nesting is the only reasonable way (I can think of) of developing a large, complex, scalable, reusable "application" in PD.
well yes you are right.
however, it is perfectly possible to do develop large complex scalable
and resuable applications in Pd (sometimes i do this)
mfg.asr IOhannes
This message was sent using IMP, the Internet Messaging Program.
-
Chris McCormick -
Derek Holzer -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
matteo sisti sette -
Patrice Colet -
zmoelnig＠iem.at