On Feb 12, 2006, at 11:37 AM, Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
cyrille henry wrote:
i don't fear redondancy.
Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition.
Wherever possible objects with the same functionality should be unified.
I agree that this should be a goal for externals and built-in objects, however for abstractions I see it slightly different and I would rather support Cyrille's view. Although I abandoned Perl years ago, I may bring up the basic Perl philosophy axiom here: "There's more than one way to do it." I see it as part of the artistic freedom Pd offers to be able to do the same things in different ways - like it's part of artistic freedom to write yet another pop song about a broken heart.
We even have different versions of Pd: msp, devel, desiredata and now pd-extended. That's the way, the world is and thus it's the way, software is. With the Linux-kernel it's even worse than in our tiny Pd world.
Several of the [list]-abs are reimplementations of existing externals. Still I see a place for them, if alone because they are not externals.
The language should be free for people to do things in many different ways, I don't think that anyone really wants to restrict that. But I do not think its a good idea to have redundant objects in the standard libraries. Its good to have different objects that provide similar yet distinct functionality, like [math/clip] and [math/list/clip. But having different clipping objects in the same library with different arguments and inlets that do the same idea would be a bad idea and just add to the confusion.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste