On 06/04/2015 02:11 AM, Chris McCormick wrote:
On 04/06/15 06:03, Jonathan Wilkes via Pd-list wrote:
(And fanouts are more obvious than [trigger] objects wired in the
wrong order, and especially where recursion is involved.)
I am confused by this assertion. Can you explain like I am five?
An Argument Against Dogmatic Triggers
My toolkit:
properly
Your (proposed) toolkit:
doesn't matter but you forced yourself to use trigger anyway
Probably my failing but I am unable to imagine a situation in which "fanouts are more obvious than [trigger]"
If I run into a bug that looks like I screwed up the order of operations, I can start with the fanouts and try to violate my own fanout premise. If I find a part of the patch where order of fanout wires indeed does matter, I instantly know it is the bug and can immediately fix it.
If you run into a bug that looks like you screwed up the order of operations, you can't immediately tell the difference between the triggers that are required to run the patch properly, and the ones that you used merely because you want to avoid the danger of using fanouts (i.e., dogmatic triggers).
Now, you might say that dogmatic use of [trigger] actually forces you to consider the order of operations in a way that my fanouts do not. And that may be true. But inevitably you will end up with a few parts of your patch where you _think_ order doesn't matter. If you use [trigger] in those cases anyway (and choose some arbitrary ordering), you remove the visual evidence that you thought the connection order could be unspecified. If it turns out you indeed chose the wrong order for your trigger, you make it harder to track down that mistake because you cannot tell the difference between your dogmatic triggers and the normal triggers.
and I don't understand the qualifier "especially where recursion is involved".
If I have a choice to debug a recursive (control) object chain using my toolkit vs. your toolkit, I'll choose mine. Because I know to start with the fanouts, and then move to the triggers if I still haven't found the bug. With yours I can't do that because I don't have any visual information about where in the object chain you may have assumed that the ordering of some operations wouldn't affect the function of the patch.
That may sound crazy, except that a) recursion is _really_ awkward and difficult to reason about in Pd and b) Pd _lets_ you make fanouts. If the UI didn't allow fanouts maybe it's a different story. But there are just so many examples in the wild that use fanouts, even fundamental idioms like [f]x[+ 1]. Scripture-style quotations or no, there's just no going back at this point.
So to me, it's more instructive to try to consider which parts of a patch require ordering, which don't, show that in the patch, and think critically about all the above.
How do you define "obvious" as used here?
For example, looking at a patch... *2 seconds of eyeballs doing their thing*... oh, there is the fanout.
vs...
Oh, _everything's_ a trigger. Thinking... *2-2000 seconds of thought*... oh, there is the dogmatic trigger.
There are of course other types of bugs, but that's the comparison for wire-ordering bugs.
Last night I spent several hours tracking down a bug that turned out to be because I had used a fan-out instead of a trigger. I am not 100% sure if this backs up your point or refutes it but either way it sucked. :)
I think I will continue to try and make myself use trigger objects instead of fan-outs to avoid that type of bug again.
I think the more you consider the consequence of how things are ordered in Pd, the easier it will be to track down bugs.
You might still achieve that by dogmatic use of trigger. But I think it's counter-productive to make proclamations against a feature that the UI allows, _and_ that everyone including the original author uses in every non-trivial patch.
-Jonathan
Cheers,
Chris.