How to visually discriminate between sprite properties and user variables

[s_federici]

I'm fruitfully using Snapin8r to import Scratch projects to Snap (thanks @djdolphin!). Everything works smoothly.

I recently noticed that, when importing some Scratch blocks, it is not easy for the user understand what is the real meaning of the resulting Snap block.

For example, when I translate the Scratch SET ROTATION STYLE TO block, I get what apparently is a "SET VAR" Snap block, but it is not. You can have a look at

https://snap.berkeley.edu/snap/snap.html#present:Username=s_federici&ProjectName=set%20rotation%20style-with%20var

The first block is just a Snap variable called "rotation style", while the second block will select a new rotation style for the sprite by using the values 0,1 and 2 (don't rotate, rotate, left-right).

The two blocks are internally perfectly discriminated by Snap, but it is difficult for the user to tell what is what. Is there a way to clearly discriminate the two blocks visually?

Just to complete the topic, to perform the same operation in Snap, without importing a Scratch project, I can select "my" in the "SET VAR" block menu then "rotation style" in the submenu. This time you get a "my rotation style" property that does exacly the same of the "SET rotation style TO" block imported from Scratch via Snapin8r, even if with a different "look". Incidentally, I can create a "my rotation style" variable that will look exactly as the "SET VAR my rotation style" property.

Am I missing something?

[bh]

@s_federici

Am I missing something?

Nope, that sums it up pretty well. I would have made a SET MY block in Sensing with a pulldown menu like MY, but Jens has a thing about adding new blocks. We can probably improve things by putting the attribute names in italics in the SET block.

[d4s_over_dt4]

@bh

We can probably improve things by putting the attribute names in italics in the SET block.

italics="[" stuff "]"

[sarpnt]

@bh

Jens has a thing about adding new blocks

why not remove blocks then? i think most of the CHANGE blocks could be removed without any confusion (i consider motion blocks an exception for a few reasons)
NEXT COSTUME doesn't really make sense without PREVIOUS COSTUME, but people seem fine using the costume number for that, so NEXT COSTUME could go
GO TO X Y is the exact same as GO TO with a list, i think the XY version could go if the other defaulted with a list already in it
i have no preference for whether TURN COUNTERCLOCKWISE is removed or GO FORWARD () LAYERS is added, but one of those should get done

i could probably name a few more but they'd be a lot more controversial, and i think some blocks are stuck in there (as in the design could be improved but not without breaking every project), the ones here could probably just use some code to convert the old blocks when loading

besides, sensing really doesn't have that much in it. control and variables are much more of a problem, although variables would be easier to browse if variables, lists, and other were split up
(why are they even in the same category anyways? lists and other would be perfectly fine buttons)

[ego-lay_atman-bay]

@sarpnt

why are they even in the same category anyways?

I think it's just something they inherited from scratch.

[bh]

@sarpnt

why not remove blocks then?

We keep talking about removing blocks. CHANGE (var) BY (amount) is a perennial candidate. And we could do it without breaking old projects by converting such projects as we load them to, e.g., SET (var) TO ((var) + (amount)). But we never do it, I think because we still want Scratch kids to feel welcomed when they discover Snap!. Or because we're superstitious about diverging from (as opposed to adding to) Scratch.

[s_federici]

@bh

We keep talking about removing blocks. CHANGE (var) BY (amount) is a perennial candidate

If redundant Scratch blocks should be removed from Snap, you could just leave less than 30 original Scratch blocks (keeping of course all Snap advanced blocks).

It all depends on what level of user Snap wants to be attractive to.

If one of the targets is the young newbie, the CHANGE BY block should be left, as writing something like "A = A + 1" is one of the less intuitive ways of expressing "increase by 1". The same is true for a lot of other blocks inherited from Scratch.

An alternative, if the main target of Snap are users interested in advance programming easily implemented with blocks, would be moving 80% of Scratch-specific blocks to a library, that the interested user (or teacher) can add back to Snap for their students. For this, the new (very interesting to me) possibility of adding a default project to be loaded at startup with all the necessary settings to make transparent to the students the "low level" Snap, would be an excellent solution.

[s_federici]

@bh

I would have made a SET MY block in Sensing with a pulldown menu like MY, but Jens has a thing about adding new blocks

If the variables and internal properties could be discriminated without possibility of confusion, not adding a new block would be the best solution. But I guess the SET MY block is really necessary. Even having italics (or something similar) arguments would not be very intuitive.

When you have a getter, having a clear corresponding setter, to me, is a must.

Maybe this could be done with an optional argument. The arrow for optional arguments is usually at the end of blocks, so maybe we could express this optionality by adding "AS PROPERTY" at the end? That is:

SET ROTATION STYLE TO 1 > (with "closed" final arrow it would be a variabile)

and

SET ROTATION STYLE TO 1 AS PROPERTY < (with "open" final arrow it would be a property)

[s_federici]

An alternative could be extending the usage of the SET globalFlag TO sensing block, that now it's just for boolean true/false flags. To avoid confusion with global local settings, it could be extended to

SET flag/property FOR <this sprite/all sprites> TO value

updating the set of flags/properties available in the first argument menu as soon as the user select "this sprite" or "all sprites" in the second argument menu (exactly as it already happens for the "OF" sensing block).

[bh]

@s_federici

writing something like "A = A + 1" is one of the less intuitive ways of expressing "increase by 1".

But luckily we don't use "=" to mean assignment, now do we? No fair using the idiocies of idiotic languages as an argument here.

@s_federici

maybe we could express this optionality by adding "AS PROPERTY" at the end?

The user would type the property name? And could type anything? That sounds clunky. I think the entry of attributes to set is fine as is; the issue here is that once you've entered it, the display of the attribute is maybe confusing. If we were going to do anything like that, it'd be to magically add ATTRIBUTE after the word SET when the user picks an attribute.

But that's really complicated and undiscoverable. I think a Sensing setter block is much better than anything like that. Besides this visual ambiguity problem we're trying to solve, it's just much more discoverable if the setter is next to the getter in the palette.

[s_federici]

@bh

But luckily we don't use "=" to mean assignment, now do we? No fair using the idiocies of idiotic languages as an argument here.

Very true. But, at least to me, setting something to itself +1 is not much better.

@bh

The user would type the property name? And could type anything?

Of course not. As I said, once the user selects the value in the second argument's menu (that is either "this sprite" or "all sprites") of the "SET FOR TO" block, they will have the correct menu with all possibile values in the first argument's menu (that is either "rotation style" etc for "this sprite" or "video capture" etc for "all sprites").

@bh

it's just much more discoverable if the setter is next to the getter in the palette.

Agreed. So the "SET FOR TO" sensing block should be close to the "OF" sensing block in the Sensing category.

[bh]

@s_federici

setting something to itself +1 is not much better.

So, are you saying we should only allow functional programming? Because the problem isn't with self-reference. It's really the same if you say SET x TO 3 and then later in the program you say SET x TO 87. You aren't really taking in that we don't say x=x+1. We say SET x TO x+1, which is totally understandable and non-paradoxical. Plus, setting x to x+1 happens all over the place in real life. Your clock does it once every minute, for example.

Also I don't like the FOR part of SET FOR TO. If you want to change something in another sprite, you say TELL so-and-so TO [SET ...]. If I had my druthers, we wouldn't have MAKE A CLONE OF either; we'd only have a reporter NEW CLONE. But Jens thought it was really important to do it exactly the way Scratch did it.

[s_federici]

!!! WARNING: VERY long post. Skip it if you are not interested to the history of computer science!!!!

There is a lot to say about this. I'm really happy of discussing these topics.

@bh

So, are you saying we should only allow functional programming?

Of course not. As much as I liked programming in Lisp in the 90's, I would never use Lisp as an educational programming language. Educational programming languages are my main interest. With "educational" I don't mean programming languages used to teach complex computer science concepts in an easy way. I mean programming languages to easily introduce people that are not interested in computer science (often afraid of computer science) to computational thinking and the joy of automation. Getting as far as possible is a plus. Not to make them quickly drop the subject is a must.

So, what I like is simple and intuitive programming. The less I have to explain, the more what they see is (to them) intuitive and close to the way they would express their solution, the better.

To me, Snap is a wonderful threefold tool: 1) it is based on the same simple concepts that are the base of Scratch, 2) it makes available to me very powerful instruments to expand and extend it, and 3) it is implemented in a clean and easy-to-understand way. So 1) I already have the most part of what I need, 2) I can extend it without having to explore every time the source code, and 3) if it happens that I have to dig into the source code I can get the results I need in a reasonable time (instead the Scratch source code is a nightmare).

