Closed ddgarcia closed 10 years ago
cycomachead
commented
10 years ago We're having this discussion in Snap meetings. I agree, the key here is "definitely" which we can do for primitive blocks. We can't really enforce things for custom blocks but it's not as big a deal I think.
brianharvey
commented
10 years ago Please remember that in Scratch, blocks don't /surprise/ you by refusing to drop into slots. This is why blocks have shapes! If a block looks like it fits, then it fits. Predicates are distinguished by having hexagonal shapes.
Consider the Scratch case of numbers vs. strings. Scratch grew out of Logo, and so they understand the importance of being able to construct a number by concatenating digit strings. Hence, the JOIN block is round, and fits into a number slot. And that's why they accept /any/ string in a number slot -- the blocks are the same (reporter) shape, so they have to be accepted in the same slots.
We could make list reporters a different shape. But I'm reluctant to start down that road. When we get first class sprites, first class costumes, etc., done, how many different block shapes are we going to have? Right now it's three shapes, which makes the interface very easy to remember.
I'm not saying that this Scratch history is inviolable. I want us not to accept "123ABC" as a number, for example -- at runtime, though, not while building a script. But I do think that anything we reject at "compile time" -- that is, when assembling a script -- should be visually obvious, and I'm not convinced this proposal passes that test.
And, you know, consider the case of a tree whose branches are lists and whose leaves are atoms. Programming that sort of structure is the kind of thing that's trivial in Lisp and takes a Ph.D. in Java. We don't want to lose this sort of flexibility.
brianharvey
commented
10 years ago I'm closing this -- I don't think there will be much room for compromise on this issue.
E.g.: "list" and "in front of" return lists. Why can they (and Boolean-range functions, like and/or/not) be dropped into number input slots? It's wonderful that commands can't be dropped into "expression" input slots, but why don't we limit more things that definitely don't make sense? Variables (and other blocks whose return type can't be deduced, like "item of ") would be able to be dropped anywhere. I think that would be in keeping with the spirit of Scratch/BYOB and make it easier to code, since fewer blocks would have a white outline and want to grab the thing I want to drop.