As someone may know, I keep hacking Snap to adapt it to goals that are somewhat different from the ones of the -incredible- Snap! team.
Just to clarify, my main purpose is to make Snap! as simple and intuitive as possible. So I'm not interested in making available to "my programmers" very powerful features (but I love that those features are available in Snap, so I can use them to make my job easier). To make it even more clear, I was the one that created a Snap! mod just to hide some blocks in the palette, when this was not a Snap! feature yet.
One of the things that -at least to me- was very useful in BYOB, was that you could select a list from a menu in the list blocks, instead of having to drag a variable reporter inside the list argument.
I could recreate the BYOB-style list blocks adding "variable names" arguments (as in this project). But I would also like:
to add the "create list" button back
to show list reporters separately, close to the list blocks
to show in the menu argument only variables whose type is list [update: see this project for a version with list-only vars in the dropdown argument; thanks dardoro!]
I hope Jens and Brian are not paying attention to this post of mine
So I would like to have hints (like "start in these scripts and in these lines, use these functions, etc") in order to speed up my work as much as possible and to avoid to follow dead paths.
Any help is welcome!
FINAL REMARK: Why am I not using Scratch 3.0, if I like BYOB/Scratch-style list blocks? Because Scratch has VERY poor procedures and, in its new 3.0 version, it lacks some handy elements with respect to the excellent 1.4 version that inspired BYOB.
I know very well what you think of this. That is why I didn't propose this for Snap!, but for a simplified version to introduce my students to programming. When they know how to handle this, I promise I will let them know that this is just the road to evil
PS: my students are not going to be programmers. They learn programming just as a way to improve their computational thinking
No, the cause and effect is more the other way; having all variables be in the same category (untyped) means that all data have to be accessed similarly.
It's evil because data are by nature heterogeneous. Back in the old days, when Fortran made a sharp distinction between numbers and text, people used to write programs to, as a trivial example, ask the user to type in any number of numbers and print their sum. And the program's instructions to the user would say "Type 9999 when done" because they'd really like to say "Type DONE when done" but you can't put text in a numeric variable. The modern version of this problem is that in a typed language it's a real pain to make heterogeneous lists (all different kinds of items) as opposed to a list of integers, another list of text strings, etc.
What is proven is that my students want the minimum number of "actions" to express anything. So, assigning an empty list to a variable that has already been created is "more complex" than just creating an empty list; adding an element to a list by dragging the list reporter from the palette is "more complex" than just selecting the list name from the menu (selection that, usually, they don't even have to do, as they have just a single list in their projects and the list name is already available in the menu argument)