But if you're also going to explain stuff as you go, rather than letting the diagrams speak for themselves, then I'd use whichever diagrams + explanations go best together.

And I'd also make those lines for position extend right to the edge of the paper. Otherwise, you'll possibly need to introduce the idea of the origin, and that's tricky.

Which of course means if you're showing two boxes, their position lines or shapes will probably cross unless you choose them carefully.

The only relative position is which instruction comes first (so yes, still introducing brain damage by Dijkstra's lights)

So, like, given these constraints, the thing you have is obvious in hindsight. But I'm not sure if the incidental complexity (like stuff not being sized correctly) is a help or a hindrance.

Good point. Time for human experiments.

So, for the case where order does matter, maybe find a way to help them discover what happens if you don't have the "right" order.

So yeah, I think I have this philosophical disagreement with Dijkstra and a bunch of FP folks. The order often does matter. Even when it doesn't matter, I mostly have an easier time visualizing a single sequence of steps rather than imagining a society of mind inside the computer doing independent work. So why bother introducing parallelism when it's harder to imagine and not universally applicable.

This is purely for introducing programming, of course. I can see how parallelism or non-determinism is useful for correctness. Then again, I've never been good at the correctness. Probably because of the brain damage..

Elm's picture env has similar qualities: https://elm-lang.org/examples/picture and avoids the need to track which argument goes to what nested function by using

|>

pipeline operator:

rectangle brown 40 200
        |> moveDown 80

In CodeWorld's case, that gets painful enough that the guide has to teach how to read nesting early on (plus editor coloring paren levels): https://code.world/doc.html?shelf=help/codeworld.shelf#expressionstructure/nestingexpressions @Ivan Reese will be amused they draw block diagrams, as something the student should imagine, while editor remains textual: ("the 🍰 is a lie"?)

I'm sure Haskell can do better with fancier operators. Even other choice of arg order could help — this is bad:

colored(translated(scaled(square, 12, 2), 4, 3), red)

but if they did this, one could read each transformation and its params together:

colored(red, translated(4, 3, scaled(12, 2, square)))

Ooh try the CodeWord [Inspect] button 🍰 You may need to drag the divider to the right so picture gets smaller and you can see the inspect tree below it. It shows all the intermediate parts and how they were combined to build the picture.

> Would you agree order of statements is essential complexity (for your pedagogical goals) whereas order of (x, y, w, h) is incidental complexity? > Or do you lump both into same mental "it matters" bucket? I try to avoid those terms 😬 "Complexity" is complex and intangible. I try to stay as concrete as possible. Here the only reason I'm trying to avoid order between arguments is I know the 6yo kids have trouble with it. The four numbers look like similar things but mean different things. They do some experimenting to figure out the first number means "how far right it is", then start working on experiments for the second, and by the time they're done they've forgotten what the first number means. So it seems like a problem worth solving. The order of statements so far hasn't seemed like a problem to solve. They already understand from reading that things go from top to bottom, it doesn't even come up. And the order is a lot more reasonable when the things being ordered have the same meaning. Draw this, then draw this. Easy. At least so far 😄 We've only done sequences of 2 statements so far. What complicates ordering is conditionals and loops, and FP does have value when we get there. You probably know that my bias with computers is to emphasize reliability above all else. The goal is to be able to have agency with the computer to the extent that you forget about the tool and focus on what you're doing. Here the kids got to experience that the math they're learning (addition, inequalities) is useful in a very different context. I think trying out lots of notations and tools and then running into limitations like, "you can't use this there, you can't do that here" moves us away from that ideal of a computer that disappears from view. This is kinda why I have them using https://akkartik.itch.io/carousel (and not at all because I made it 😂) -- it's available on all their devices, and I know it's as close to a minimal stack as I can think of that is available on all their devices. I know what problems it can run into in the middle of a lesson, and I know what to do to get us back on track. I think that's worth a lot. More than Bret Victor's ideals. They are still important, which is why I appreciate the nudge to reread them and to find out about CodeWorld. But only if they build on that reliability and ubiquity, IMO. We programmers have a tendency to circle obsessively around notations and tools. There's some value in trying to push back on that tendency and just build stuff (that is not notations and tools).

Yes, there's definite value in a UI that lets them scrub around the numbers inside each call. But I don't have that UI right now, and my attempts to create it will also spawn bugs. Good software takes 10 years to create, but in 10 years my kids will be 16. So situated software has to respect certain limitations of time and energy, I think. I definitely do still appreciate recommendations of new tools. I can play with them and decide whether to include them. And even if I don't I might obsessively circle them at night while the kids are asleep 😂