Comparing Scratch with Snap!

Hal Abelson:

First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel, formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
- "Structure and Interpretation of Computer Programs"

Scratch version (follow the link to see the finished product):

Snap version (follow the link to see the finished product):

From the experience of building these, some of the advantages of Snap which emerged are:
1) Hal Abelson's objective ("programs must be written for people to read, and only incidentally for machines to execute") can be achieved with Snap. Because you can Build Your Own Blocks (BYOB) the overall structure of the code can be laid out far more clearly. It's tidy and you can immediately see the big picture of the overall program. This is because the extra blocks you build are tucked away into the Palette section.

Here is my main Snap procedure. The inner repeat stamps a fuzzy circle of dots. Then the radius and number of dots is increased and the process repeated until the specified number of circles are done. The structure of the code is relatively easy to understand, compared with Scratch.

I have written no less than 9 of my own blocks and by naming them meaningfully you have a good idea of what they do. Their names are:
MOTION TYPE (blue)
circle_centre
move_fuzzy_radius
return_to_centre

LOOKS TYPE (purple)
background_colour
set_dot_colour
stamp_lumpy_dot

OPERATORS (green)
pi
increment
dot_number

These DIY blocks are not black boxes. The user can open them up in the Block Editor, look inside to see how they are implemented.
Here is set_dot_colour:

Here is move_fuzzy_radius:

2) Because of point one above it is possible, with Snap, for the user to easily see and tweak variables in the Scripting Area. You can see the values in the code of 4 variables: radius, radius_increment, dot_spacing and number_of_rings:

On the other hand with Scratch the whole code takes up lots of space, so it is not practical to tweak the variables in the scripting area. This means, in Scratch, it has to be done with prompts but with so many variable that becomes too arduous / time consuming and the user will become impatient. In the Scratch version I "solved" this problem by restricting the number of variables that could be tweaked to three: background colour, dot colour and number of circles.

3) Snap has extra features such as lists within lists which enable me to display colour selection more clearly and elegantly. See the pen_colour table. The user chooses the colour by typing in the matching number, eg. 10 for orange.

Previously, I reviewed an article about the design of construction kits by Mitch Resnick and Brian Silverman where they promoted the virtues of the KISS principle. Their point 2 was that wide walls took precedence over high ceilings. Their point 5 was "make it as simple as possible – and maybe even simpler". Those points are embodied in Turtle Art and Scratch.

I'm arguing here that Snap!, a program with more powerful features is better suited to designing more advanced tools / applications. And surprisingly, with respect to, presenting tidy code it does adhere to the KISS principle. Returning to the Hal Abelson quote I was struck by how I could reduce clutter in the Scripting Area by Building my own Blocks and design code that expressed its intention more clearly than in Scratch or Turtle Art.