About not sharing the block's color in empty slots to help beginners understand HOFs

[DyslexicAwe]

Beginners learning to use Higher Order Functions probably deserve all the help that they can get, I guess.

Beginners (as opposed to experienced users to whom this is self-evident), can not really tell if "empty" slot is really empty, waiting to be filled (by items of a list), or maybe it is not accepting any inputs whatsoever because it is filled with color already. As I see it, it is not very helpful that the nested block's empty slot gives beginners a false impression of being already filled/closed/not accepting any inputs whatsoever, because it is already filled with the block's color.

Please see the picture (in a SET block example) taken from the Snap! Reference Manual p. 55 with an example of a nested SET block within a HOF (i.e. RUN block) declaring the clone's (new) parent the first neighbor sprite.

The first picture is showing the empty slot as it is now, i.e. filled with the block's color, while the other picture below is showing a proposed white-colored one.

I'd like to hear your opinons, even though probably not many beginners read this.

[brianharvey]

I can see how that would make sense, but a white slot already means something a little different, namely, that you can type into it. Thus, only numeric and text/Any slots can be white. Some text inputs can only take on a fixed set of values, chosen from a menu, and those aren't white because you can't type into them -- but they're still input slots that can be filled.

A while ago I proposed a different way to mark fillable input slots in procedure-type inputs, and it's on our list of things to think about but not something that excites Jens last time I checked.

[DyslexicAwe]

Thank you for replying. I appreciate it.

[DyslexicAwe]

Maybe a compromise can be reached by still having the white slots as the number-or-text(Any)-fillable-only ones, while other empty slots (especially those to be filled by inputs provided by HOFs, but also those containing a pull-down) could also be white AND being marked with triangle-shaped arrow?

In the image below both proposals are shown. If you compare them, I propose a cosmetical-only visual change aimed to help beginners, which makes almost no changes to the language design philosophy, I suppose, while rdococ's proposal does (if I understand correctly).

[brianharvey]

Using white for this purpose is a nonstarter. We distinguish "read-only" pulldown menus (like SET) from writeable ones (like ITEM) using white. You don't want the same visual hint to have two different meanings.

Here's an example of one of the proposals I made:

[DyslexicAwe]

Here is how "a writable vs other_kinds_ofinputs can be distinguished (visually hinted at)_ by arrows only philosophy" now "mapped over" your design would look like. (I.e. instead of the blue circles outlining white slots, blue arrows in various shades of blue are used.) Just like in your case, different shades of blue are used in order to hint at whether it is the same input used twice or different inputs are being used in a formula.

I have no intention to persuade you into this "philosophy", I'm just sharing it.

See the picture

P.S. If I was persuading you, which I am not, I would point out that the orange "list" symbol's on white background although a user cannot write texts or numbers into it, so the non-writable and/or ringified blue "arrow" symbols can be on white backgrounds, too. instead of

[brianharvey]

Arrows already mean something, namely, that there is a pulldown menu in this input slot.

Maybe one reason we're talking across each other is that there is some ambiguity in the word "fillable." Any empty input slot can be filled by the RUN or CALL block, and therefore indirectly by a higher order function. Most input slots let you drag an expression onto them. The white background is for the subset of input slots into which you can type literal values.

The thing for which we need a new notation is to help users understand (1) when a function slot is empty, what arity of function (how many inputs it takes) should go there; and (2) when a function slot has an expression in it, which empty slots will be filled by which argument values. Since this is a new kind of information to give users, we shouldn't recycle any existing notation: not whiteness, not downarrows, not gray rings, not slot shape. We should use a notation that doesn't already mean something different. The colored rings in my picture are one proposal.

From the ellipsis in your picture of COMBINE, I think you've misunderstood why I put two different-color tiny ovals in my picture; they indicate that the function you put in that slot must accept exactly two inputs, no more no less.

[DyslexicAwe]

Thank you for trying to pinpoint the reason for our differing perspectives.

