Comment by sinuhe69
11 hours ago
Snap is designed to be more expressive and powerful than Scratch. But I find debugging them is very painful. Changing the name of a variable or block for example, could create “holes” in the calling sites but the system can or cannot report an error and fails silently. Snap is IMO more flaky and the team seems more eager to add features than polish the existing ones or make the system mor robust and stable.
> Changing the name of a variable or block for example, could create “holes” in the calling sites
WTF. Isn't the whole point of visual programming that you are NOT bound by the limitations of text as a medium? A block refers to a specific variable. It shouldn't matter what it's called, it shouldn't matter if what it's called changes, it should still refer to the same variable even after renames.
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.