I wanted to ask if anyone had thought of clever mnemonics to get the order of prepend and append right. I usually get them backward!

I think my wrong thinking goes like this... just taking append as an example. "Append" has a direct and indirect object: I (the subject) append the direct object onto the indirect one: if I append "food" onto "cat," I get cat food.

In my mind, the left inlet is the direct object, so then I think that the left-hand list should follow the right-hand list... but of course this is backward. (I get this so consistently wrong that I'm tempted to think, maybe the semantics are just wrong in both Pd and Max... but of course I just have to adapt my thinking.)

I guess I should think of it like: RHS is more consistent, LHS probably changes on every invocation. Prepend, the consistent part is a prefix; append, it's a suffix.

Any other ideas?

hjh

reallife.pd

@jameslo said:

Maybe you could think of object oriented languages like Java...

Ah I see, so, retrain myself to think of the left inlet as the receiver of the prepend or append message (though even here, the semantics are arbitrary).

@ingox Very cute! I'll have to use that in class when talking about list operations

hjh

@ingox While I have never had an issue with prepend/append, I have never been able to remember if [list] was shorthand for prepend or append. Fixed.

I like to think that [list] will do a "list join", and then append is "join the first list with the second"... prepend is like swapping the two lists before joining, so, in preparation to join, swap first, the second comes first and the first goes last... maybe this help?

Hm, actually the thing about object oriented languages doesn't hold up, I think.

Object oriented languages are all about the state of an object, and the final arbiter of that object's state is the object itself. So you don't have a godlike actor to squish lists together. The only way to append/prepend in a paradigmatically OOP environment is to request one or the other list to append or prepend something else onto it. And here, the sensible semantic is:

var a = ["abc", "def"];

a.append(["ghi"]);
-> ["abc", "def", "ghi"];

Max and Pd list operators are different from this: You are passing lists around, but the lists are passive. They're not objects, rather, messages. Probably this is where the confusion comes in: by casting the lists as operands, there's no hierarchy, and as a result, it's completely arbitrary whether prepend(A, B) means B-then-A or A-then-B. Both equally make sense. So then there's room for me to read it so that A is the direct object: "prepend A onto B" -> A, B where I should be reading "prepend the remembered list onto A"

I suppose I'll never really agree with the Max/Pd semantic on this. Makes no sense to me, tbh I think Miller made a mistake here. But every programming environment has these gotchas.

hjh

@ddw_music Oh, ha ha, I thought you had already pointed out the ridiculousness of my suggestion by framing OOP as message passing, i.e. "Oh, so you're asking me to treat the Pd message as the object, and the Pd object as the message being passed to the Pd message asking it to transform itself? Hey, thanks a lot, that clarifies everything!" I was already laughing.

In my (very weak) defense I was mostly thinking about order. first.concat(last). a.append(b). But I was also thinking about the append method of an object. I learned OOP not as message passing (e.g. Smalltalk) but as encapsulation. Some early non-OOP languages (I can't remember, so long ago...Pascal?) had facilities to group data together with the functions that accessed/modified them within some scope, and unless you had access to that scope, then you couldn't just go do whatever you wished with the data. Honestly, I used to try to do that in assembly language, though admittedly there was no encapsulation enforcement--it was just about hiding all the nasty details in a single compilation unit. So if I were to come across the append method of a list object, I would assume that the list was thing that was being modified and that the argument was the...uh...argument to the modifier.

Remember that [list] and [list append] are synonyms. Are you convinced yet?

That said, I'm never shocked whenever someone tells me that my intuition is weird. I think you're better served by @ingox's and @oid's suggestions, which are unforgettable IMHO. Unless you're too young to know who Queen is, in which case you substitute...uh...I dunno...Lil Nas X lyrics?

@ddw_music If this can work for you:

Maybe this can in the same way?

@jameslo said:

@ddw_music Oh, ha ha, I thought you had already pointed out the ridiculousness of my suggestion by framing OOP as message passing...

Oh, sorry, that wasn't my intent at all... when I initially read your previous post, I thought it made sense -- I wasn't trying to ridicule, but rather, sincerely trying to understand. Probably should have left it alone but I kept thinking about it.

I never intended any pejorative in any of these posts -- it's a confusing API and IMO we're all working together to find useful vocabulary for it.

With that said, @ingox 's last one is probably the big winner... it had actually crossed my mind at some point that "subtract B from A" rolls off the tongue, so why could "prepend B onto A" not similarly roll off the tongue?

hjh

@ddw_music For me it is more visual. I see the main bang flowing down through the hot inlets, the cold inlets being prepared beforehand.

There is even this technique to structure complex code, with the convention that all the parts on the right side only feed into cold inlets: