I'm Pamela. I'm working on an AP Computer Science Principles review course for Khan Academy. For the programming unit, I'm teaching in JavaScript (since that's what we use on KA), but am providing links to see the similar code in App Lab, Python, and Snap.
I have successfully ported all the examples, but I have a few questions and observations:
I would like to link to a view that shows the code, the editor view. The default "Share" URL does not show the code, and one has to click the toggle icon to see it. Is there a query parameter or hash that I can specify that defaults to showing it?
Is there a way to add comments or notes in Snap?
I am currently using "talk" as the equivalent of printing a line to a console. Is that the closest thing, or is there a console output as well?
I noticed there is "Make a variable" and "script variables". It seems that the former creates global variables and the latter creates scoped variables. I've decided to use the latter in all my examples, as they are all within a scope. Please correct me if I misunderstand the distinction.
I noticed that "Make a block" is available in both Operators and Variables. Is there a difference between the two locations? I don't think I noticed one, except that I kept getting confused as to where my blocks ended up.
I observed the following constructs are not a part of Snap, please let me know if I'm incorrect:
">=" and "<=" : This affected a number of my examples. I used OR with > and =, but that lead to redundant code, so it was not my favorite. I reversed the condition in cases where I could do so. I'd vote for having those operators personally.
Lack of actual "true"/"false" values: I get that Snap generally isn't very typed (i.e. strings aren't surrounded by quotes when you type them in), so I could see why they don't exist. But it was interesting to note the absence.
Lack of pow(): This came up a few times. I used the workaround of 10^/log^ combo, but gosh, that complicates things. I'd vote for a pow().
UI-wise, the "Share" UI was not intuitive for me. My flow would be to create the project, "save as", then "save as" again but click "share" and then click "cancel". It took me a few tries to feel confident that "cancel" didn't actually cancel the sharing. It seems to me that "Share" could be a separate file option.
If you read this far, thank you! I don't need or expect responses to everything, but I thought I might as well share it all here. I'd mostly love to know if there's an approach to #1.
You can add "flags" to your shared projects url. See Snap! manual (pages 101-102) to get all options. You only need "&editMode" and maybe "&noRun"
Comments in Snap! ? Yes. Right click on the script area and you get the option "add a comment". Then you can attach it to any block (or you can leave it alone anywhere). Also, you can create comments into the block editor (it is just a script area) and the comments attached to the hat of a custom block are the "help info" for this block.
You can create your own console. Usually, children use the normal "Say" or "Think" blocks to see what is happens, and that info is shown into the stage. But you can save your debug info into a variable, or into a list (like a log list)... or you can use JS block to run the "console.log()" function.
With "Make a variable" you can create "global variables" (for all the sprites) or "local variables" (for that sprite). You can use them on the script area (wherever you want... in all sprites or in that sprite). As you have said, "script variables" are only for their scope (their script, their stack).
You have a library with blocks to create those "global/local variables" programmatically.
Oh! You can "make a block" everywhere!! You have the "Make a block" button at the bottom of every category primitive blocks, and also with the "+" button, and also with a right click over the script area. Note that Snap! first name was BYOB (build your own block), so this is an important feature!
And observations...
1o. Yes, you must use (( ) < ( )) OR (( ) = ( )) But we have custom blocks... and that is for this! You can save your own library with the blocks you need. Then, the beginning point of a project could be your own "starting point" project with all the elements you want. And of course... maybe you build different "starting points".
2o. Yes, you have the "true/false" value inside the Operators category
3o. Yes, maybe pow() could be added to the Math block. But (the same as 1o) you can create your own math block. And you can use Snap! primitives or use JS block to make anything you want.
And I say nothing now about ht UI. But soon we will have a social web and all these actions will be more intuitive (sharing, publishing, rating...)
Adding just a couple of points to Joan's detailed response:
About ≤ and ≥ (this is the 21st century, we don't need ugly digraphs ), we leave those out deliberately because they turn out to be great programming exercises.
We are, though, going to add an a^b block.
When you use the Make a Block button or the plus sign in a palette, the initial dialog defaults to using that color for the new block, but you can change it in the initial dialog window to be any color you want.
And yes, the awkwardness of sharing is on our list to fix!
One thing that nobody seems to have mentioned: never use ([log v] of ()]) It uses Math.log(input) / Math.log(10) and often has rounding errors.
You can use e^/ln for the same effect or use the JavaScript code Math.log10(input)
Also you can use Math.pow(base, exp) to get pow.
The flags for the URL works great, just what I was hoping for.
Oh, I see true/false now. Perhaps I was looking in variables. Thanks!
I was generally trying to avoid making custom blocks, as I'm trying to create examples that would resonate with folks across any BJC classroom, and they might have different approaches for constructs that aren't native to the language. For ≥ and ≤ in particular, my content introduces the relational operators in the article before the compound operators (AND/OR), so I was hoping to use ≥ and ≤ without having to reference not-yet-introduced concepts. It's really not a big deal though, since most students will be reviewing with this, not using this to learn for the first time.
Thanks, space elephant, for that pow() suggestion.
), we leave those out deliberately because they turn out to be great programming exercises.