For example, in older versions of Snap! one could load a library and click edit on the map block and see:
This was pedagogically and practically important. One could learn Snap! programming by looking at how it could have been implemented and if one is trying to define some variant this could be a good place to start.
Yes, our plan is to have an "Edit" option for primitives that could be written in Snap!, and when you open it, you get code with a transformed name, something like .MAP or whatever, so that editing doesn't delete the fast version.
Couldn't all of the blocks be rewritten?
I'm probably not understanding what you mean, but I'll try and we'll see...
Imagine the Snap! editor, but with no primitive blocks at all. Now you want to write, I don't know, MOVE ( ) STEPS. You click Make a Block, fire up a Block Editor, and... then what? If nothing is primitive, what are you going to drag into the definition?
Maybe you meant, "if we take Snap! and just delete one primitive, couldn't we always find a way to define it in terms of the others?" And the answer is yes, in principle, as long as you have Ringify and you have the CALL block, you can compute any function.
(User interface things are less amenable to redefinition. How are you going to implement SHOW VARIABLE, for example? Stage watchers aren't first class data, so it's not easy. I guess you could use the new first class costumes stuff to draw a watcher, pixel by pixel, but you wouldn't want to.)
Even for functions, though, you really don't want to have to define trig functions, for example, starting with nothing but lambda.
If the only blocks left were these, then you would be able to recreate all the others:
Well yes, but that's sort of cheating. The original context of this thread was talking about the pedagogic virtue to seeing things like MAP written in terms of "more primitive" primitives. There's nothing particularly pedagogic about seeing the Javascript implementation.
I agree that there is much less pedagogic value in seeing the JavaScript but I think for some users there is some value. On a perhaps only related topic, is there any performance disadvantage to blocks defined by JavaScript functions and those defined in the Snap! source code?
I recall a large project Alan Kay was doing where everything could be edited even if it meant getting into successively lower-level computational constructs that were harder to understand. Could all primitives be implemented as JavaScript blocks without a performance hit?
There's a tiny cost, because each procedure call becomes two calls, one to the Snap! wrapper and one to the underlying JS code. I don't know whether it'd be noticeable. More problematic is that it's tricky for JS code to call Snap! code; we can do it, as in the new primitive HOFs, but it would be a pain to do it for every call from one primitive to another.