Consider upstreaming deprecation of & from LSU fork

[cdsmith]

I noticed that @alphalambda removed the & operator from their standard library, in favor of pictures (renamed to combined in that fork). I've had similar thoughts, and I wonder if I ought to do the same thing (slowly, with a VERY long deprecation cycle) in my own copy.

I think the issue is that students find & to be too much like English, and not enough like a mathematical operator. That leads them to have incorrect expectations that it can be used in all places where they want multiple things. I've seen students try to use & to separate animations, items in a list, and so on.

I definitely haven't decided to do this. I think I'll wait to discuss with @alphalambda after it's been used there for a while. It would be a shame to do such a disruptive deprecation, only to learn that it doesn't help! Just creating the issue to capture discussion and track the decision-making.

[cdsmith]

Commit references above: https://github.com/alphalambda/codeworld/commit/a6cf8250b9e4205a82438aedca7966d82b9e796d

[cdsmith]

As mentioned in #28, an alternative to relying on pictures is to change the operation to something more specific, like |+| (chosen to look like layering two pictures, viewed from the side). The theory here is that maybe & is uniquely confusing just because it looks more like English grammar than a mathematical operator. Something like |+| looks like addition, and it may be more successful. But I don't know.

The reason I'm hesitant to go with pictures as the primitive is that it means teaching more punctuation on the first day of class, when it is already a race between getting students to succeed by the end of class, but also understand what they are writing so it doesn't feel like copy-and-paste. Students struggle with punctuation... like, a lot! I'm afraid another level of nesting would add a bunch of frustration at the start. So there's a trade-off there.

[cdsmith]

It looks like this is working out really well on the LSU side. There's also evidence that the problem is not only the specific choice of operator, but also the notion of a new binary operator in the first place. Also, it looks like making this most effective requires a new name for pictures. I'm still not sure of it, but I'm strongly considering this.

Steps would be:

1. Add a new layered function, which is the same as pictures.
2. Update the existing guide, sample code, and inspect function to use layered in place of both pictures and (&). This establishes layered as the canonical way to combine pictures.
3. After a suitable waiting period (for example, one year), add a deprecation warning to pictures and (&).
4. After a very long waiting period (for example, two or three more years), remove the pictures and (&) symbols.

That makes this about a 4 year migration, which seems reasonable given how much it breaks.