The Scratch Wiki says that broadcasting messages helps reducing lag for Scratch. Is that the case for Snap!, too?
While I haven't look into the source nor don't work on it, maybe?
It's more likely since if you do other stuff, it can cause more memory than just broadcasting, so since Snap is trying to act like Scratch with its own thing, my best guess is could be true. Maybe check it for yourself by trying different things and checking the memory with programs.
I don't think so. Snap has everything? first class, and scratch doesn't.
Well, I mean by that is saying it's more inspirited.
oh, ok
Compared to what? I'm not sure what this means.
Compared to the when green flag clicked block.
Probably it's a comparison between broadcast and multiple forever loop (for each sprite) waiting for the semaphore (shared variable change).
Ah, I see. That makes sense for software-generated conditions. I was trying to understand it as applying to hardware things such as mouse clicks. Yes, of course a broadcast by the code that causes the condition to occur eliminates wait loops. It doesn't solve all problems, e.g., a script that's running forever doing lots of things but also needing to know when this situation arises (the player has won or lost the game, let's say) isn't helped by a broadcast because it's already running.