Custom palette categories in BJC projects?

For Teachers
1

I notice that the starter code in BJC projects tends to stick custom blocks in one of the built-in categories. For instance, the custom blocks in the Gossip project from Unit 1 Lab 2 are in the Operators category.

That offends my sense of coupling and cohesion. I feel like it would be nicer if the project came with it’s own custom category (e.g. Project) and any custom blocks in the starter code were in there and that would be the right place for students to create their own blocks. Is there some pedagogical reason I’m missing that it’s good to throw them into the existing categories? (To me the built-in categories feel like the standard library and I wouldn’t expect to add things to the standard library; I’d expect to make my own libraries.)

(I’m not asking BJC to change; I have my own fork of it running on my own server so I can change this if I want. I’m just curious if there’s something I’m missing about the way it is, either educational or technical.)

2

Most likely projects were created long before user categories were possible

BJC has been going for quite some time

3

Yes, it’s the way it is because BJC predates custom categories.

But also, if we were starting now, I think I would still argue for adding blocks to the built-in categories. One of the things we want to teach is that once you’ve written a procedure it’s no different from a procedure that someone else wrote. So, for example, until relatively recently APPEND was a library procedure rather than a primitive. But once you’ve loaded the relevant library, I want you to think of it just as if we’d made it primitive.

Custom categories make sense for a library that creates a ton of blocks; I can see why SciSnap wants to create a bunch of them. But even, say, the APL library is less obvious to me. APL itself distinguishes procedures that are basically scalar functions even though they can be extended to lists from procedures that are meaningful only for list inputs, and that’s the Operators/Lists category distinction.

When Jens fell in love with the APL RESHAPE function and implemented it as a primitive, if it’d been in a custom APL category it would have moved into Lists. So users would have to remember which APL-derived functions are loaded from the library and which are built into Snap!.

So, if you’re suggesting a general principle that custom blocks belong in custom categories, I disagree. I would do that only if the custom blocks really do create a new intellectual category distinct from the existing categories. If we had a library consisting of the hyperbolic trig functions, I’d put them in Operators, not in a separate hyperbolic-trig category.

Scratch works kind of the way you’re suggesting; custom blocks automatically go in a “my blocks” category instead of letting you choose a category. But they do it that way because they think of custom blocks as being a special, advanced thing to do; they want to make the custom blocks stand out. We adamantly reject that idea; we think creating custom blocks should be a perfectly ordinary thing to do.

Edit: The streams library uses a custom category because streams really are a distinct idea, but even that’s more about implementation than about some deep truth. If Snap! were a normal-order language like ML or Haskell, then the ordinary List-category functions would all be stream functions!

The Colors and Crayons library deliberately defines Pen blocks because they implement the way I think colors should have been implemented in Snap! in the first place.

4

I guess to me it depends on whether the block actually belongs in the category. For instance, I don’t think the blocks the Gossip project in BJC adds to Operators are actually operators. So if a block obviously belongs in a particular category, I’ve got no problem putting it there. But if the blocks are defining a new abstraction on top of the existing categories my design sense says they should be in a separate category, that is more specific to the application being built. (Obviously none of this matters a ton at the scale of most BJC projects but I want to teach good practices.)

5

Well, Operators already isn’t the sort of pure category you’re envisioning, because it has numeric and text operators in it.

I guess my taste about this is strongly influenced by the fact that we didn’t have custom categories until just recently. But also, I’m influenced by the Logo history of dealing with text not as strings of characters but as sentences made of words, so in my mind what’s in Gossip is just what should have been a primitive data type anyway! I might feel differently about the quiz program, where we make a big point about declaring a new Question data type, or the address book, in which we declare a Contact type. Maybe I’d be more open to putting those in custom categories.