I got an error from your first sample program:
Also, when I run it from the community site page rather than from the Snap! editor, I get an error even just on Hello world:
Otherwise looks nice. I had some trouble reading your code, but the comments help a little, but I didn't see the comments until I happened to reduce the stage size in order to read a long block. There's that little yellow line going off to the right, but that wasn't enough to catch my eye. I think you should attach a (boldface, one-line) comment to the hat block saying "look right for comments" or something like that.
On the other hand, you could consider Harvey's Law of Documentation: Any time you are tempted to comment a piece of code, rewrite it instead. Preferably, rewrite it to be less clever. I know this law is the opposite of what your other CS teachers tell you, but they're wrong.
A program is a tree structure of procedures. In a well-designed program, the procedures near the root (the ones called directly by the main program) have broad jobs to do ("read the input" for example), and the ones at the leaves handle details that really don't affect the logic of the program.
Now, if programmers weren't lazy, for every program there would be a documentation tree with the same shape as the program tree, with each node corresponding to the procedure at the corresponding node in the program tree. So there would be broad documentation of the big pieces, and very specific documentation of the little pieces.
But that's never going to happen, because programmers are lazy. So, given that you're only going to be given part of the documentation tree, do you want the top part or the bottom part? Answer: The top part will be much more helpful in understanding the program logic. The bottom part consists mainly of trivial comments:
So, when I say not to comment your code, I don't mean not to write documentation. I mean to write high-level documentation about how the program works. If you feel the need to comment a low-level detail, either you're being clever (e.g., taking advantage of some adventitious detail of the bit patterns representing numbers) or you're not using data abstraction (NEW POINT, X VALUE OF POINT, Y VALUE OF POINT, SET X VALUE OF POINT, SET Y VALUE OF POINT).
I definitely try to follow this rule in my own code... Any time I find myself typing /* I think "Uh oh, how can I make this more straightforward?"
If you want to see an example of high-level program documentation that I wrote, there's one here: ucblogo-code/plm at master · jrincayc/ucblogo-code · GitHub. "PLM" stands for Program Logic Manual, which is something IBM used to sell for their big mainframe computer software, because back then the expectation was that everything was open source (not free, though, in either sense) and that some of their customers would have programmers on staff who'd want to personalize the software they used.