So, let's start.

@bh

You aren't really taking in that we don't say x=x+1. We say SET x TO x+1, which is totally understandable and non-paradoxical

Unfortunately, it is not. And I can say it without any possibility of disconfirmation based on 20 years of teaching computer programming with A=A+1 and 14 years of teaching it with SET A TO A+1 (I know, you have more experience). I don't say it is not understandable to anyone. What I mean is that it is not intuitively understandable to "my people". In general, variables are my students' nightmare. After you learn about them and use them for several months/years they are ok. It is better if you learn how to use them in a clean way, but, even if you don't, you can easily get everything you need. But if you learn about them (and you have to build a complex project for you final test) in only 3 months, they will cause you a lot of headache. Scratch's Stage monitors help a bit. But not completely. And the concurrent nature of Scratch without an easy search tool brings to announced disasters.

So, thanks to Scratch/Snaps reporters, I reworked all my lessons and now my students can just use (internal) variables without even noticing it. The don't need any custom variable. They just need to use a variable if they want to create a "score" without having to create digits by using 10 costumes each. But a score is easy. And the CHANGE BY block makes it also intuitive. For a score, even SET A TO A + 1 would work, as they have just to memorize it. But CHANGE BY is easier. If it were me, I would replace CHANGE BY by two blocks, INCREASE BY and DECREASE BY. But, as my students do not complain about CHANGE BY, it is fine.

