undefined

points

[-]

> 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.

by gs176 hours ago|

parent|

[-]

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.

by gs177 hours ago|

prev|

[-]

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.

by rmunn1 hours ago|

parent|

[-]

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.