Oh.
Yeah, those are examples of text that I think could be misunderstood as calling for mutation of the input.
Once you understand a little about functional programming, it should be clear that reporters don't mutate, until you take data structures and write
But, again, newbies...
Think about the notation foo++ in C. It returns a value, but it also changes what's in the variable.
I like this one!
So, is it like a rising-edge monostable gate?
When beginners learn snap, they learn about booleans, and they learn that if something is true, something happens. If you say "WHILE <> IS TRUE", that's pretty much dumbing down to a level that beginners get past on their first day. If they can learn what if <> {
} and repeat until <> {
} do, then they can figure out what while <> :: control hat does without needing us to tell them the following blocks repeat while <> is true, but doesn't while it's false :: control hat Plus, I feel like some beginners may think that snap assumes everyone who uses it is dumb, and can't remember how a block functions. I know that some kids like hard things, because they have a much bigger sense of accomplishment then if they were coding in a language that is extremely descriptive with every single block.
Basically I'm saying that WHILE <> REMAINS TRUE is a little absurd, since beginners should learn about other similar blocks, and are able to use that knowledge to figure out what other blocks do.
Edit: another thought is, the boolean slot is the "IS TRUE" text.
I kind of like it, since I believe that's a better name for snap.
How, What would that look like?
The boolean slot should indicate that the value is one of two values, and "while" indicates that it should be true.
Beginners will (or should) understand that WHILE wants True rather than False, yes. But I don't think it's obvious that the block keeps firing (especially since that's what WHEN used to mean!). It's obvious in the C-shaped WHILE, because users know that loop blocks loop (especially given the little arrow as a hint). But I don't think it's obvious in the context of a hat block.
You're focusing on each block separately, and yes, in that context, putting TRUE in its name is redundant. You're thinking that users will think that the TRUE is opposed to FALSE, which is why I like it better with REMAINS. But I think you're not seeing what happens when they're adjacent in the palette:
Not only does that clarify the distinction between WHEN and WHILE, but it also teaches what the ∞ means.
I Still Think the remains true part is a bit unnecessary, Since that’s literally what While means.
Maybe you'd like this better?
It may just be me, but that kind of distinction is the kind of thing help text should clarify.
$$\text{I.M.A.O}$$, Once someone learns the distinction, the longer name ends up just using up more mental bandwidth.
Me too..
But anyway, replying to bh’s post, I like the becomes true wording and how it’s similar to the while wording, but I also agree with @bluebaritone21, we should have a short block name like with the MAP example, but have help text.
IMPORTANT:
Also, I feel that with the lack of infinity sign on not-Infinity rule blocks, It sort of implies that The condition is not always being checked. Any thoughts?
I suppose. I worry that they won't know they need help and so won't learn the distinction. But having both WHEN and WHILE as adjacent primitives would help a lot, and might get them to read the help text. So okay, I concede, even though I still like my way better.
Yeah, maybe with the SPACE ABOVE option checked too to know these blocks are similar but not the same as the rest and also repeatedly check a condition.
If you bring the infinity sign into question, I feel like that also indicates that the script runs infinitely vs once.
I do have a thought, that maybe you're thinking beginners are dumber than they actually are. Sure, 9 year olds may not understand the difference very well, but teenagers, which, if I recall correctly, is the main target for snap, would understand the difference very quickly.
Programming is all about problem solving, if you can't do that, then you're probably not cut out to be a programmer. This also extends to block names. If you don't know how to experiment and figure out what a block does, then maybe you need to learn how to do that. I feel like that's more important than trying to teach absolute beginners more advanced concepts before they know the basics. If they know the basics, then they will be able to figure out the more advanced stuff. It's all about the building blocks.
Well, maybe you're right. But hat blocks aren't "more advanced stuff"; even Scratch has hat blocks. :~) Remember, what started this whole discussion was Jens pointing out that in his experience everyone hits bugs because they're confused about whether WHEN means an event or a rule/condition. We are taking as given that this is a problem worth helping them with. (Actually, "we" here means everyone but me; I suggested, and still think, that this kind of bug -- one that's about something -- is a good learning opportunity.) So the question is, given a user who has no clue about events versus conditions, how to make that discoverable.
Personally, I’m not concerned about
Because of the experimentation and help screens which solve your problem, but I do understand.
Help screen + manual. Maybe we could have users contribute to the manual, maybe just in a forum topic, with you or Jens editing it ?
We're working on converting the manual to something like markup and then making a repo for it to which people could file PRs. I'm a little scared about this because in my heart of hearts I don't think anyone can write except me. ;~) But we'll see how this goes. (The "we" who are doing this work are Michael Ball and Victoria Phelps at Berkeley.)
I finally understand CLICKED vs. PRESSED, by the way. PRESSED fires as soon as you push the mouse button down. CLICKED doesn't fire until you release the button, and then only if you haven't dragged the sprite. DROPPED fires when you let go of the button, if you have dragged the sprite. So they're all events, not rules.
Actually I don't remember that, since it doesn't seem like jens has said anything along those lines in this topic. In fact, now that I'm going back, it sounded like your initial reply was replying to something you guys talked about internally.
That's what I also think, and am arguing for.
According to you, that’s how Jens feels about snap…