I was experimenting with the <is [] a [number v] ?> block, and it brought up a question that I would like to ask about Snap!.
All the different data types register as at one of the different options from the second pulldown menu. For example, 5 is a number, an empty list still registers as a list, and leaving the box blank registers as a text.
Is there a data type in Snap! that registers as none of the different choices, like a null data type, or an input that does not register as any of the choices?
JavaScript functions and other JavaScript objects that aren't costumes, sounds, lists, etc. have an undefined type in Snap!. A nothing type also exists, but I can't think of any value of that type rn. You can shift-click the Snap! logo, click Switch to dev mode, and open the Operators palette to find a type of reporter.
Not on purpose. The idea of a NULL value in the C family of languages (including JS) is imho really iffy because they represent it as a zero pointer -- that is, it's the same bit pattern as the number zero, the Boolean False, and in some languages the empty string. If we found that we needed such a creature, I would propose to have a unique object whose printform would be "no value" or something like that, and we'd initialize variables to that object instead of to zero! And I guess add that to the type pulldown.
Yeah, that's clearly wrong; they should have one of the procedure types. The trouble is that we'd have to parse the JS code to know whether it's a Command, a Reporter, or a Predicate.
The one about the turtle costume is just a misfeature, because Jens thinks that the story you tell users should match the code that implements it. It should say "costume."
Maybe we should add "stage" to the menu; we would certainly do that if we implemented multiple stages. So I'm going to count this as a misfeature too.
The only really hard one is the JS Function problem. I'm tempted to say we should replace the word "function" in the block title with a pulldown menu in which you could choose "reporter" (the default), "predicate," or "command." That would be going to a lot of trouble (because we'd have to keep that choice somewhere for every such JS procedure) to solve an esoteric problem, so it certainly won't be a priority.
A parser could relatively easily notice that different paths through the code give different result types (including no result as a type) and then punt to Reporter.
A better argument you could make would be
return foo(x,y,z)
which would require type-checking some other procedure that might not be ready to hand. But punt-to-Reporter still makes sense there.
I know. What I'm saying is that being wrong occasionally is okay in this context. If foo doesn't return, then this call to foo -- inside a return statement -- is erroneous anyway.
I'm not sure there is a big difference between the different snap function types. I always use reporter, predicate, command and undefined together. Do you have any examples that don't? If so, you can add a function option that includes all four.
We're trying to keep the options in the IS_A_ block disjoint. That prevents users being taken by surprise.
The type declarations used to be more important than they are now, because we didn't formerly allow putting command blocks in a reporter ring. Now you can do that, provided there's a REPORT block in the script you end up running. In the other direction, reporters that might report a script are allowed as input to command rings, but they get unringified, the way variables do.
Many words like "function" and "variable" have different (but overlapping) meanings in mathematics and in computing. I know that the reporter/command distinction goes back to Logo but most of the computing world uses the word "function" to cover both.
I'm curious whether, if we could do everything over again, it would have been best to make no such distinction. No confusion between using 'run' or 'call', the type menu for input would be simpler, and probably many other simplification would result. Also it is very common in many programming languages to have commands that do side-effects but also return a status value.
And on a related note, when teaching should one emphasize or deemphasize the command/reporter.
Obviously, it is too late for Snap! to change but I'm curious if there is a consensus in the Snap! community that the distinction was a mistake (inherited from Scratch).
Reserving the name "function" for functions isn't about the command/reporter distinction. That's why we have the word "reporter": so that we can reserve "function" for actual functions. Just because some programming language designers don't know what a function is doesn't mean we have to lower our vocabulary to their debased level. (And their languages aren't any good either. :~P)
"Variable" is a different issue; mathematical language is confusing, using the same name for at least two different ideas: something that varies, or something that's constant but we don't know its value yet. The programming language theory gang have a precisely defined meaning (a cell in memory, not including a name, which may be separately bound to it). But the programming language designers who don't know what a function is typically don't understand that either. (I confess I didn't until I started hanging out with PL theory people.)
I have often had that conversation with myself about whether we should have had all procedures return values, as in Lisp. Right now (at 1:47am, so keep that in mind), I think that the Logo choice was right for Logo's purpose, which was to teach youngish kids math. And so I think Scratch was right, too. What I'm not sure about, tonight, is the Snap! program of building on Scratch while supporting serious CS for teenagers. (I almost wrote "late-teens" but then remembered Nathan.) Maybe we should have built a block language more closely modeled on Scheme (you know, God's programming language). But then maybe we should just use Scheme, which was what we did at Berkeley until Dan roped me into this CS Principles movement. I think CS Principles has worked, and of course that's a good thing. And I think that BJC has worked, in the sense that we've raised some people's expectations about what belongs in a CS course for everyone (namely, recursion and HOFs). More people are happy with the lesser code.org idea that a CS course for everyone should be slick videos by athletes and rich people -- but then, more people used Basic, too, back in the day.
I hated lessons involving definitions/vocabulary that didn't also include some motivation. In this case one motivation that comes to mind is that calls to actual functions can memoized and also executed in any order. Another motivation is that functions have a declarative meaning missing from procedures with side effects.
I wonder how often the concepts of reporter and function are conflated by teachers and students. As you mention, RANDOM is not a function but is clearly a reporter.