@bh

Plus, setting x to x+1 happens all over the place in real life. Your clock does it once every minute, for example.

Sure it happens. But my students are unable to generalize this concept and to reuse it for everything. I could spend the three months of my course (15 hours of theory + 15 hours of applying these concepts in the PC lab) on just concentrating on variables as I was doing before 2007 (I had no choice). But then my students wouldn't be able to create anything more meaningful that a program to calculate the area of a triangle or the sum of the numbers in an array. As no one of them is going to become a software developer, so they will never reuse what I thought them.

Anyway, at the end of my course I teach them how everything we did without using variables (only sprites, reporters and messages) can be done in a simpler way (not conceptually simpler, but based on less scrips and less blocks) by using variables. I show them that the same things that they can do by using the more than 100 blocks of Scratch can be done by using just less than 30 blocks if you use variables. 10-20% of them prefer then to use variables in their exam, 80% prefers to stick to a multitude of sprites and messages. The large group of sprite/message lovers spend of course more time in developing their solution, but they can do it in a safer and to them easier way without making any mistake. Now that I moved to Scratch (and I based my lessons on sprites, reporters and messages) in every exam only 5-10% of my students don't get at least a "C" (but the most are "B"s and "A"s, some "A+"). In the past D-Fs were about 30%, or more.

@bh

Also I don't like the FOR part of SET FOR TO. If you want to change something in another sprite, you say TELL so-and-so TO [SET ...].

Fine to me. What is important is that the current ambiguous representation of "SET TO" for both custom variables and internal properties is corrected. Ambiguity is not something that can cope well with computer programming.

@bh

If I had my druthers, we wouldn't have MAKE A CLONE OF either; we'd only have a reporter NEW CLONE. But Jens thought it was really important to do it exactly the way Scratch did it.

Doing things the way Scratch does can be important in some respect. For example to make Scratch people evolve more easily towards the beauty of Snap programming. So, I understand Jens.

[bh]

@s_federici

Unfortunately, it is not. And I can say it without any possibility of disconfirmation based on 20 years of teaching computer programming with A=A+1 and 14 years of teaching it with SET A TO A+1 (I know, you have more experience).

