Minor
Page 18

A
when stopped script

should read

A
when I am stopped script

1 Note to users of earlier versions: From the beginning, there has been a tension in our work between the desire to provide tools such
as for (used in this example) and the higher order functions introduced on the next page as primitives, to be used as easily as other
primitives, and the desire to show how readily such tools can be implemented in Snap! itself. This is one instance of our general
pedagogic understanding that learners should both use abstractions and be permitted to see beneath the abstraction barrier. Until
now, we have used the uneasy compromise of a library of tools written in Snap! and easily, but not easily enough, loaded into a project.
By not loading the tools, users or teachers could explore how to program them. In 5.0 we have made them true primitives,

Ok - at this point I'm thinking that I'm not running the right version of Snap! !!!!!

Turns out I was using
https://cloud.snap.berkeley.edu/snap/snap.html

which says its version 5 but obviously isn't the same as the one I should have been running
https://snap.berkeley.edu/snapsource/dev/snap.html



Editing my previous comments now

bharvey wrote:

For those who've played with the dev version of 5.0, please read

https://snap.berkeley.edu/SnapManual50.pdf

and tell me about any bugs you find! Thanks.

Which are the main differences between 4.x and 5.0?

D. Higher Order List Operations and Rings

I feel this is real step-up / hang onto your hats moment !

Maybe needs some extra highlighting /explanation of this rather than just another heading

continued from above

To my (simple) mind - maybe the map function would be a simpler concept to introduce first?

Page 37
The images are tool small to read - make them 1 x 4 rather than 2 x 2?

having read on, I think Lists Section E should come before the complex stuff in Section D

Page 53

Since Scratch doesn’t have custom
blocks,

Scratch 2 and 3 have simplified custom blocks

Page 57

D. Local State in Sprites: Variables and Attributes
A sprite’s memory of its own past history takes two main forms. It has variables, created explicitly by the user
with the “Make a variable” button; it also has attributes, the qualities every sprite has automatically, such as
position, direction, and pen color. Each variable can be examined using its own orange oval block; there is one
set block to modify all variables. Attributes, however, have a less uniform programming interface in Scratch.
……
In Snap!

I think this would read better if it said
In Scratch, a sprite’s memory of its own past history takes two main forms. It has variables, created explicitly by the user
with the “Make a variable” button; it also has attributes, the qualities every sprite has automatically, such as
position, direction, and pen color. Each variable can be examined using its own orange oval block; there is one
set block to modify all variables.
…..
In Snap


or something like that

Page 58

When a new clone is created, by default it shares only its methods, wardrobe, and jukebox with its parent

jukebox? :-)

Page 60

(Due to a misfeature,

Not seen that phrase before

Page 63
No text underneath the heading
Media Computation with Sounds

Page 64
Personal comment

Local State with Script Variables
….

going to take a lot of re-reading to understand what is going on here

Possibly might need a brain transplant as well

SimpleScratch wrote:

Page 53

Since Scratch doesn’t have custom
blocks,

Scratch 2 and 3 have simplified custom blocks

Wow, thanks for the really careful reading! I'm especially glad you caught this one; I wouldn't want to have published something wrong about Scratch, as opposed to about Snap!.

s_federici wrote:

Which are the main differences between 4.x and 5.0?

The biggest difference is barely mentioned in the manual: the new “social” web site with published projects, comments, and all that.

The media computation stuff is new. Fast primitive HOFs is the biggest thing for me. And a million little bug fixes, of course. But it's the new web site that makes it 5.0 rather than 4.whatever.

SimpleScratch wrote:

D. Higher Order List Operations and Rings

I feel this is real step-up / hang onto your hats moment !

Maybe needs some extra highlighting /explanation of this rather than just another heading

Hmm. The quickest answer is that this is a reference manual, not a tutorial, although I do sneak in tutorials on really hairy things such as continuations. But also, maybe we'll be proven wrong about this, but we (I think I can speak for Jens on this topic) believe that much of the reason people consider HOFs a hard idea is that text languages don't help as much as graphic languages. I mean, compare
(filter (lambda (x) (= (mod x 2) 0)) '(9 4 7 2 0))
with the Snap! version. The “lambda” doesn't jump out at you the way a gray ring does, and you have to work at figuring out what's inside the scope of the lambda expression. And, it took us three tries to get this right, but the fact that the ring is built into the block means that you barely have to think about it at all, until you get to writing your own higher order functions. So it's kind of intentional that we don't make a big fuss about HOFs. We say, look, here's an even easier way to do it, and it is easier! The trick is to emphasize HOFs as embodying what the C++ people call programming patterns, rather than emphasizing how encapsulating a function delays its evaluation. The latter sounds hard; the former (leaving out the part about C++) sounds easy. Finding all the items that match some criterion is something you have to do a lot, so here's this tool, and you stick in the criterion and the list, and out comes the answer.

As to map before keep, I always used to do it that way, but we've slowly moved toward keep first for two reasons, one deep and one embarrassingly stupid. The deep reason is that applying a function to each item of a list is something that, especially if you're not a mathematician, doesn't feel like an obvious thing to want to do, until you've seen a bunch of examples, not just as exercises but in the context of a real program. Keeping the even numbers, or the numbers, or the nouns, or the variable names, or whatever out of a collection of things does seem like something you do in real life, not even necessarily in the context of programming. I want to shorten the contact list on my phone by keeping all the people who are current friends or collaborators. I'm out of room in my bookshelves so I want to keep only the ones that I think I'll want to read again.

And the embarrassingly stupid reason is that “keep” is a word everyone knows, whereas “map” is a technical term only mathematicians know. And I haven't been able to find a good replacement name that doesn't suggest that the original list is modified, rather than that a new list is created.

SimpleScratch wrote:

Page 63
No text underneath the heading
Media Computation with Sounds

Oh lord. I kind of vaguely thought the manual wasn't quite done yet, but totally forgot why. Whew! Thanks.

SimpleScratch wrote:

Local State with Script Variables
….

going to take a lot of re-reading to understand what is going on here

This is a hard topic. In order to understand it completely, you need to understand how evaluation is done in a Lisp, and in particular how lexical scope works. I [used to, pre-retirement] tell my students that they have to sort of split their brains in half; one half doesn't worry about how it works internally but stays focused on what we're trying to achieve (namely, local state variables). The other half just mindlessly cranks through the evaluation rules, never mind whether it makes sense. If you can do both of those at once, you get it, after two weeks of class (six hours of lecture, four hours of lab, and a lot of homework). Alternatively, read SICP 3.1 and 3.2, neither of which makes sense until you've read both of them, so you have to read them twice. (The two SICP sections are more or less the two brain halves described earlier.)

(This evening I was at an event at the Exploratorium and after the session was over this guy came up to me and told me he took my SICP class 15 years ago, and it totally changed his understanding of programming, and even though Scheme is this weird little language that he's never used again, he uses the ideas every day. And he recently had to teach a couple of mechanical engineers at his work to understand the programming that interfaces with their hardware, so he made them read SICP. Warms my heart.)

Snap! 5 and the Snap! conference are very exciting! The video sensing blocks aren't yet listed under Etcetera.