Yeah, I specified old text languages to try to avoid the confusion between metaprogramming and incremental development in an IDE. I think Jens is just about old enough to remember what I mean, but let me spell it out for you.
In the old days, programming language compilers didn't have any kind of editing capability built in. You edited your program in some external program, Emacs or (these days it'd be) TextEdit or Notepad (not a document formatter such as Word), and then ran it through the compiler. So there was no danger of the compiler modifying the program code. (Cf. Kernighan C compiler hack.) It's because of this history that when someone had the idea of combining the compiler with a special-purpose text editor that understands the language's syntax, they had to make up a name for it, "Integrated Development Environment."
The point of macros ("metaprogramming" has too many letters for me to keep typing it) is to extend the language. They let users be their own language designers. Using a macro capability to change the definition of an existing procedure is not what it's really for; it's to make a new syntax. As an analogy, imagine if raw Snap! let you have only one C-shaped slot in a block, but you could write a macro to allow more than one. That'd be inventing a new syntax. (I'm emphasizing syntax because in any reasonable language you can invent new semantics with plain old procedures; no need for macros. But yes, another use for macros is to invent programmatically a family of procedures not involving new syntax.)
What counts as syntax is way more complicated in a visual language than in a text language, whose programs are ultimately just text. Snap! 's macros don't let users define new block shapes, input slot shapes, or shapes period. But those shapes represent categories that can be invented in a text language. Maybe, over a long time, one by one, we'll end up feeling the need to invent macro-like graphics features. Or maybe not.
Indeed, Snap! metaprogramming (the part about letting you create a block) is an example of letting users do programmatically something they could always do in the UI. (The other half, letting you examine a block definition programmatically, isn't an instance of Eisenberg's Law.) But the point of the Law is that everything you can do in the UI should be doable in a program. For example, although Jens loves a programmable equivalent to the "Make a block" button, he hates the whole idea of a programmable equivalent to the "Make a variable" button. ¯\_(ツ)_/¯
I mean, I can see how there might be a few exceptions. Consider password managers, which let you see your saved passwords for different sites. Yeah, there probably shouldn't be a web API to retrieve those passwords programmatically. Maybe there are a few such exceptions for Snap!, too. But Eisenberg's Law says that by default, if you can do something in the UI, you should be able to do it in a program also. One reason to make it a Law is that if you're in the habit of thinking that way, you build your UI in a way that factors the actual doing of whatever it is from capturing the mouse click that tells the UI to do it, and then you can (using a macro! :~P) automate exposing the action in the programming language. It's the other direction that's hard, because you have to design an appropriate UI, a dialog box or a slider or whatever, for each action.
A while ago there was a thread asking for a block equivalent to the "pic" option in the stage's context menu
Turns out there is such a block, kind of, but it's hidden in dev mode:
I say "kind of" because this makes a costume, rather than exporting the image, but there's also a block
in the Pixels library, and together they fill the need.
Why is it hidden in dev mode? By default every item in every context menu should have a block equivalent. That doesn't have to mean a zillion different blocks; there could be a block
in which the choices in the ITEM slot would depend on which menu was chosen in the MENU slot. Or something; this is an off-the-cuff idea rather than a careful design.
︎" submenu with entries stage, scripting area, and palette. Users should be able to ringify a block or script; if it's a single block maybe you should offer the union of that block's context menu when in a script and (then, after a horizontal rule) its context menu when in the palette. To make Jens happy, for all menus, filter out anything with "delete" in its name. :~) And your Menu menu should also include a submenu for each sprite with entries such as on stage, sprite corral, current costume... you get the idea. I suppose there should also be a Button choice in the Menu menu that lets you choose green flag, pause, stop, visible stepping, new sprite, paint new sprite, photo new sprite (we're leaving out the trash can). And a per-sprite submenu that gives you buttons such as Draggable, Revolve, Don't revolve, Face left-right only.
