Oh, that is still very much a thing to this day. There are many scratch 3.0 mods that add tons of completely unnecessary blocks. I love snap, because it knows what users really need, and doesn't throw hundreds of unnecessary blocks at you (although I can't say the same for custom block collections people used to make).
The great thing is that I can open someone's collection of 100 blocks and extract the two I really like, for my own collection. :~)
Thank you. It's because Jens spent his youth sitting at the feet of John Maloney, and I spent mine sitting at the feet of John McCarthy.
I confused "this block" with "this block script".
By the way, "block" can have different meanings, so if you use them for the classic stacking, jigsaw-like blocks (such as [scratchblocks]move (10) steps[/scratchblocks]), calling them "command" might be better, because it is already done in some parts of the UI (custom block creator, etc)
"convert predicate to hat" is unnecessary if it just triggers when it is true because can't the block [scratchblocks]when <>::control hat[/scratchblocks] do the job?
I don't think "when stop sign clicked" predicate will be seen outside of extraordinary use cases or bugged projects. Click the stop sign, too late, all scripts with that block are stopped, can't detect it.
The "when pause button clicked"? It just pauses, how will scripts be supposed to move on and handle the predicate? Does it work again when unpaused?
"when stop sign clicked" hat already exists in Snap! under "when I am stopped", albeit scripts are limited to one frame or instant. Any longer scripts will be stopped.
"start all" already exists again. Get a broadcast block and there is a green flag broadcast.
I like these concepts, but some are unfitting. Also some of my reasoning wasn't sounding great at all.
oh... can we atleast add custom hat blocks, ringed hat blocks and hats in the block editor, but only add the 'run this hat' and 'stop running this hat' blocks
Maybe. Not gonna do the design work in the forum. Maybe we'll announce a beta if we want users' comments at that stage.
ok. same thing for caps?
I really like this idea! Also, @ego-lay_atman-bay & @bh, why are you two hating on scratch mods that add a lot of blocks? I mean, if I were making a Scratch mod, I would probably add blocks too, but I do kinda get it, it's just that it sounds like a lot of hate.
I'm just saying, I've seen a lot of scratch mods that add useless blocks, like go backward (10) steps, move right, stuff that can super easily be created by the user.
"Useless"? Well, I guess that depends. Of course, the "useless" blocks could've been combined with their "vanilla" counterparts via dropdowns.
I thought having a lot of blocks wasn't that bad but now that you mention what blocks they actually add there's a good reason to hate these mods. It seems like they just need extra blocks so that they can say they have more than other mods instead of actually making useful blocks.
Not all mods that add a bunch of blocks is bad though. I was looking through penguinemod, and there's not a whole lot of blocks that were added that are unnecessary. Turbowarp is also a really good mod, as all the added blocks are hidden in extensions, and when loaded, it will warn the user how the project won't be compatible with scratch. I can't exactly remember which mods add tons of unnecessary blocks, but I know I've seen them before.
I was going to mention Turbowarp, but you did it before I could.
I see.
Umm. That's a purely cosmetic feature; we haven't felt the need for it, in custom blocks. It does have a self-documenting aspect, so I guess not completely useless; Jens went to the trouble of making the STOP primitive change its shape depending on which option you choose in its menu. But it'd be well below the When Things Slow Down™ priority level.
"Hating" is a strong word. (I know, it's a figure of speech, but still, it's not how I feel.) If you want to add a lot of blocks in a library or an extension you build, go for it. But in our design process, our rule is, the fewer blocks we add, the better.
(Having said that, I humbly submit that our eight-block Scratch mod has changed the world more than all those zillion-block mods put together.)
It's not always easy to know how to apply that rule. I'm not convinced, for example, about that ludicrously long menu in the LENGTH block, including things that imho should really be separate blocks. I mean, LENGTH, RANK, and DIMENSIONS are kind of related; they're measures of the size of a list structure. I can see putting them in one block. But DISTRIBUTION? Maybe that goes with SORTED and UNIQUES, but I think even that's a stretch. And certainly the ones below the line have nothing to do with the others, as the line kinda acknowledges.
The trouble with stuffing things into a menu is that it hurts discoverability. I bet you can count on your fingers the number of users who know there's a DISTRIBUTION primitive. Fingers and toes, maybe, although note that I said "users," so Jens et al. don't count.
The reductio ad absurdum of minimizing the number of blocks is that, given the new PRIMITIVE primitive, we could make that the only primitive block! Clearly that would hurt usability. But there's also a reductio ad absurdum in the other direction: We could turn all the libraries into primitives. Those are all blocks we consider useful; none of them fall into @ego-lay_atman-bay's objection to trivial blocks. But, try the experiment of loading all the libraries into a Snap! instance and then try to find anything in the palette.
I'm afraid Aristotle had it right: virtues are located somewhere between extremes. You learn exactly where through a lot of practice.
Just load the scisnap library and you'll have a hard time finding anything.
Now, I'm not saying the scisnap library has too many blocks, heck I have a feeling all the blocks serve a purpose (no redundant blocks), I'm just saying that the library is pretty large.
At least he added a lot of categories. That helps. But yeah, I certainly don't always know that something I want is in that library.
If we add open-and-close-able subcategories, which I'm hoping we will in the not too distant future, it'll help a lot, for SciSnap! as well as for Snap! itself.
So Will there be a category with the ‘Variables’, ‘Lists’ and ‘Other’ subcategories?
I guess that's possible. Personally I'd make them separate categories altogether. First class lists (as opposed to Scratch lists) have nothing to do with variables.
ok