Agreed, it can be really hard to get around a roundabout as a pedestrian if it's not designed for it, and then they make it so both you and people entering don't know each other are there until you're about to get hit.
You can use the split and join blocks to get the code and turn it back into blocks, but it's not well documented like I mentioned earlier. You split a ringified script "by blocks" to get a list version, which you can then use the "[text] of [list]" block (it's the one with length selected by default in the dropdown). That allows you to get the "Lisp" version in code.
Once you have the text version, you put it back into a split block set to split "by blocks", which gets the list version, which can then be put into the input list of a join block to get the code again.
This is technically discoverable from within Snap itself since they provide a library wrapping these steps, but it's not the first place you might look if you don't know it already exists.
The CoT isn't necessarily showing that it ran a classifier. The system prompt has:
> If Claude suspects it's talking with a minor, it keeps the conversation friendly, age-appropriate, and free of anything unsuitable for young people. Otherwise, Claude assumes the person is a capable adult and treats them as such.
> I know almost all colleges in the US have walk in free mental health counseling
I've been to two universities and this was not the case from the university itself, especially outside of normal business hours. If you didn't have an emergency, you had to wait months, if you had an emergency (I was explicitly told the only way to see someone anytime soon was if I said I'd kill myself if I didn't get an appointment and then they'd see if there was someone available) you might be able to talk to someone sooner. After hours emergencies maybe the psych ward at the hospital would see you? There's free resources, but universities aren't really providing much.
It's an odd quirk of Snap that they never cleaned up. Some blocks have a "friendly" error message. Delete a variable and uses of it get "Hmmm... a variable of name 'name' does not exist in this context". That one just regurgitates the JS error when it should say "You need to add and select a sound to play a sound".
You have to add one, in the sounds tab you can record one, or in the file menu they have a library of them you can load (they also have libraries of sprites and backgrounds which are pretty useful when we use this with students).
That one is a bit more defensible for variables, when you rename variables, it gives you "rename" or "rename all". "rename" renames the variable, leaving uses of it the same, "rename all" also renames where you used it. Deleting a variable leaves the blocks that references it in place but they'll throw an error if called (IIRC this is useful if you wanted to switch from a global to local variable or vice versa).
Now, custom blocks have a different issue, where deleting one just severs any code that was using it (so if you had some custom blocks in a program: [on start] -> a -> b -> c, deleting the definition for b will mean c no longer gets called). There's now a block to delete custom blocks, so you can make self-destructing code.
They've fixed surprisingly many of the quirks, but my biggest gripe with Snap is that they don't like to add documentation with new features. A lot of the older content has a nice "help..." context menu option with a description of what it does (which is often out of date itself, e.g. the "split" and "join" by blocks feature isn't shown on those blocks), and newer blocks have the context menu option... but nothing pops up.
The documentation problem is entirely my fault. I managed to stay up to date through version 8.0, but then so many things happened so quickly that I got swamped. Then I got depressed and gave up.
Also I made the mistake of writing the manual in MS Word. At the time, I couldn't find a standard way to insert pictures into a TeX document, or I would have used that. (Now, of course, there is a standard way.) There is an effort underway to convert the manual into a web-based format in a git repo that anyone can contribute to, but that effort is 90% done and you know what that means! :)
Six months ago I was teaching a beginning-programming course to six kids, using Snap!, so I was reading the forums. And there was a group effort to add documentation to many of the blocks that were lacking it. I haven't been back in a few months, so I don't know how that effort is progressing, but there were definitely some undocumented blocks that were getting documentation completed as I watched, and eventually added to the Git repo to land in the next release.
So it's getting better.
The other thing to remember is that the core Snap! development team is just two guys, Brian Harvey and Jens Mönig. When they're focused on things like trying to figure out how to get macros into Snap!, so that Snap! can truly be a Lisp (right now it's only most of a Lisp), they tend to leave the documentation effort to the community. If they had a larger team I might fault them for that, but with just two guys, I can't really blame them for focusing their efforts on things the community is less able to do, and leaving things the community can do up to the community.
I have to clarify that the Snap! implementation is 99% the work of Jens Mönig. It was 100% Jens for the first two major releases, back when it was called BYOB ("build your own blocks") and was an extension of the Scratch source code. Then we wanted to use it in a CS course for non-majors at Berkeley so I got in touch with Jens and started complaining about missing features! The result was an intense collaboration in which the coding was still 100% Jens but I contributed ideas about user interface and features. I think my biggest contribution was teaching Jens about lambda!
Our team has officially grown to six people, adding Bernat Romagosa, Jadga Hügle, Michael Ball, and Joan i Pelegay. And several Snap! users have made major contributions, especially to libraries that extend the reach of the language. But the interpreter itself is still all Jens.
That's more of a problem in text-based coding. One of the things I genuinely like about Snap (well, in my case NetsBlox, which is a fork of it) is the ability to have spaces and weird characters in a variable name.
Edit: Oh, you meant the lambda in the post title? It's not really part of the name, but you can at least type it into Snap itself.
There's no need to type the word "lambda" into Snap!. As befits a visual language, we have a visual representation of lambda; it's the gray ring that you sometimes see surrounding an expression or a script. It's a discoverable notation; when you click on an expression you see its value, and when the expression is inside a ring the value you see is the expression itself. We inherited from Scratch the idea of using different shapes of input slots to represent the data type that's expected, round for numbers and rectangular for text. (They have since changed their minds about that, I'm not sure why. They do still use hexagons for Boolean slots.) We have an "expression" data type, and instead of a polygonal shape, we represent expression input slots by preloading them with an empty gray ring. (If you drag something with a gray ring around it into the slot, your ring is absorbed into the one that's already there.) This lets us write higher order functions that are usable by kids who haven't yet wrapped their minds around anonymous functions. It took us three tries to get the notation exactly right, but I'm super proud of it.
reply