Seriously, what does the primitive [ V] <t> block do? Even it's definition is a primitive [doPrimitive V] <t> block (that should lead to an endless loop imo)
And if it comes from the source, where do all the options come from? Are they hardcoded?
I'm confused over here.
primitive [doConfusion V] <t>
It's for the blocks all the way down setting. Some blocks can be written in Snap!, but the primitive (done when the Boolean is true) is faster than writing the block in Snap (done when the Boolean is false).
What's the point of the boolean?
Since the beginning of time, back with BYOB, there's been a tension between our teaching mission, which is all about letting users build their own tools, and speed, for which we build the tools in Javascript (in Smalltalk, back then). In BYOB, which was never going to be the fastest language on Earth anyway, and also back when we were hoping to convince the Scratch Team to adopt our ideas so we wanted a minimum of necessary primitives, we always chose pedagogy over speed. We were super proud—still are super proud—that we could build a FOR loop in blocks.
Even in "grownup" text languages, you can't write something like FOR yourself, because it can't just be a procedure call; it has to be a special piece of syntax.
Then Snap! came along and was starting to be fast enough to do real work, and in particular Jens got interested in media computation, which requires handling large lists, and so we regretfully started recoding some of those tools as primitives. But right from the beginning I made up the name "hybrid primitives" meaning blocks that ran as primitives, but you could say Edit in their context menus and get a definition in Snap! code in a Block Editor. At that time I was thinking that doing so would make it stop being a primitive.
Well, it turns out that back in his Smalltalk days Jens had learned to say "Smalltalk all the way down," meaning that Smalltalk was (almost) entirely written in Smalltalk itself, which is how a different design group thought about the same idea, except their goal was that the Smalltalk interpreter would be fast enough that they wouldn't have to choose between speed and pedagogy.
So, the PRIMITIVE block with its Boolean flag is the way we've ended up having our cake and eating it too. You can edit a primitive, modify its code, experiment with the modified version, and flip back to the primitive version when you need it to run fast.
One problem with the primitive block is that you can't modify a block that only has a javascript definition, such as stop all sounds, which results in you not being able to add axtra functionality to one of those blocks without having to create a custom block that runs the original javascript definition.
Its
<t> primitive [ V]
Right?
Yeah, over time more and more primitives will have Snap! equivalents. But there will always be an irreducible core. If nothing else, allocating a chunk of heap memory.
The problem is when you want to add additional behavior to a javascript only block, such as if you want to transform the inputs of a block.
For example, if someone is creating a camera based project, they could modify the go to [ V] block to transform the positions of all movement blocks to be based off of the camera instead of the stage (because currently that block is a javascript only block). The problem right now, is that you can't transform the value, and still have it run the original javascript function.
No, I get it, what you want is like the SUPER or USUAL notation in OOP languages to let a child's method run the parent's method. Maybe there should be a variant version of the PRIMITIVE block that doesn't have the Boolean input and can be used anywhere.
Indeed, the same issue arises in our OOP system. A child's method ("for this sprite only" block) should be able to invoke its parent's method. And TELL (MY PARENT) [METHOD] won't do, because you want to use the child's local variables and attributes such as POSITION, not the parent's.
In a perfect world, we could use the same notation to solve both problems.
I just want to say, this is the reason I love Snap, I code in python but I end up hitting road blocks where I want to make my own function that run inputted code, but python has no support for that. In other words, I always find myself back on Snap code with blocks.
It does. You can pass lambdas (which aren't very good), or functions (without the parenthesis), and then call it in the function as if the parameter is a function.
def hello():
return "Hello"
def world(fun):
print(fun(), "world")
world(hello) # Hello world
world(lambda : "nice") # nice world
You may want to go search this stuff up.
Ok I was wrong, but still I love Snap.
(thank you I didn't know that (but that's do to the fact I code in snap so much))
We learn from eachother, innit? 
Yes, yes we can. That's what the forum is for.
That's what I'm saying 
The prefect solution
(yes, it is creating a block)
Those images are script pics, so you can drag them into the editor and use them.
@jens Since you don't believe anyone but me is bothered by NUMBERS FROM counting backward, please read the code just above.
Well there is just no way to have that block return an empty list.
You do what you have to do. (but I do prefer a range function like In python)
Yeah I dig it, that's my point. NUMBERS (and also FOR) should count up rather than down. Since it's too late to do that without breaking projects, it should have a menu input with choices TO and UP TO. And UP TO should be the default in the palette. (Note, I was talking to Jens, not really to you.)
Oh my, I was so worried when you said
I thought you were talking about me.
