About Scratch having new variables silently set, while Snap! uninitialized

Help with Snap!
1

I learned that in Scratch having new variables silently set was a feature, however in Snap! this inherited feature is a misfeature and I like Brian's suggestion to imagine new variables as being type-virgin, i.e. as if created with an initial value of *uninitialized*.

Since we were asked by the original poster to stop replying here, maybe we can split from this post on?

Meta-comment: I think it is nothing wrong if people disagree and/or see things differently, or even argue.

I maybe wouldn't even start arguing against the misfeature allowing a new variable to be silently (i.e. "by default") set to 0 or else arguing we need to allow it to be silently set to an (anonymous) list values, too, if I knew it is indeed considered a misfeature.

I thought it was a feature and not a misfeature. (I haven't read in the Manual that :sn: contains things that even developers themselves acknowledge to be a misfeature; so I could not know that.)

I think explicitly stating this difference between Scratch and Snap! in the Manual would be nice.

2

Well, I think it's a misfeature. Jens might not.

This is the visible tip of a huge iceberg, which is about trying to be both a Scratch-like, quick-start language for even young kids vs. being a "grownup" language for experienced programmers.

In Scratch, lists are at the esoteric end of things, and not first class; 0, False, and the empty string are all interchangeable, at least in certain contexts. So having variables start with that 0-False-empty value makes sense and makes failing to initialize a variable not a bug, at least the first time you run the program. For :sn: beginners you can make the argument that it makes sense here, too.

At the other extreme, there are people, including some German CS professors and some forum teenagers, who want :sn: to be just like Java, with a ton of error checking and strict typing.

In between, but not midway between, my Berkeley colleague Dan Garcia wants a feature that would allow optional declaration of the return type of a function. He points out that we already have that for predicates, indicated by the hexagonal shape. And if a function does have a declared type, he wants it to be impossible to drop it into an input slot of a different type. So, you couldn't drop a function of type number into a slot of type list. (Not settled in this proposal, I think, is whether primitives would have pre-declared types, so you couldn't drop a + block into a list input slot.) He argues that when he's volunteer-teaching at his kid's middle school, that precise thing happens a lot, and catching it while building a script would be better than having to debug it when running the script.

I think it's fair to say that over the last decade we started with the principle that we'd be just as permissive as Scratch, and that over time we've taken tiny steps in the direction of type checking. Jens doesn't like runtime error checks because they slow down even correct programs, but a "compile time" (script-building time) check might, from that perspective, be better. My first timid toe in the water was asking for a specific error message for trying to take the first item, or all but first, of an empty list, instead of getting some inscrutable JS error, because that situation often means you forgot the base case test in a recursive function, and I want the error message to say so.

Anyway, we keep relitigating these questions because there's no clear right answer.

3

If this is true (i.e. it makes sense), then it could be argued that what I have wished for (i.e. silently setting new variable to anonymous list value at east when it was not yet set to anything in particular by a user (in other words, when it is still set to 0), when using the "ADD item TO" block as suggested here, would not make such a non-sense.

Thanks for putting this discussion (and my wish within it) into a context/a bigger picture of other people's wishes that I was not aware all want something from you and Jens. Acknowledging this, however, I still have an impression that my wish is a tiny and the least 'disruptive' one in comparison to other people's wishes.

But maybe I am wrong.

4

"Still set to 0" is different from "not initialized"; maybe I explicitly set it to 0. We'd have to have an initialized? flag for each variable.

The thing is, maybe I forgot to initialize it, but I wanted to initialize it to some non-empty list value. In that case, I'd rather get an error message than having :sn: make a guess as to what initial value I had in mind.

I mean, we do sometimes make special cases. The big one is that if you drag a variable into a gray ring input slot the ring disappears. So I'm not saying it would be impossible to make the special case you want. But as a teacher I feel that would just be reinforcing the idea of variables having types, so I'd rather you just get in the habit of initializing your variables!

5

I appreciate your recommendation to always initialize variables, and despite giving impression to the contrary by arguing with you about lists, I already have a habit of initializing my variables in all my projects. The thing is, in my view of what initialization means or could mean, is that it is not being limited to using SET block only.

In my (broader) view (which may not be the right (correct) cs view) one can understand it as giving a variable a first value and that can be achieved not only by SET block, but also (in case of list), using the "ADD item TO list" block, too.

6

You can't say "Add $100 to my bank account" and expect the bank to open an account for you! First you open the account, then you can add to it.

So, no, I think the only way to initialize a variable is with SET.

7

Ok but Snap! isn't a bank

edit: It's a bank of precocious 12-year-old programmers which you have virtually collected, nevermind

8

Variables in Snap! are persistent by default and stored with every save. So they are initialized, at load time, by deserialization. There is no point to force explicit unconditional initialization in such stateful environment.

9

What does this mean? Is this something I am doing and/or want to (i.e. pretending there's only one 'bank', where every citizen has already opened a personal account, so they can just say "let's add something to it"), but I should not, or something completely different?

10

Contrary to "legacy" languages Snap! saves states as a part of project. Every variable (not marked as "transient") is stored at save and restored at load. There is also imediate mode - every block can be executed at any moment. It's quite uncommon set of features. So i consider Snap! as being statefull. There is no need to set EVERY variable (unconditionally) under "Green Flag" or "Recieve msg" hat.
If you build e.g. simulation of throw, gravity force, view scale can be stored in project but material point sprite position should be set/reset at every run.

11

Indeed, if what you want is the value that the variable had when the project was saved, there's no reason to reset it. What I generally do, and I think I learned this from Jens, is to have an initialization script that I run only when some disaster has lost the values of variables.

init
init1102×324 58.2 KB

If the value of the variable changes during the running of the program and you want to save the changes, then you especially don't want to initialize the variable when you start the program.

However, what should be avoided is assuming that a variable is initialized (has been saved initialized, or is initialized to 0 when you don't do something different), and then trying to run the program a second time without reloading it. That's very likely not to work; it's a common Scratch beginner mistake.