Paste a Sprite on another Sprite

[bh]

@ddekany

I still don't see what class of use cases justified adding the "cut" and "paste" blocks though.

Have a look at the "Cut and Paste" collection. We solicited projects and several users produced some.

@ddekany

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.

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.

[ddekany]

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.