Mathieu Bouchard wrote:
On Wed, 15 Dec 2010, brandon zeeb wrote:
2. No control over abstraction (object) construction order and
lifecycle
What's that ?
3. No introspection (although not required, very helpful, and don't
tell me it's in some external, I don't care!)
Why do you don't care about externals that might do the job ???
IMHO, directing your criticism at pd-vanilla alone is extremely
unproductive. You have to accept the fact that doing real work in Pd
may require a lot of externals. It's sad, but it's like that. I
wouldn't use Pd if it didn't have externals.
I agree on this.. but why you say is it sad? It means Pd is modular like
any sane programming 'environment'... You couldn't do much in a
programming language using it vanilla no? (well apart from assembler
maybe)... IMHO
5. No interfaces or abstract abstractions (to control inlet patterns)
Strictly speaking, interfaces, or completely abstract classes, need
only be made explicit in languages that have strict method-lookup. In
languages like Python/Ruby/Perl/Tcl/ObjC/etc., all the lookup is at
run time, and likewise for PureData. In those languages, there is
usually no built-in way to declare interfaces, because the
method-lookup wouldn't use those declarations anyway.
Strict method-lookup normally means that "anything-methods" don't
exist, and that means that complicated workarounds have to be provided
instead of solutions that depend on "anything-methods" and loose
method-lookup.
I would like to know what you mean by "inlet patterns" here.
6. Unfriendly and inconsistent type system (it is cumbersome in real
use, although I get over this by using [list])
I once proposed alternate versions of [unpack], [select], etc., that
had no type restrictions. There was a discussion on it. See :
http://www.mail-archive.com/pd-list@iem.at/msg08636.html
http://www.mail-archive.com/pd-list@iem.at/msg08644.html
but also the rest of the thread...
7. and on and on In most Pd patches, I see people using a few lookup
tables again and again (ie: mtof). As this is a complete waste of
memory,
[mtof] does not use a lookup-table :
t_float mtof(t_float f) {
if (f <= -1500) return 0;
if (f > 1499) return mtof(1499);
return 8.17579891564 * exp(.0577622650 * f);
}
void mtof_float(t_object *x, t_float f) {
outlet_float(x->ob_outlet, mtof(f));
}
one can attempt the Flyweight pattern.
Please first give an example of a useful use of the FlyweightPattern.
[bypass~ some_process~ 330 1 3 9]
Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that
there are several quite different manners of doing that in Pd, no ?
But I have trouble reading definitions and tutorials of IoC. I
probably have used a bunch of different IoC techniques in Pd and other
languages already.
I mean that even simple patches without any abstractions would use
implicitly IoC in some manner.
Where [bypass~] expects it's 1st argument to be an abstraction and
the next 10 to be arguments to that abstraction.
If you used externals, you could make the number of arguments to be
variable and unlimited. You could also make it lookup the abstraction
in the parent's folder, so that I can put some_process~.pd in the same
folder as the main patch, for example.
Every patch which uses [bypass]~ must have 1 signal inlet and 1 event
inlet. Unfortunately, this interface can't be programmatically
enforced.
It's enforced at run time. There's also nothing wrong to having more
than 2 inlets in this case, as long as you wouldn't be using the extra
inlets in that case anyway (or can do without them).
In the end though.. does it really make sense to compare Pd (and
dataflow in general) to paradigms of 'written' languages?
I mean I do see a point in having something like Python easily usable
within Pd (see my recent questions about Py), but this is dataflow, I
guess if people (like me) love to use it it's because for doing this
type of stuff - I won't say audio or I'll get flamed by Mathieu :) -
it's more fun than doing it in more 'traditional' languages like
C(sound) and similar.
Lorenzo
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