Oh, I believe that students have trouble with variables! In our high school course we list algebra as a prerequisite only so that they'll know what a variable is and what a function is. (Although that's a little problematic too, because an algebra "variable" doesn't actually vary when you're solving equations; it's just a constant whose value we don't know yet. Variables in programs (can) actually vary.) If you're just saying that the concept of variables is hard to begin with, I agree.

But is it really the case that
SET X TO 3
⋮
SET X TO X+1
is harder to understand than
SET X TO 3
⋮
SET X TO 3+1
? If they understand that function arguments are computed before the function starts, and if people refrain from showing them = as an assignment operator in some other context, it shouldn't be mysterious just because X is involved in the argument expression. And if they boggle at it, show them
SET Y TO X+1
and then
SET X TO Y
.

@s_federici

What is important is that the current ambiguous representation of "SET TO" for both custom variables and internal properties is corrected.

I'll see what I can do. :~)

@s_federici

So, I understand Jens.

Oh, so do I. All else being equal, it's best if we behave like Scratch. But we're not consistent about that. For example, Scratch displays the position of the sprite under the stage next to the sprite's icon. We don't do that, and when kids come to Snap! from Scratch some of them complain about it. But Jens, the same Jens who thinks we should be like Scratch about clones, says we don't have to implement that because you can put watchers for the sprite's position on the stage. Which is true, but that fills up a sizable chunk of stage space. And also, unlike you, Jens hates CHANGE var BY amount and periodically threatens to remove it. (I'm glad you explained that your students find it cognitively more understandable, so it's not just as a shorthand for them.) So it's a decision each time we add a feature whether we should do it Scratch-style or rely more on reporters than on commands. And I think when clones were brand new we should have only provided a reporter.

But my main point here isn't to convince you about any particular decision, but just to point out that there is a decision to make each time.

[s_federici]

@bh

