[PD-dev] list math

[Hans-Christoph Steiner]

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