[PD-dev] abstractions

[Mathieu Bouchard]

On Mon, 7 Jul 2008, Roman Haefeli wrote:

> sorry, if i now seem to be nitpicking, but this is actually what i mean
> by 'core classes': the classes, that cover the initial focus of the
> library, in the case of gridflow the classes, that do deal with grids.

ok.

> i don't think, that something hardcoded as [range 8 9 10] in
> [#camera]/[pd camera] justifies the use an extra external, if three
> [moses] objects cover exaxtly the same.

Look, [range] is in use in more abstractions than that, plus in more 
patches that you can see (unreleased stuff). [#camera] was just one 
example, and furthermore, [range] was just one example. There is also 
[route2], [listread], [listfind], and whatever else, that get used in 
abstractions, and that aren't as straightforward to replace by Miller's 
builtins.

> i rather meant: is it really necessary to have the exact functionality 
> of [range]? cannot the same be achieved by having some [moses]es here 
> and there?

It's not the point.

> different languages provide different ways to deal with issues.

And Pd doesn't provide enough when it comes to supporting abstractions in 
a way that makes them be able to use Pd in a way equivalent to how normal 
externals can use Pd, and at a price not significantly greater.

For example, [#in] and [#out] aren't in such great shape since they became 
abstractions, and they're significantly more complicated, because even the 
simplest dynamic patching is complicated.

At Pd Convention 2004, there was a nice moment during the papers sessions, 
where there was an apparent consensus that as many things as possible 
should be made as abstractions. I still think about that. I like the idea, 
and I've always liked the idea, and you can trace my appreciation of that 
idea back to the original design of GridFlow, but it's not always so 
feasible just by using Pd.

> i might be wrong, but i haven't seen a case yet, where [range] would be 
> the only option to solve a certain problem.

Originally [range] was only there so that when I convert jMax patches to 
Pd patches, I wouldn't have to do elaborate search-and-replaces. Although 
later on I could have decided to let it go and do things the Pd way, 
instead I came with the idea that [moses] was not enough and that if [sel] 
and [route] and such, take multiple number of arguments, [moses] should. 
In some patches I had to string 8 [moses] together.

Anyway, you seem to be on the defensive side... we don't absolutely need 
[range] so why bother? This is influenced by the fact that it is 
troublesome to make [range] in the first place, because at the same time 
it's not possible (or overly difficult) to make an abstraction out of it, 
and because it's troublesome to even carry portable C code around if it's 
not already in a very popular distro. If it were easy to make an 
abstraction, perhaps you wouldn't think like this. Or perhaps you would 
think like this about [range] anyway, but you wouldn't think like this 
about another example such as [route2].

> but in this case i am more in favor of repeating [moses]es instead of 
> introducing another class, that doesn't really cover new possibilities.

not much actually covers new possibilities. any abstraction could be just 
pasted in a patch so that you don't need the abstraction. It's all a 
matter of how much you're ok with doing that. It's more of a quantitative 
difference than qualitative.

> in this particular case, i also prefer [moses], because it does not 
> crash, while [range] crashes pd,

I don't have (nor remember) that bug.

I disavow any version of GridFlow prior to 0.9.2, and frankly, I also 
don't remember all of the bugs that might have been in 0.9.2 or 0.9.3. If 
you want to report bugs, do it relative to the last release, 0.9.4, or the 
SVN. (I uploaded it Friday, just didn't send an announcement yet).

> from a developers perspective: why bother with making new code work, 
> that introduces new problems and needs special attention, if pretty much 
> the same could be achieved with a bit more effort in the user domain?

Exactly. So why bother improving Pd? It's hard, it introduces new 
problems, and needs special attention. If any possible improvement looks 
like it could be great, just break down this possible improvement into 
smaller, more incremental improvements, so that when you look at them 
individually, any of them looks like it's not worth doing. Looking at the 
big picture makes one worry, and we shouldn't worry, so let's not look at 
the big picture.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec