Unit 1 Lab 2 Teacher Guide

In Labs 2 and 3, students learn a new idea: not only can they assemble existing blocks (code) to create sequences (scripts), they can also encapsulate an entire script into a single new block of their own design, which they can then use as if that block had always existed. This process—one aspect of abstraction—is basic to computer science. Students will see how a multi-part script can be "hidden" inside a block (so students don't need to see all the details of the block while using it) and given a name (so they can easily know what it does and can use it more than once).

In this lab, students program two sprites to gossip with each other, picking randomly from words and ideas that students specify. The context is whimsical—students generally enjoy teaching a computer to gossip and find the results funny—but the ideas they are learning are deep. Getting a computer to generate (and understand) natural language has been the serious work of computer scientists for decades; Siri is one of the results. Students first experiment with blocks that have been built for them, seeing what they do. Then they learn to edit and modify these blocks. Finally, they create a new block of their own by using the same structure they've seen in the blocks they've edited but now with new content. In doing so, they will learn how to create lists of data, select data from those lists, and combine data in new ways. In Lab 3, they will extend this knowledge to another aspect of abstraction—learning how to give blocks inputs.

Pacing

Prepare

As a Class

Lab Pages

Page 1: Pair Programming.
- Learning Goal: Begin the use of pair programming and understand the value of this way of working.
- Tips:
  - Some students may resist pair programming, arguing that they work better alone. Tell them to give pair programming an honest try during the first lab or two, and then you'll entertain ideas about modifying the way the pair works if they still want that.
    - Programmers in industry often work in pairs, but the specific driver/navigator structure of pair programming isn't really how they do it, for the most part. Programmers who are accustomed to working collaboratively find ways to fit together that take advantage of each person's strong points, and they change styles of work depending on the specific task—is it coding, or data design, or documentation? Pair programming is a simplified type of collaboration that lets students experience different roles in a team. If students complain that it feels artificial, you can agree, and explain that it's like beginning at any other skill: You do it in a precise way, following all the rules to the letter.
  - Visit csteachingtips.org for more suggestions on pair programming.
  - Lost on the Moon. This is an exercise in cooperation. Almost every time, the group does better than any of its individuals, so it helps convince students that cooperation works.
    - "What does this have to do with computer science?" The subject matter of the exercise (astronaut survival) was deliberately chosen as one that none of the students is likely to know anything about. (By contrast, it's quite likely that some of your students have experience with programming while others won't have had that experience.)
    - How it works: Divide the class into groups of three or four. (Four is better because even numbers discourage voting.) The first part of the exercise is individual; if you want, you can defer organizing groups until after that.
      1. Hand out the first handout with the list of supplies facing up. Read the introductory paragraph with the class.
      2. Students work individually for 10-15 minutes. They organize the items in order of importance to survival with 1 for the most important item and 15 for the least important.
      3. Tell them to turn the sheet over. Read the suggestions about cooperation with them. These suggestions may feel counterintuitive as they go against the "hidden curriculum" of society.
        
        It's not a competition. We live in a competitive culture. Young people will have a learned instinct to treat an exercise like this one as a competition. Encourage students to push beyond the winning vs. losing mentality.
        
        Consensus not compromise. Encourage students to focus on understanding each other's reasons. and to look for solutions that respect both reasons, rather than "splitting the difference" of the actual answers.
        
        Better vs. more popular. Voting makes sense when the voters have different interests: employer vs. worker, farmer vs. programmer, etc. In those situations, voting is a sort of nonviolent warfare; the stronger team wins. But when you're all on the same team, voting is not a good way to make decisions because there's no guarantee that the initially most popular idea is the best idea.
        
        Cooperation doesn't mean to let someone else have their way. Just as it's not about winning, it's not about losing. Students should pay attention to the ideas and the reasoning behind the ideas rather than to the politics of whose ideas they are. Good reasons for decision-making should be persuasive, not loud voices.
      4. Now divide the class into groups, and have them do the same exercise again. Their goal is to get the best possible answers for their group. Give them 10 minutes.
      5. Now hand out the official NASA solutions. Both group and individual scores are computed by, for each item, computing the (absolute value of the) difference between the student ranking and the NASA ranking, then adding the 15 item scores. A low score is good.
      6. Debriefing. Expect a lot of "it's not fair" complaints. "It's not fair; how were we supposed to know there's no magnetic field on the moon?" Don't get defensive; remind students that the exercise deliberately asks about a topic nobody in the class has studied or experienced. You'd expect that individual and group scores would both be random. And yet, even in this extreme situation, groups beat individuals. Be sure that the fairness complaints don't prevent that comparison by taking all the time. First have them guess how many students did better than their groups. Then find out: "Hands up if your individual score was better than your group score." There won't be very many hands. It's really remarkable how well this works; typically every student does worse than their group.
Page 2: Making Programs Talk.
- Learning Goals:
  - Try out code to see what it does.
  - Analyze code to see how it works.
- Tips:
  - Some of the sentences that the program makes are silly, such as "my cat loves my cat"; encourage students to enjoy that rather than trying to "fix" it.
  - The starter project shows Snap! code with comments attached. Some students may want to comment some of their code, for their own information, but please don't require students to do so. This isn't a software engineering course preparing students for the workforce. Keep the focus in this first course on the beauty and joy. In fact, if the question comes up, you should tell students that code written to teach, as in this project, will be more heavily commented than "real" production code. Comments on every block restating what it does in English make the code harder, not easier, to read. One comment, at the beginning of a definition, can be useful to describe the intended purpose of the block and/or its domain and range.
    - A comment attached to the hat block at the beginning of the script in its definition will be used as the help text, if a user of the block selects "Help" from its context menu.
  - In this lab, most of the actual directions for students are in the project starter file, rather than on the lab page. BJC doesn't always use this approach, but its virtue is that students don't have to move their heads back and forth between the lab page and the project itself.
  - This page introduces the term "reporter" for blocks that report a value, as opposed to command blocks that just take some action. This first exploration of these block types is not the time to teach vocabulary; just use the appropriate words yourself. Formal definitions come later.
  - Making Sprite(2) tell Sprite to respond is a tentative introduction to recursion, here using broadcast blocks rather than procedure calls. As with "reporter," this is just a first taste. Formal introduction will come later.
Ideas for Brian and Mary to integrate:
- "Don't make kids stop and memorize vocab." (for page 3)
Page 3: Customizing and Debugging.
- Learning Goals:
  - Personalize the who, does what, and who2 blocks by inserting phrases into the list blocks inside.
  - Become familiar with the arrowhead notation for variadic blocks (ones that take a variable number of inputs, like list).
  - Become familiar with the concept of debugging, and debug any issues that arise in the project.
- Tips:
  - Most students will be funny and not hurtful or obscene in their inventions. You don't need to preemptively protect against that, but if it happens, that's the time to tell the class that they should be mindful of whether everyone in the class (including you) will find something funny.
  - This is a little awkward... --MF, 5/21/19
    It is probably too early to talk about abstraction and name it. Students will need to see more examples of it before it needs a piece of technical vocabulary. But two of its attributes may be worth mentioning even now: one, putting inside a block named to make code easier to read and understand by "hiding the complexity," and two, using a simple name that describes the purpose of the code. Once we understand what who does and are assured that it works properly, we no longer need or want to see the guts of how it works.
  - The yellow box after (not inside) FYTD 1 is important; it's yellow rather than orange because at this point the report block is given to them, so they don't have a chance to make this mistake. Later, when they are writing their own blocks, misconceptions about the difference between report (which tells the computer some value) and say (which tells it to the user) are likely to come up.
  - String and concatenate are language from the AP exam. BJC uses "words," "sentences," and "joining." Make clear to students that they need to know the technical terms for the AP exam, but the more natural language is fine for real life, including real programming after the exam is behind them.
  - About debugging: These are very simple programs, and they may not have anything to debug. But at least students should be sure of that by repeated testing.
Page 4: Making Your Own Block.
- Learning Goals:
  - Create a new reporter block (oval shape) called gossip response with the same inner structure as the three reporters included in the starter project.
  - Edit the gossip2 block to use the new block.
- Tips:
  - This page is almost all mechanics, rather than big ideas. You might want to make sure that both students of a pair get to make a new block.
  - The vocabulary box formally introduces reporters and commands. Of course students have seen these words, and examples of what they mean, before this. The distinction is important in almost every programming language, although the names used for them differ. Some languages use "procedure" for commands and "function" for reporters. (The latter is a slight abuse of language, since a mathematical function always returns the same value for the same inputs, and that's not true of all reporters; consider random as a counterexample.) Some use "function" for both! (This is a serious abuse of language!) Some languages, especially functional languages, require that every procedure return a value. That makes life much simpler. (For example, we wouldn't have to have call separate from run, or separate versions of if as a command and as a reporter.) One of the few disadvantages of a graphical language is that we're stuck with the different block shapes fitting into different places in a script.
  - Some additional vocabulary that we decided not to put in the student pages: A command or a reporter is a block, not a particular use of a block. A reporter with its input slots filled in is an expression, and a command with its input slots filled in is an instruction. It's best if you model using these words yourself, without asking students to memorize them. This is formalized for you below.
  - In the "On the AP Exam" box below, the second bullet is an AP vocabulary item, but we don't dignify it with that name because it's plainly incorrect -- procedures are values in themselves. They should say "the value of a procedure call" or "the return value of a procedure call."
Page 5: Adding Variety to Gossip.
- Learning Goals:
  - Explore more complicated reporter that introduces conditionals and predicates.
  - Experiment with and reflect on a recursive procedure.
- Tip:
  - Conditionals and predicates are introduced here experientially and without any definitions. Resist the urge to "teach" these topics for now; the formalism will come in Unit 2.
  - Students also get their first taste of recursion (procedures calling themselves) as they embed more complicated who inside more complicated who. As with conditionals and predicates, these ideas do not need to be formalized yet, and mastery is not expected. Students dabble in recursion again throughout the next few units, and the final two units (after the AP exam) address this topic in detail.
  - FYTD 8-9 are another toe-dip into recursion. You are not expected to teach the word or the idea, just to be prepared for student questions about it.
  - Here is some vocabulary for you to use in context, not to require of students...
    : Block Types and Blocks with Inputs
    Block Types:
    - A command is a single jigsaw-puzzle-shaped block, without its inputs. For example: and are commands. They tell the computer to do something.
    - A reporter is a single oval-shaped block, without its inputs. For example: and are reporters. They report data.
    - A predicate is a single hexagonal block, without its inputs. For example: and are predicates. They are reporters that report only Boolean values.
      
      A Boolean value is or . (These are different values from the text strings "true" and "false"; they are also different from 0 and 1.)
    Blocks with Inputs:
    - An instruction is a command block along with its inputs or input expressions. For example: is an instruction.
    - An expression is a reporter block along with its inputs or input expressions. For example: is an expression.
    - A Boolean expression is a predicate block with its inputs or input expressions. For example: is a Boolean expression.

Solutions

Correlation with 2020 AP CS Principles Framework

Computational Thinking Practices: Skills

1.C: Explain how collaboration affects the development of solutions.
2.B: Implement an algorithm in a program.
4.A: Explain how a code segment or program functions.
4.B: Determine the result of code segments.
6.A: Collaborate in the development of solutions.

Learning Objectives:

CRD-1.C: Demonstrate effective interpersonal skills during collaboration. (1.C)
CRD-2.B: Explain how a program or code segment functions. (4.A)
AAP-2.D: Evaluate expressions that manipulate strings. (4.B)
AAP-3.E: For generating random values:
1. Write expressions to generate possible values. (2.B)
2. Evaluate expressions to determine the possible results. (4.B)

Essential Knowledge:

CRD-1.B.2: Common models such as pair programming exist to facilitate collaboration.
CRD-1.C.1: Effective collaborative teams practice interpersonal skills, including but not limited to:
- communication
- consensus building
- conflict resolution
- negotiation
DAT-1.A.5: Abstraction is the process of reducing complexity by focusing on the main idea. By hiding details irrelevant to the question at hand and bringing together related and useful details, abstraction reduces complexity and allows one to focus on the idea.
AAP-1.C.1: A list is an ordered sequence of elements. For example,
```
[value1, value2, value3, …]
```
describes a list where
```
value1
```
is the first element,
```
value2
```
is the second element,
```
value3
```
is the third element, and so on.
AAP-2.B.3: An expression can consist of a value, a variable, an operator, or a procedure call that returns a value.
AAP-2.D.1: String concatenation joins together two or more strings end-to-end to make a new string.
AAP-2.D.2: A substring is part of an existing string.
AAP-3.A.1: A procedure is a named group of programming instructions that may have parameters and return values.
AAP-3.A.2: Procedures are referred to by different names, such as method or function, depending on the programming language.
AAP-3.A.6: The exam reference sheet provides the procedure
```
DISPLAY(expression)
```
to display the value of
```
expression
```
, followed by a space.
AAP-3.A.7: The exam reference sheet provides the
```
RETURN(expression)
```
statement, which is used to return the flow of control to the point where the procedure was called and to return the value of
```
expression
```
.
AAP-3.A.9: The exam reference sheet provides procedure
```
INPUT()
```
, which accepts a value from the user and returns the input value.
AAP-3.B.6: Using procedural abstraction helps improve code readability.
AAP-3.B.7: Using procedural abstraction in a program allows programmers to change the internals of the procedure (to make it faster, more efficient, use less storage, etc.) without needing to notify users of the change as long as what the procedure does is preserved.
AAP-3.C.2: The exam reference sheet provides
```
PROCEDURE procName(parameter1, parameter2, …)
{
    <block of statements>
    RETURN(expression)
}
```
which is used to define a procedure that takes zero or more arguments. The procedure contains
```
block of statements
```
and returns the value of
```
expression
```
. The
```
RETURN
```
statement may appear at any point inside the procedure and causes an immediate return from the procedure back to the calling statement.
AAP-3.E.1: The exam reference sheet provides
```
RANDOM(a, b)
```
which generates and returns a random integer from
```
a
```
to
```
b
```
, inclusive. Each result is equally likely to occur. For example,
```
RANDOM(1, 3)
```
could return 1, 2, or 3.
AAP-3.E.2: Using random number generation in a program means each execution may produce a different result.

Lab 2: Gossip