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.
This would be tricky because when the user is writing procedures we don't know yet what variables might have lists in them. (Variables don't have types; data have types.)
This would be tricky because when the user is writing procedures we don't know yet what variables might have lists in them. (Variables don't have types; data have types.)
Thanks Brian. So I have to udpate my list of steps:
to add the "create list" button back
to add list variables to a separated internal list in the Snap! code
to show list reporters separately, close to the list blocks
to show in the menu argument only variables whose type is list
i think you're misunderstanding the discussion, snap already has lists, just not this more restrictive style of lists. this is for a separate project by s_federici
the advanced topics section is called that because beginners usually shouldn't concern themselves with the stuff it it, it's usually just confusing
I don't know why, but this made me laugh. Is this because variables having types just doesn't fit with the idea of variables being pointers to a value/function/similar?
EDIT: I said function, but I meant like procedure or something. I'm a JS programmer at heart :/
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)
Thats what my teacher kind of said in the 2nd grade when she introduced us to Scratch
it was along the lines of "You wont become programmers, I just want you to learn more about computers."
oh, that makes more sense, although i do occasionally dream of being a professional programmer during math class, along with the usual "i will never use this math..."
Math isn't to use; it's to appreciate the beauty of abstraction. I agree that school math rarely helps with this appreciation, although there are good math teachers here and there.
