We're working on a Snap! project. Some of the built-in Snap! commands have somehow been deleted. For example, only a single type if "If .. Then" statement seems to be available:
We were not aware that it was possible to delete Snap! primitives and we're not sure how this occurred.
Is there a way to restore the missing commands without completely rebuilding the project?
Hi Glen,
teachers are often asking for versions of Snap! that only have a reduced set of blocks available, so students can progress gently without the distraction of seeing blocks they "don't need" for the task at hand. While I personally distrust such pedagogy I nonetheless wanted to make it possible for teachers / workshop facilitators to create "starter projects" around a reduced instruction set, and that's what hiding / showing primitive blocks is meant for.
I'm glad this had been resolved!
Why is this a bad thing? If a class starts with just rings and call, then students make loops, and then they can have the faster primitives. Otherwise, it is harder to see the point of making loops.
I just realized this never got an answer. I'm not Jens, but I think he and I are of one mind about this.
Starting with a small point, the teachers who want to hide primitives aren't teaching lambda calculus! Typically they're teaching young children, or they're doing an Hour of Code lesson and want to be sure it can be finished in an hour, and so they just give you MOVE, TURN, and REPEAT. Or they're teaching something entirely separate from programming/computer science, like the MATH+C project at EDC.
More generally, there's a deep question about philosophy of education behind this tactical question. What is the purpose of Snap!? For me and Jens, the purpose is the empowerment of young people, bringing them the intellectual toolkit of adult programmers in an accessible form. It's not to teach specific knowledge of any particular fact or skill. But facts and skills are what schools are all about, especially in these days of high-stakes testing.
All of us have invented puzzles in which students are to achieve some programming goal using only a restricted set of blocks. But the way we traditionally present such problems is by pulling the allowed blocks into the scripting area and telling the students to rearrange them into a program. This has the spirit of inviting the learner to play a game. Games have rules, and every kid knows that if you don't respect the rules, you're not really playing the game. Chess players don't move their pawns as if they were queens, not because some technology prevents them putting down the pawn except in a space it can legally reach, but because they want to be playing chess, not messing around with chess pieces.
By contrast, if you hide blocks, you're not inviting; you're enforcing. The hidden lesson is "I'm the teacher; I set the rules, you just do what I say." When Jens and I finally gave in to all the teachers who were bugging us about this, we put a "show primitives" option in the palette's context menu, and we're not hiding that. We hope this still keeps somewhat the sense that the student is a willing participant in the game. Some teachers, not all, worry that students will "cheat" by bringing in unauthorized primitives.
The MATH+C project paid Bernat to build a more restrictive environment, from which you can't escape except with some combination of keys pressed and mouse buttons clicked that I can never remember. I hate that, although the people in the project are all friends of mine. But I hate it a little less than I would otherwise because their goal is teaching math, not teaching programming, and in fact they hide pretty much all the primitives, providing the kids with only math-related blocks such as "+3." They don't want kids distracted by programming, which is indeed powerfully distracting! So I can sort of see their point.
Well that's definitely where you right-click. Personally I call it "the palette" rather than "the control tab," but a garlic by any other name would smell as sweet. (I love garlic.)