bharvey wrote:

(snip snip)

Really you should think of the tools as meaning "blocks you should think of as primitive but Brian hasn't convinced Jens to include as actual primitives yet."

I do think of them as "primitives that Brian haven't, yet, convinced Jens to include as actual primitive“ blocks. Maybe I am wrong, but the sole reason for suggesting to rename it ”Advanced Blocks/Primitives" is that there must be a line drawn somewhere, however arbitrary it is, between a beginner user (or an ordinary user, if you wish) and an advanced user, I guess. Even if you disagree, you will probably agree that it is not (pedagogically) nice to overwhelm a beginner with too many primitives at once, so you need to draw a line between ordinary primitives and advanced primitives, I guess, and call them differently, albeit they are all primitives, just for the sake of not overwhelming beginners.

scratchmouse wrote:

there must be a line drawn somewhere, however arbitrary it is, between a beginner user (or an ordinary user, if you wish) and an advanced user, I guess. Even if you disagree, you will probably agree that it is not (pedagogically) nice to overwhelm a beginner with too many primitives at once, so you need to draw a line between ordinary primitives and advanced primitives, I guess, and call them differently, albeit they are all primitives, just for the sake of not overwhelming beginners.

At that level of abstraction, the general idea sounds good. But it breaks down when applied to the specifics of Snap! and its tools library, I believe.

