haha, that's pretty neat! 
Now you see what means 'fast' 
1-3 ms per hole!
Well, duh, it's a primitive, of course it's fast. The question is whether this warrants / justifies inclusion in Snap! Speed is always nice, but every special case also takes away a learning experience and a whole range of project ideas (it does open up others).
Ah, that's what you are thinking about! That users will became lazy to implement their own ideas!
There is an anecdote about russian army:
An officer orders a private to go take a crowbar and sweep the barracks.
"But how can I sweep anything with crowbar!?" he replies. Officier: "I don't want barracks to be clean. I just want you to suffer."
Please do not be offended, that's just a joke. I so much appreciate your everyday efforts to make Snap! better. But I really do not understand how such a nice feature (that can be placed to external library) can damage user experience.
Very nice work @dardoro
I've made a small change and added a menu to make it easier for muggles like me to use
Thx, it's more convenient this way 
Nice! You can also make the drop-down menu read-only.
I checked that the performance degradation of "switch to costume" is caused by string literal in one of the pixel elements.
So to get a more consistent result, operation on pixels must enforce numeric values.
Simplest test case: https://snap.berkeley.edu/snap/snap.html#present:Username=dardoro&ProjectName=pixelPerf&editMode
:
This is a big question that we've been struggling with from the beginning. The fact that in Snap! you can write
is such a fantastic learning opportunity! As a teacher (or a curriculum writer -- we do this in BJC) you can lead up to this through examples that build in a particular function:
After you write two or three of those, you're ready to learn the -- not hard exactly, but needing to be taught, not intuitively obvious -- parts, namely, declaring an input to be of type Reporter, and then using the CALL block to call it.
So this argues for not providing students with MAP. But the argument on the other side is that MAP is so very useful, it seems like child abuse not to make it available from the very beginning of the course.
There are also concerns about efficiency, etc. But those are secondary to the pedagogic issue.
Oh, yes, you are right! And it's just funny: performance degrades if I do this:
But it runs very fast and doesn't degrade if I do:
Thank you for your efforts!
Fantastic learning capabilities of Snap! are beyond all doubts 
The same argument I give when ask to enhance capabilities of PASTE ON block
But I see, we are on different sides... You - creators of Snap! - are teachers first, and I am an expirienced programmer who doesn't need to study anything but just want to make fast and good looking apps simply without reinventing the wheel...
And one more thing about studying. You surely know there are different kinds of beauty. More precisely there is a beauty of the solution itself and a beauty of the result. For example, cymplecy, Bernat and Jens here proposed several approaches to my initial problem with transparent holes. And these approaches are all good! But they are good as solutions, as algorithms and not so good when we talk about their results. Yes, it solves the problem, but these solutions are slow and have visual artifacts (like flickering and green border around holes). Yes, we still can see beauty and elegance in them (and as a matematician I appreciate it too), but for students it may be not so inspiring. Because they may have not yet developed this kind of sense of beauty That's why IMHO the really inspiring thing for student is when his beautiful solution leads to beautiful and fast result. Yours captain obvious
I don't get this guys. Why would anyone think "paste" does what it does, and why is this behavior generally useful? If you ask anyone what will happen if I "paste" the image of sprite A on top of the image of sprite B, intuitively they will think that the image of A will just be there on top of the image of B. The chosen behavior, where the alpha channel of B stays is weird.
That you can emulate anything with hyper blocks and such (or not) is irrelevant when you want to introduce programming to beginners.
Anyway, the use case because of which I found this at all is that "stamp" only works on the pen layer, and someone wanted to draw on a layer on top of a sprite. I think that's a quite normal need, to be able to have multiple pen layers. I noticed this "paste" thing, and hoped it will do that, but nope. Yeah, and those blocks has no help either. Also I would call it "stamp on"... Why "paste", when the other one was "stamp"?
Actually, I wonder, if I just want multiple pen layers, maybe it shouldn't be done with sprites on the first place. However, sprites has Z coordinate and such, so maybe it's a good idea to reuse that. I don't know.
Another aspect, the naming of these. "paste" and "cut" are associated with the clipboard in the head of most users. Like "cut", in additionally to remove something, should keep a copy somewhere. But these are really just "stamp on" (with the weirdness regarding the alpha), and "erase". And did I mention, there's no help popup for these (simply nothing happens if I chose "help" - a bug), which adds to the confusion.
Careful -- when I said that to Jens he just yelled at me for days.
Yeah, it's because of the analogy with the clipboard, of course, that Jens likes these names.
About the alpha channel, though, I have to disagree with you, for two reasons, one practical and the other pedagogic. The practical reason is that we already have a different mechanism to do what you want, namely, nesting sprites. You can attach (a clone of, if you want) one sprite to the other, so that from then on, they move together. That pays no attention to the shapes of the sprites; it just glues them together.
The pedagogic reason is that users don't think of sprite costumes as a rectangle (the bounding box) in which some pixels are invisible. They think of the costume as having any shape you want, with all pixels visible. We encourage them to think that way in most of the language; in particular, the TOUCHING predicate considers only the visible pixels of the two sprites (although as an implementation detail it starts by checking whether the bounding boxes intersect). So instead of being like gluing two sprites together, PASTE ON affects only the target sprite, whose shape is determined by its own costume. So even if the block were named STAMP ON, if you apply a rubber stamp to an irregularly shaped surface, that surface doesn't grow; only where the surface exists can the stamp stamp.
Yeah, this part is my fault. I'm in charge of documentation, but it's all I can do to try to keep the manual up to date. Help screens are a pain in the neck. But I'll get to it...
Snap's "Paste" comes from the term "paste up" used by newspapers before desktop publishing took over. The idea is to clip what's pasted-on by the bounds of its surrounding container. The word has a long tradition in Smalltalk (which invented the GUI and thereby DTP ^^).
What we have to remember - this is @jens toy and what he says goes - even when he's completely wrong #joke
But the great advantage of Snap! is that we can create almost any function ourselves and call it what we like.
I've already taken @dardoro excellent block and modified it a bit but it could easily be further modified/expanded and the named changed from paste on to something else
Nesting sprites doesn't work well for the use case I tried to tackle, which is painting (or stamping) on sprite. You would end up with hundreds of mostly overlapping sprites in no time with that approach. Anyway, what I was looking for is more like multiple pen layers, which can be behind or in front of sprites. I thought this feature will be good for that, but it turns out it wasn't. I still don't see what class of use cases justified adding the "cut" and "paste" blocks though.
(As of "touching", that also happens to be an unfortunate name. It's actually should be "overlaps".)
His toy... that's a common fallacy. You have put a smiley there, yes, but still. Also, I don't know if it applies to Jens. I don't know him at all. But, saying that "he's entitled to do whatever he wants" because it's his creation, is a bit like saying "he is entitled to ruin the potential of his own hard work". Which is true, but, I mean, who wants such thing to happen? Again, I'm not sure if it's applicable here, it's just the "his toy" reasoning.
As of we can create almost all functionality ourselves. Yes (I guess), and that's good thing. But the better situation would be if there are fewer, more understandable (more intuitive) stock blocks, which, however, are good building elements to achieve stuff that feels kind of basic. In this example, I fail to see how these block satisfy that criteria. Maybe they do, I don't know. It's just that creating custom blocks is irrelevant in that discussion. Think of new users. What their first impression will be? Will they stay, or think this is too confusing (for kids), and, I don't know, maybe let's use Scratch or MS Arcade, etc. instead.
Have a look at the "Cut and Paste" collection. We solicited projects and several users produced some.
Yes, that was our policy when we first built BYOB, the predecessor of Snap!. We added all of eight blocks to Scratch, implementing first class procedures (lambda and apply) and first class lists (cons, car, and cdr). The higher order functions were in a library, written in Snap! itself.
That minimal approach works well for toy computation, teaching principles on small amounts of data. But once you're doing media computation, you have huge lists of pixels and you have to be able to do computation on them at speed. Also, people have started wanting to teach data science, importing large public data sets to query. So we needed the HOFs to be fast, and we needed new blocks to support first class costumes and sounds. I think Jens regrets the necessity, and I know I do, because we both agree about keeping the block palette small.
But I'm not sure I believe the argument about confusing kids. When Scratch added lists way back in version 1.4 (or maybe 1.3? Before my time.) they worried that kids might find lists confusing. And, indeed, Scratch newbies don't use lists. But they just ignore the list blocks at first; they don't give up on Scratch because of them. And so eventually they do learn how to use lists, by reading other kids' projects.
We've talked about hiding some groups of blocks behind right-facing arrowheads that you click to turn them into down-facing arrowheads and a bunch of related blocks. That might be a good way to meet everyone's needs.
But the other thing to remember is that most of our users don't just discover Snap! at random; they are students in classes that use Snap!, and then after the class some of them stay with Snap! for fun. So they are supported by teachers in learning some of the complexity. And they have the MOOCs that Jens and Jadga have made, specifically about media computation.
And there's a lot of complexity we could have added but didn't. JavaScript graphics primitives include "draw a circle," "draw a rectangle," "draw a polygon," and so on. Those don't have corresponding Snap! primitives.
But think of people, form outside Berkley. People who look for an alternative to Scratch because of its odd limitations and quirks. (Very few will look for doing "media computation" in these jigsaw languages, I think.) What will their first impressions will be, and of the people who they want to teach. I think Snap! could do significantly better there with relatively small investment.
Too many strange puzzles shown by default is certainly a bad strategy there. Maybe, make Libraries more visible in the UI, and put the more specialized puzzles there.
Of course there are other issues too, maybe even more impactful ones. Like, the UI design is not good. It's way harder to comprehend what does what than it could be. Name choices are sometimes not good either, and names matter a lot. Seems these don't get their share of attention that they deserve.
There's also a suspected animosity towards how things in the industry work (how OOP works there in particular), which, I guess, yielded these weird things like injecting code into another "sprite" to access its private state ("tell" and "ask"). But, that's certainly religious territory, and surely had their own topics, so, no much hope to improve adoption there.