(Although that's a little problematic too, because an algebra "variable" doesn't actually vary when you're solving equations; it's just a constant whose value we don't know yet. Variables in programs (can) actually vary.)

Yes

@bh

If they understand that function arguments are computed before the function starts, and if people refrain from showing them = as an assignment operator in some other context, it shouldn't be mysterious just because X is involved in the argument expression

They can see what variables are thanks to Scratch/Snap monitors that show them what happens when a variable value is reassigned. Then they can replicate the usage of variables they have already seen. But they are totally unable to extend the concept. When they could use a variable they don't think "Oh, yes, I can do it by using a variable". They just don't know how to go on. That is why I love Scratch/Snap: they can do very complex things in just 15 hours of lessons only by using images (sprites) whose properties are those visible on the Stage (position, size, etc). They don't have to create and update the values of those properties by themselves, reportertes do that for them.

@bh

I'll see what I can do. :~)

Excellent. Thanks.

@bh

says we don't have to implement that because you can put watchers for the sprite's position on the stage. Which is true, but that fills up a sizable chunk of stage space.

Very true. That is why I'm planning to add this feature to my reduced/upgraded version of Snap I created for my lessons.

@bh

it's best if we behave like Scratch. But we're not consistent about that.

Yes, Snap is sticking to the Scratch 1.4/2.0 set of blocks, and it is slowly departing from Scratch while Scratch keeps adding new blocks or new features. But, at least for now, the distance is still small enough. And, I must say, I appreciate a lot Snap's decision not to remove menus from the list blocks. I would hate having to tell my students that the last item of a list is "ITEM LENGTH OF LIST OF LIST" instead of "ITEM last of LIST". Same for the random "any" item.

@bh

Jens hates CHANGE var BY amount and periodically threatens to remove it.

I hope he won't. But, if he does, I will add it back to my custom Snap. As I did by adding "FOREVER IF" back when it was removed from Scratch. Now, with the new general "WHEN" block, I guess I don't need it anymore.

@bh

So it's a decision each time we add a feature whether we should do it Scratch-style or rely more on reporters than on commands. And I think when clones were brand new we should have only provided a reporter.

I understand that. And, even if it could be unpractical, I would appreciate if these decisions would be discussed with the community. It is not crucial to me: the clear structure of Snap (and the excellent archive of past versions) allows me to recover what I need. But, as Scratch is used by a community, I think the community that is going to love it (or not) should be mote involved in the evolution of Snap.

[bh]

@s_federici

it is slowly departing from Scratch while Scratch keeps adding new blocks or new features.

Actually Jens tries to stay on top of what Scratch is doing.

@s_federici

I would appreciate if these decisions would be discussed with the community.

Yes. It's not clear how to do that, though; the forum crowd isn't typical of the user community. We've tried to keep people informed at Snap!Con, but that's not representative of the entire community either. We post on the BJC teachers forum, too. And Jens is always talking with German teachers. The trouble is that all these sub-communities pull us in different directions.

Some of our (BJC) teachers would prefer that Snap! not change at all. They say kids get confused if what they see online isn't exactly what's on the curriculum page. It was a big deal with the list icon changed; we had to redo a lot of pictures.

[ego-lay_atman-bay]

I just wanted to point this out, I think the change [var] by block makes sense to keep, since a lot of programming languages have a similar thing. You can add a value to a variable using +=. For example, var foo += 1 just changes foo by 1. Of course they also support -=, *= and /= (I think?).

[snapenilk]

@ego-lay_atman-bay

var foo += 1

I don't think that will work at declaration because the compound assignment operators (+=, -=, *=, /=, %=, **=, etc.) use the value that the variable has before the operation, but it doesn't have a value at declaration.

@ego-lay_atman-bay

they also support -= , *= and /= (I think?)

Yes; additionally:
foo++ and ++foo are short for foo += 1, and foo-- and --foo are short for foo -= 1.
foo++ and foo-- return the value before incrementing/decrementing, and ++foo and --foo return the value after incrementing/decrementing.

[bh]

... Well, okay, here's one. We've recently made the associative functions on numbers variadic, so you can say . In the coming release we extend this to the associative functions on Booleans: .

Dan Garcia (who convinced Jens that the Boolean operators could be done preserving hyperness and lazy evaluation) also wants variadic relational operators (>, ≥, etc.) so you can test whether a set of values is monotonic.

I'm opposed to this change, because is mathematically incoherent, because the range of the relational operators (Booleans) is different from its domain (numbers). If you look at the addition example above, it's done by repeatedly adding one part then another:

1. 9+4 ➞ 13.
2. 13+7 ➞ 20.
3. 20+0 ➞ 20.
4. 20+7 ➞ 27.

(Never mind if it folds left or right; that's not important for this discussion, because the operation + has numbers as both its domain and its range, and the operation is associative. Those are the preconditions for accumulating partial results.)

Now think about the < example. You compute 7<8 ➞ True. Then you try True<1 ➞ domain mismatch. Unlike 7+8+1, which means (7+8)+1 -- the same operation cascaded pairwise -- 7<8<1 means (7<8) AND (8<1). Since the < function moves from numbers to Booleans, the further combination can't be done with <, but only with a Boolean operator, in this case AND. So it's not a proper extension of the < function to multiple operands.

To trained adult mathematicians, that's okay. They look at a chain of < symbols and automatically insert the missing AND functions, because they see that all the time in proofs: "If a<x<b ..." But to a kid, who's just been taught that a+b+c means (a+b)+c, and maybe even has recently been taught the associative law
∀a,b,c: (a+b)+c = a+(b+c)
it's easy to generalize that notation incorrectly to (a<b)<c, which is meaningless.

So, I'm reluctant to extend variadicness to the relational operators. Weigh in, community, with the understanding that we'll take what you say as advice, not votes; you have to give an argument for doing whatever you suggest.

(P.S. Sorry, I'm backing up in the discussion, because I fell asleep in the middle of writing this!)

[ego-lay_atman-bay]

@snapenilk

I don't think that will work at declaration because the compound assignment operators (+=, -=, *=, /=, %=, **=, etc.) use the value that the variable has before the operation

You're right, I just wasn't thinking too much about it, but the general idea is the same.