Maybe the main reason is that from my perspective, which is far from being a perspective of a scientist you are, the "literalness - nonliteralness of inputs" is much less important and thus it merits not the emphasize it is given by reserving the whiteness for the slots that are on "the literalness side". Literal value, a variable, a procedure-as-data, they are all just an input to be dragged into a fillable slot, as seen from my perspective. What matters in my perspective, though, is, whether I am able to drag them into a slot myself or not -- because a higher order function is going to "do the dragging" (metaphorically speaking) instead of me, and, therefore, I am not able do it myself. What I am still able to do in this case is to provide the HOF with a list of data, the items of which will "be dragged" (metaphorically speaking) by the HOF itself (automatically) into appropriate slots and operation/expression will be performed on the items.

In a nutshell "user's freedom vs a degree of automatedness" is what matters in my perspective and thus merits to be notated somehow.

About the need for the ellipsis (from my perspective). I think because none of the SUM, MULTIPLY, JOIN, JOIN WORDS, AND, OR operators is truly binary in essence, only their blocks are designed as binary, the COMBINE's notation needs to emphasize that items "are dragged in" (metaphorically speaking) neither one by one nor two by two, etc, but all at once (...) automatically.

[brianharvey]

So, you're saying that since white slots are the most vivid notation we have, we should use them for the most important thing? That would indeed be the most sensible approach if we were designing in a vacuum. But millions of Scratch users plus a million or so of ours already know what a white input slot means (including the ones who couldn't articulate it). We have to take that into account.

[DyslexicAwe]

Can't argue with that. So it can only be implemented in a private ("remix" of) Snap! Hmm...

[brianharvey]

No! That's even worse, having two different identical-looking software development systems in which the code looks the same, but the same style means different things in the different versions. Why would it be so horrible if we use a new notation for this new meaning?

[DyslexicAwe]

But is it really a fundamentally new meaning? Doesn't this mean that differences between the literal values vs variables vs procedures-as-data are seen as more important that they really are? In my opinion/perspective is important whether a particular data can be "dragged" (literally or metaphorically) into a particular empty/fillable slot (either by a user or by a higher order function), or not. I think, IDE could prevent a dragged thing to be dropped into a slot if that makes no sense. I guess this is possible.

[brianharvey]

This is why I don't like metaphors. Yes, from ten miles up, all the things we're talking about have something to do with some kind of "filling." But, as I've been trying to explain, the differences are very different, and encouraging users to think of all these different ideas as if they were the same idea is just condemning them to a permanent state of confusion. It's as if you were telling users that when they have a cavity they don't have to go to the dentist for a filling because they can just rub apple pie filling on the tooth instead. Is the difference between pie filling and cavity filling one of the ten most important ideas in the entire history of ideas? No. But if you don't understand it, you're condemned to a life of severe pain.

Consider these two expressions: Yes, in both cases, the two input slots in the + block will be "filled" when it's called by the higher order function. (And you know this, not because the slots are white, but because they're empty! ) But what that similarity doesn't tell you is that each time map calls +, it will fill both slots with the same value; each time combine calls +, it will fill each slot with a different value! And yes, I think that's pretty important, not if you want to write a book on philosophy of programming, but if you want to understand how some specific program works and what it actually does.

[DyslexicAwe]

Brian Harvey said:

And you know this, not because the slots are white, but because they're empty!

Of course.

I never opposed that knowing something is "fillable" comes from seeing it is empty, what I am saying is that the most visible way to show something is empty is to make it white because any other color is making it less clear that it is, well, empty, at least for beginners.

And I am saying that adding different (little) symbols into that whiteness is enough and that there's no need to color those empty spaces/slots in order to show some, more (for you) or less (for me), important differences, which we seem to be arguing about, but in fact we are not.

We are arguing about the magnitude of differences because it is not as huge as to make it necessary to "color the emptiness" different colors. If I was downplaying the differences too much in the heat of discussion, I'm sorry. It was not my intention. What it is, though, it is showing that using different colors to "color the emptiness" because of the differences is not necessary. I now agree with you now that a new notation is being needed for a new meaning, and that the downarrows were not the best symbols. New symbols are needed and they can be on white emptiness, I think, so here are symbols that resemble, as I see them, small boats that are carrying the items into the HOF. (They could be seen as cups to be filled, too, I guess).