On Sat, Apr 17, 2010 at 1:38 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 16 Apr 2010, Spencer Russell wrote:
I'm excited about the idea of a more object-oriented approach,
Pd's implementation was made with an object-oriented approach. You can't get much more object-oriented than that. If you mean that the object-oriented approach has been implemented using C++'s grammar instead of having to invent yet another object system in C, you are right, and that can be a relief. However, this does not guarantee anything at all on the outcome of the project.
Agreed that Pd's code is certainly organized in an object-oriented way, and the architecture that Miller has constructed to do OOP in C is extremely clever and definitely nothing to throw sticks at. On the other hand, there are structures that come for free when using a language that supports real objects out of the box (such as real polymorphism) that are difficult if not impossible to achieve in C.
Much of ZenGarden is designed by copy+paste, and that's something that it doesn't get any better than Pd.
Meanwhile, the author claims ZenGarden has « clean code », presumably to imply that Miller's isn't, but there's no explanation at all on what it means to be clean. I think cleanliness means no copy paste. I also think cleanliness doesn't mean using variable-names that look like this_is_the_array_that_contains_the_outlets_sorted_by_horizontal_position.
I'm not ready to make blanket statements regarding the overall cleanliness of ZG vs. PD code, but there's definitely a significant reduction of boilerplate necessary to create an object, which seems like a step forward. I have some concerns about the extensibility of some of ZG's current architecture (the PdGraph object has a list of all the objects it supports hard-coded in), but it's still a young project with the architecture still somewhat in flux.
Then the externals API... I don't think that was compatible with anything. It's a lot easier to port your Pd externals to MAX than to ZenGarden.
agreed, losing the rich library of Pd externals would be a huge problem, and developing a flext-like abstraction layer seems intractable due to the significant under-the-hood differences.
It also seems important to note that the ZG guys aren't trying to replace PD wholesale, but just to provide a separate runtime library that makes Pd patches more embeddable (within other programs, on other devices). The project was started by RJDJ, so I don't imagine that dynamic patching is a high priority.
-s