For example, probably the very most “advanced user” blocks are the RUN/CALL W/CONTINUATION ones in Control. Only 12-year-olds can learn them. But they're primitives, not Tools, because you can't write them in Snap!. (Yes, you can with JS Function. I'm not considering that "writing in Snap!.") At the other extreme, FOR, in Tools, is a piece of built-in syntax in most languages, and nobody thinks beginners can't use it. But you can write it in Snap!.

It isn't even just a linear difficulty scale. Take ASK and TELL, in Tools. The whole idea of inter-sprite communication is, not super advanced, but maybe not first-day stuff. But the way such communication works in Snap!, generalizing the OF block we inherited from Scratch, is a little convoluted; ASK and TELL are syntactic sugar based on OF, providing a simpler notation for the same idea.

Also, I'm not convinced that “too many primitives” is the right metric. If it were, we (and Scratch) wouldn't have CHANGE (var) BY (delta), which is trivially implementable with SET and +. The right metric is to try to make hard but popular capabilities easy, e.g., by providing IF ON EDGE, BOUNCE. That, to an advanced user, just begs to be refactored into an ON EDGE predicate and a BOUNCE command. Except that it's not clear what BOUNCE would mean if you're not on an edge.

But I'm guessing that our fundamental disagreement isn't about the theory of pedagogy at all. It's that you think that

is easy, while

is hard, whereas I think it's the other way around.

P.S. You and the College Board, but don't get me started on that.

But I'm guessing that our fundamental disagreement isn't about the theory of pedagogy at all. It's that you think that… <SNIP SNIP> is easy, while

is hard, whereas I think it's the other way around.
P.S. You and the College Board, but don't get me started on that.

I am willing (as opposed to bureaucrats from College Board) to learn how people, who are much smarter than me, see things. Which puts me in a slightly different basket, hopefully.

I'd like to “re-make/re-word” some blocks that are not simple for not-very-smart kids/adults, like me, so that maybe they would be able to see it the way really smart kids/adults, like you, see them. For example, it has not been until very recently clear at all to me in case of your example that those empty slots are really there waiting to be filled by items (all of them, one by one) from the list named “data”. I can almost hear you saying that this is stupid, and I agree.

To me and other not very smart adults, such as those from College Board, there is from the existing wording “MAP ( ) OVER ( )” just not as clear as it would be in case of a re-worded version of “MAP ( ) OVER ITEMS OF ( )”. I imagine an arrow that goes (in the re-worded version from the “ITEMS” part of the MAP OVER block) all the way to those empty slots - and voila suddenly what to my mind appeared an uncomprehensible mysteriousness of the MAP OVER is over (pun intended) for me.

It even appears simpler than the previously seemingly simpler (loop) version. Wow. As you said. If the stupid bureaucrats from College Board are as stupid as me, they need to picture those arrows and they will be able to see it as simpler the way you always have and I am now finally able to see, too.

For example, probably the very most “advanced user” blocks are the RUN/CALL W/CONTINUATION ones in Control. Only 12-year-olds can learn them. But they're primitives, not Tools, because you can't write them in Snap!.

Although after what you wrote I am not sure anymore, but I thought your criterion seemed to be "not being able to make the tool in Snap!, using only existing primitives", thus defined from the point of view of building the blocks, while mine seemed to be defined from the point of view of, maybe not difficulty of use, but user experiences. Any way, it doesn't seem very important to me now, anymore. More important is that I now am able to understand the blocks using those imaginary arrows.

It isn't even just a linear difficulty scale. Take ASK and TELL, in Tools. The whole idea of inter-sprite communication is, not super advanced, but maybe not first-day stuff.

Despite me not being very smart at all, I have been able to use ASK block for inter-sprite communication recently - with some help I received at the Snap!'s GitHub Issues - and my little color shooter game works as intended. Additionally, using the imaginary arrows mentioned with MAP OVER now I understood yet another block - the KEEP ITEMS SUCH THAT ( ) FROM ( ) block - and I have used it, instead of a loop that was there in my game (as shown below in screen picture), because it is simpler. You can notice arrows similar to those I imagine in a re-worded MAP ( ) OVER ITEMS OF ( ) block. The white arrows going from “items” to the empty slots:

But the way such communication works in Snap!, generalizing the OF block we inherited from Scratch, is a little convoluted; ASK and TELL are syntactic sugar based on OF, providing a simpler notation for the same idea.

I never thought of the ASK and TELL blocks as syntactic sugar on top of OF block. It's interesting to view it that way. Because, to be honest, both blocks (i.e. ASK and TELL) used to appear as incomprehensible as MAP OVER block to me.

At the other extreme, FOR, in Tools, is a piece of built-in syntax in most languages, and nobody thinks beginners can't use it. But you can write it in Snap!.

Also, I'm not convinced that “too many primitives” is the right metric. If it were, we (and Scratch) wouldn't have CHANGE (var) BY (delta), which is trivially implementable with SET and +.

The right metric is to try to make hard but popular capabilities easy, e.g., by providing IF ON EDGE, BOUNCE. That, to an advanced user, just begs to be refactored into an ON EDGE predicate and a BOUNCE command. Except that it's not clear what BOUNCE would mean if you're not on an edge.

I agree. Interesting!

At that level of abstraction, the general idea sounds good. But it breaks down when applied to the specifics of Snap! and its tools library, I believe.

I have a (maybe simple?) question. I can get a black pen by using “set pen shade to 0”. But is there a way of getting a white and a light grey pen by using “set pen color” and “set pen shade”?

s_federici wrote:

I have a (maybe simple?) question. I can get a black pen by using “set pen shade to 0”. But is there a way of getting a white and a light grey pen by using “set pen color” and “set pen shade”?

No, basically. It is a known misfeature that our color system is based on HSV rather than HSL coordinates. We even have a pull request (thanks, Joan!) that we'll get around to when things slow down.

Meanwhile I think you should use the crayon library (“Provide 100 selected colors”), or maybe the RGB library (“Set RGB or HSV pen colors”).

scratchmouse wrote:

I can almost hear you saying that this is stupid, and I agree.

No, I hope I wouldn't say that! Good teachers don't have words like “stupid” in their vocabularies, except maybe in contexts such as "It was really stupid of me to…" Even the College Board people (and the ones who wrote the curriculum are CS professors, not bureaucrats) aren't exactly stupid; they just grew up in imperative programming languages and therefore have bad instincts about what's easy and hard.

there is from the existing wording “MAP ( ) OVER ( )” just not as clear as it would be in case of a re-worded version of “MAP ( ) OVER ITEMS OF ( )”.

That's an interesting idea. For KEEP and COMBINE we managed to come up with common-language wordings to replace the standard technical ones (FILTER and ACCUMULATE respectively), but I've been unable (for decades!) to come up with a wording for MAP that doesn't suggest mutating the input list. “Map over items of” would, I agree, be better for beginners, but would be confusing to people familiar with the mathematical meaning of “map.” I can make really long ones, like VALUES OF FUNCTION ( ) OF ITEMS OF ( ), or, even better but longer, VALUES OF FUNCTION ( ) APPLIED TO ITEMS OF ( ).

I never thought of the ASK and TELL blocks as syntactic sugar on top of OF block. It's interesting to view it that way. Because, to be honest, both blocks (i.e. ASK and TELL) used to appear as incomprehensible as MAP OVER block to me.

Really? I'd like to hear more about that. The metaphor of ASK and TELL seems pretty straightforward to me; there are these different actors (sprites) onstage and they talk to each other as people do, ASKing each other questions and TELLing each other to do things.

So, in our defense, we do explain all these blocks in three ways: the Help windows, the Snap! Reference Manual, and also in our Beauty and Joy of Computing curriculum. Click on the Snap! icon in the top left corner of the window and you'll see an option to download the Reference Manual. That's where to go if the Help window doesn't explain the block to you – but it sounds to me as if the Help window should have been enough for you!

Ok, related to this discussion – I have another question – the list HOFs: Why do we all think ‘map’ is the best name for that action? (Python and JS and some Lisps have different names than Snap!'s KEEP and COMBINE, but MAP is consistent.) Personally, given the syntax of Snap!'s MAP, I think apply would make a little more sense, but I can't say why.

bharvey wrote:

I think you should use the crayon library (“Provide 100 selected colors”), or maybe the RGB library (“Set RGB or HSV pen colors”).

Thanks a lot Brian. The “set pen color rgb” block worked exaclty as I needed (I often forget how powerful the Javascript block is )

cycomachead wrote:

Why do we all think ‘map’ is the best name for that action? (Python and JS and some Lisps have different names than Snap!'s KEEP and COMBINE, but MAP is consistent.) Personally, given the syntax of Snap!'s MAP, I think apply would make a little more sense, but I can't say why.

Just be glad it's not called MAPCAR, which was the original Lisp name, to distinguish it from (then) MAP, which applied the function to the entire list, then to the entire list minus the first element, etc. Sounds silly but it lets you write things like

using a HOF.

From the beginning, I think, MAP(CAR) was the only official primitive HOF. COMBINE has never been official because of all the subtle choices in writing it: What about empty lists? What about singleton lists? Associate left-to-right or right-to-left? I think FILTER is pretty straightforward; I don't know why (supposing I'm remembering correctly) it wasn't primitive in Lisp 1.4.

APPLY is taken; it's the official name for what we call CALL. (I keep forgetting you didn't take 61A from me.)

cycomachead wrote:

Ok, related to this discussion – I have another question – the list HOFs: Why do we all think ‘map’ is the best name for that action? (Python and JS and some Lisps have different names than Snap!'s KEEP and COMBINE, but MAP is consistent.) Personally, given the syntax of Snap!'s MAP, I think apply would make a little more sense, but I can't say why.

IMO “map” should not be renamed “apply,” but for a different reason than @bharvey. In Haskell, the map operation isn't just for lists, but is generalized into the functor typeclass so that other types, such as Maybe, can be mapped. The applicative typeclass inherits from functor and adds a new operation, written <*> but pronounced “apply.” See https://wiki.haskell.org/Typeclassopedia .

TheAspiringHacker wrote:

IMO “map” should not be renamed “apply,” but for a different reason than @bharvey. […] The applicative typeclass inherits from functor and adds a new operation, written <*> but pronounced “apply.”

After re-reading this a few times, I'm not sure it is a different reason. Even if APPLY's domain and range are a little different in Haskell's more complicated type system, still basically it is using the name “apply” for a function that calls a function with a collection of inputs. Indeed, I doubt that they would have chosen that name to mean something profoundly different from what it means in Lisp and (therefore, I think, historically speaking) in programming language theory generally. (What PL people do, basically, is study how to do a good job of translating other languages into Lisp, except instead of calling it “Lisp” they call it “abstract syntax trees.” But they all know what they mean by that. ).

P.S. … and the point of hairy type inference systems is to do at compile time the error checking that would more naturally be done at runtime, so that the compiled program runs faster and still doesn't have domain/range bugs. The compiled program is therefore in a typed-variable-free plain old Lisp.

P.P.S. This is what old-timers like me mean when we refer to Lisp as God's programming language. In order to run a program in some other language, you first translate it into Lisp; God just programs in Lisp in the first place.

Yeah, I guess so! If we have a type constructor `Id` of kind `* -> *` that returns its argument, `Id` could easily implement Applicative by defining apply as equivalent to function application!

I tried doing this in Haskell, but the type system wouldn't let me. The problem was https://stackoverflow.com/q/4922560/8887578 .


However, the identity monad (which uses newtype) pretty much implements what you describe.

Note that the map function is also defined as function application, so in the case of the identity type constructor, mapping could easily be renamed application. However, with other types, map and apply are different.

bharvey wrote:

I've been unable (for decades!) to come up with a wording for MAP that doesn't suggest mutating the input list. “Map over items of” would, I agree, be better for beginners, but would be confusing to people familiar with the mathematical meaning of “map.”

It seems to me that you set yourself up to an impossible task (is it to or is it for? Excuse me for my English, if what I have just written isn't grammatically correct, since I'm not a native English speaker) trying to satisfy everybody, i.e. beginners AND mathematicians, but I can understand why you don't want to expose yourself to be criticised by mathematically-(in)formed ones, because math is the Queen of Sciences, viewed by all other scientists with this (almost) religious respect for dealing with eternally true statements, the aureola that gets extended to the notation itself that they use to prove them. Even if by doing that this would mean for me to be called names by the Queen servants, I'd rather be serving beginners only.

Really? I'd like to hear more about that. The metaphor of ASK and TELL seems pretty straightforward to me; there are these different actors (sprites) onstage and they talk to each other as people do, ASKing each other questions and TELLing each other to do things.

Until recently, I just haven't found a practical use for them and I thought I can do without them. (And, to be honest, I thought you introduced them just to prove or illustrate some fancy mathematical (or theoretical) (and mysterious) statements/concepts, that I - being a beginner (more than an “advanced user”) - have not been prepared to dive in just yet.)

bharvey wrote:

That's where to go if the Help window doesn't explain the block to you – but it sounds to me as if the Help window should have been enough for you!

I did click on the ASK and TELL block's context menu's Help, but there was none. Also, in the Manual, there's an example for TELL block only (on page 53, where the ASK is mentioned only - in parenthesis):



I would be very honored if you would want to use in contextual Help for ASK block (and/or to include it in next version of the Manual) an example from the inter-clone communication from my game, using ASK block, as shown on the printscreen (click here to be able to zoom-in) below:


It would be a cherry on top, if you would explicitly write on page 55 of the Manual that "a local variable can store multiple copies of itself, one for each clone" as this is not written now explicitly (at least not explicitly enough for a beginner, like me, to easily understand).

scratchmouse wrote:

It would be a cherry on top, if you would explicitly write on page 55 of the Manual that "a local variable can store multiple copies of itself, one for each clone" as this is not written now explicitly (at least not explicitly enough for a beginner, like me, to easily understand).

It would additionally be helpful for beginners if above a local variable's name there would be a counter of its (changed) copies - similar to the way now instances (i.e. clones) above the When I start as a clone block are being counted.

In my game (mentioned above), I'd like to use KIST (Keep Items Such That) block instead of a loop, shown in the printscreen below (that I have been using in my current version of the game).

Will it work as intended?

bharvey wrote:

“Map over items of” would, I agree, be better for beginners
(snip snip)
I can make really long ones, like VALUES OF FUNCTION ( ) OF ITEMS OF ( ), or, even better but longer, VALUES OF FUNCTION ( ) APPLIED TO ITEMS OF ( ).

I agree that your ones would be really accurate, now that I understand what the block does, but as you pointed out yourself - they would be too long for a beginner to be able to grasp quickly what the block in effect does. So, let's not make it too long, please.

I'd be very happy if you - as have agreed that “it would be better for beginners” - would add-in just “ITEMS OF” to re-word the MAP ( ) OVER ( ) block, please.
P.S.
Not because I would think that my initial suggestion is better than anyone else's, that would be evidently stupid of me, it's more because your (longer) ones seem all to have “ITEMS OF” in common.

scratchmouse wrote:

but I can understand why you don't want to expose yourself to be criticised by mathematically-(in)formed ones, because math is the Queen of Sciences, viewed by all other scientists with this (almost) religious respect for dealing with eternally true statements, the aureola that gets extended to the notation itself that they use to prove them.

Oh, come on. The point is, “map” is a bad choice for nonmathematicians regardless of what other words are used along with it, because to a nonmathematician, “map” means a picture of a nation or a continent, which doesn't help at all in understanding what MAP does. Whereas to a mathematician, the “items of” is implied by the word “map” itself, and to add “items of” makes it seem as if the second input has to be a list of lists.

I may think something else tomorrow, but right now I think it should be called CALL ( ) {FOR/WITH/ON} EACH ITEM OF ( ). I'm open to discussion about the choice of preposition, but leaning toward WITH because it seems to me least likely to admit the misunderstanding that the list is mutated.

I did click on the ASK and TELL block's context menu's Help, but there was none.

Sorry, I meant for MAP. But thanks for reminding me about ASK and TELL needing help windows.

a local variable can store multiple copies of itself

I wouldn't use that wording. They are different variables with the same name (unless we are talking about clones that truly share the one local variable of their parent). (Side note for 12-year-olds: Technically, a variable doesn't have a name; it is a box that holds a value. Somewhere outside the variable itself, in an environment frame, there is a binding that holds a name and a variable. This is important in Snap! in the case of an upvar, a variable that is bound to two different names, one inside and one outside the procedure that owns it.) So I would just say that multiple sprites can have local variables with the same name.

In my game (mentioned above), I'd like to use KIST (Keep Items Such That) block instead of a loop, shown in the printscreen below (that I have been using in my current version of the game).

Sure, that should work. IF NOT EMPTY? KEEP…

Sure, that should work. IF NOT EMPTY? KEEP…

Thanks!

The point is, “map” is a bad choice for nonmathematicians regardless of what other words are used along with it, because to a nonmathematician, “map” means a picture of a nation or a continent, which doesn't help at all in understanding what MAP does.

Good point.

I may think something else tomorrow, but right now I think it should be called CALL ( ) {FOR/WITH/ON} EACH ITEM OF ( ). I'm open to discussion about the choice of preposition, but leaning toward WITH because it seems to me least likely to admit the misunderstanding that the list is mutated.

I share your preference. The WITH proposition is the best. ON is most likely to make the wrong impression that the list is mutated by the block, while FOR can be understood either way.

But thanks for reminding me about ASK and TELL needing help windows.

Thanks for using an example from my little game in ASK Help window. (I'm joking. But it would be really cool to see it in your help window.)

They are different variables with the same name (unless we are talking about clones that truly share the one local variable of their parent).

I am talking about clones (sharing the one local variable of their parent).
You are describing it, I think, on page 55 of the Manual:

"If the value of a shared property is changed in the child, then the sharing link is broken, and a new private version is created in that child. (snip snip) ‘Changed’ in this context means using the SET or CHANGE block (…)". (in my previous post, the one about the Manual; if you zoomed-in on the image, there's a printscreen of the page 55 - with highlighted text)

If I understand correctly, if the ‘shared property’ happens to be a local variable, then when it is SET or CHANGEd in a script under ‘When I start as a clone’ block by a clone, then - as you say - “a new private version of the property is created in the child”. Is it then okay to say that it brings into existence the “multiple copies of the local variable” (and those copies/versions can be counted)?
As I have proposed in my photoshopped screenshot in the previous post?

(Side note for 12-year-olds: Technically, a variable doesn't have a name; it is a box that holds a value. Somewhere outside the variable itself, in an environment frame, there is a binding that holds a name and a variable. This is important in Snap! in the case of an upvar, a variable that is bound to two different names, one inside and one outside the procedure that owns it.) So I would just say that multiple sprites can have local variables with the same name.

Interesting. It sounds familiar to me, but I forgot it, if I ever really knew this.

Oh, come on.

I know In my defense I can say that I was afraid you would have no interest in continuing the (unpleasant?) initiative for MAP block re-wording unless I say something like that. (Sorry).

scratchmouse wrote:

If I understand correctly, if the ‘shared property’ happens to be a local variable, then when it is SET or CHANGEd in a script under ‘When I start as a clone’ block by a clone, then - as you say - “a new private version of the property is created in the child”. Is it then okay to say that it brings into existence the “multiple copies of the local variable” (and those copies/versions can be counted)?

No, the situation is not parallel to that count on scripts. That one is counting sprites who are currently running this exact script, not a modified version of it. If we were going to put a count on a sprite-local variable, it would count the sprites that see this exact variable, not sprites that have separated themselves from this variable and have a different variable with the same name. But even that wouldn't really be parallel; the count on the script counts sprites that are running the script right now, not all the sprites that share access to the script. So, inside the script there may be IF (such-and-such) and the condition will be true for some clones but not others, and so the count of sprites in which the script is (still) running will be reduced.