[PD-dev] stripping down Pd-extended's default libs

[marius schebella]

Roman Haefeli wrote:
> On Tue, 2009-02-17 at 11:24 +0100, marius schebella wrote:
>> hey hans,
>>
>> if it's called "extended" and you strip it down to the bare bones,
>> then where's the extended part?
> 
> i think, noone wanted to strip down anything. this is only about not
> loading the whole bunch of libs automatically anymore. how does that
> make pd-extended less 'extended'?

first, I think there is a difference between a "user" user (who 
downloads a patch) and a "patching" user.
I always saw pd-extended as a consensual (ok, proposed actually by only 
one person) agreement on a set of object classes that are available in 
addition to pd vanilla. It was a way to make sure that if a "patcher" 
programs a patch for pd-extended that every other pd-extended "user" 
will have the same setup and thus be able to open the patch without errors.
if you leave the loading of external(librarie)s to the user user, that 
means, if you allow/force the user to create his/her own order of 
startup libs, you cannot count on this behaviour anymore.

>> eventually, I think users should not have to bother with namespaces at
>> all. I still consider namespace declarations in a visual dataflow
>> programming tool to be a hack.
> 
> can you elaborate that a bit?  to me it looks perfectly normal, that i
> have to at least call the tools, that i am going to use. 

ok.
this is a problem of software architecture. where to draw the border 
between what is "given" and what is open. to me object classes should be 
part of the given world, because one, it makes coding, teaching, 
deploying easier, if all patchers were using the same set of tools and 
two, if you create your own screws, then you also have to ship the screw 
drivers (not only declare them).

I know the pd concept is, not to insist on a predefined set of object 
classes, which of course makes pd more extendible, but with this huge 
overhead of having to hassle with declarations, namespaces, which are ok 
for written programming languages, but maybe not for a building block 
programming tool like pd.

especially if - like in the case of the pd externals - the libraries are 
arbitrary. (like any categorization system). they are not sorted by 
topics but rather by coders. just think, a new pd patcher has to learn 
that an object was programmed by IOhannes, and therefor it is in the 
zexy library. another one was programmed by someone at the IEM, 
therefore it is part of the iemlib. furthermore the name of the 
libraries can change, the same code can become part of two different 
libraries and some objects do not even belong to a library.
if you are consequent in providing your tools, it means that you have to 
ship the particular pd externals together with your patch everytime you 
want to share a patch. because then referring to zexy is not enough 
either, someone else could create a concurring external library also 
called zexy. then what...

plus, not agreeing on the toolset (set of object names) will always 
cause your own abstractions to be potentially overwritten by 
internal/external object classes, which get loaded instead.

plus, with some objects it is necessary to load them in advance, for 
example all objects with abbreviations, or some objects that enable 
special features (like the loader for luascripts).

pd is *not* like c, c++, java, these languages create applications, but 
the way I would like to see pd is, that pd programmers don't create 
standalone pd versions, but only pd patches.

plus, don't expect (pd-x) patchers ever to declare all objectclasses 
that they're using.

I hate to say this, but standards and specifications can really make 
life easier. the habit to leave many things opens allows people to addon 
a lot of crazy stuff, but it is counterproductive from the viewpoint of 
patch sharing.

marius.