Section #1 Lesson Plan

September 20th, 2020

Written by Julia Daniel and Brahm Capoor

In the first week of section, we’re hoping you can get to know your section and they get to know each other, and that they understand why section is such a cool and important part of 106A. In addition, this will be the only section that covers Karel, so we hope you can get through at least the United Nations Karel problem.

Getting to know your Section

Feel free to spend a good chunk of time learning names, establishing how section works, and answering logistical questions about the class. Fun icebreakers are a plus. Make it clear that you and the rest of the course staff are here to support them in their learning over the course of 106A. Remind them that you are their primary point-person for questions about the class (although post on Slack or get in touch with Brahm if you ever aren’t sure how to answer a particular question from a student!). Introduce IGs as a one-on-one time to talk about their assignments and about how the class is going generally. You may have IGs before you next see them, since Karel grading and IGs are due next Friday, so this is an important point to make. All this being said, if students go down rabbit holes of detailed logistical questions, feel free to have them come talk to you after section so that you leave at least ~20 minutes for Karel.

Lecture Recap

So far in 106A, there have been 5 lectures, and this section covers the first 3 (in bold). Please check out the slides in full if you haven’t been in lecture, but here’s a quick recap:

Intro to Karel: Course Logistics, 4 basic Karel commands (move, turn_left, pick_beeper, put_beeper), anatomy of a program
Control Flow in Karel: for, while, if/else
Decomposition in Karel: Breaking down a problem into milestones, then using top-down decomposition to get to a particular milestone, testing and fixing, then moving on to next milestone
Variables: Variables as named boxes that you can put values into and read values from
Arithmetic Expressions

Karel Problem(s)

Students will be wrapping up their time with Karel after this week (except for the midterm!), but we’ve given two problems that should help solidify some of the important concepts they need for approaching future assignments, specifically milestoning, problem decomposition, and testing. One major point to make is that finding bugs is a sign of achievement, not failure– no one writes perfect code on the first try all the time, but finding your bugs quickly, and writing code that leads to simpler, easy-to-fix bugs, are skills to learn. Feel free to share your own past frustrations with buggy code with students, especially later on in the quarter with students who feel discouraged or “bad at coding”.

Hospital Karel

There are two main milestones to tackle, and the order doesn't really matter:

Building a house
- Assuming we know we are at a location where we want to build a hospital (abstracting away how we got there), how do we do it?
- Talk about decomposing repeated tasks – in this case, making a column of three beepers – and adding “vocabulary items” (functions) to Karel.
Crossing the entire world and putting a hospita wherever you find supplies
- Talk about abstracting away how the hospital is built to just focus on telling Karel when to build a house; assume you have a working build_hospital function.
- Test that this can be done correctly, without worrying about whether the house itself is built correctly. This can just be a couple sentences – “let’s run through this. If we have rubble here and here, will this [pseudo]code put houses where we want?” – to build in habits in your sectionees of testing whenever they think they’ve finished coding a milestone.

Karel Defends Democracy

Here, too, think about how to incorporate lessons of milestoning, decomposition, and testing. If you don’t make it through this problem, no worries. Make sure to tell students that we give them more problems than they’ll get to in section on purpose – these are good practice problems for them to tackle on their own!

Refreshing Knowledge

This section is a quick summary of the parts of Python that will be relevant to this section. Importantly, it is not written at the level that a student would be expected to understand. Feel free to ping me on Slack if you want to chat about how any of these concepts might be explained to a student.

Things you should know about Python

A collection of miscellaneous trivia in Python that might be relevant throughout the quarter.

Python is interpreted rather than compiled: Rather than first compiling a program into an executable binary, the Python interpreter evaluates your source line by line.
Python is strongly and dynamically typed: Values in Python do have types, but those types aren't checked at compile time (note that there isnt' even really a compile time to speak of). Instead, whenever a line of code is about to be evaluated, the types of the variables are checked then. In addition, variables aren't restricted to one type: you can set a variable equal to 3 in one line and then to "banter" in the next.
Everything in Python is passed by object reference: This is slightly tricky to understand, so the main note here is that passing parameters in Python works functionally identically to that in Java (i.e. 'primitives' like numbers are passed by value, and objects by reference). If that's all you want to know now, ignore the rest of this paragraph! In Python, there isn't really such a thing as a 'primitive' variable: all values are objects on the heap referred to by variables on the stack. Thus, in calling a function, those references are passed into these functions, allowing for pass-by-reference mechanics for data structures. However, interestingly, some data types like integers are immutable objects, meaning that any changes to them cause the reference to point to another integer, rather than changing what is already on the heap. As a result, passing integers into a function in Python has much the same mechanic as passing a String into a method in Java: you're technically passing an object by reference, but it's basically like you're passing it by copy.
There are only two scopes in Python: All values in Python exist at the module scope (available everywhere in the file) and the function scope (available everywhere in a function) after it's defined. Note that this means that loops don't have their own scope: a variable defined in a loop will still be available in that function once the loop ends.

Functions in Python

A function in Python is defined like so:

                    
def do_a_thing():
    # sick code here

and then called like so:

                    
def calls_other_function():
    do_a_thing()

Parameters are specified in Python just like in Python and C++ i.e. declared inside the parentheses of the def statement and then passed into the function in the same order that they're defined. Importantly, parameters to python functions are not typed, so it is the programmer's responsibility to pass in the correct types:

                    
def function_with_parameters(string, num, other_param):
    # sick code here 

# somewhere far far away...
function_with_parameters("brahm", 42, 2)
function_with_parameters(42, "brahm", 2) # this works, but is bad style

Additionally, functions can return values like so:

                    
def returns_value():
    return 42

Control Structures in Python

Loops in Python look like so:

                        
while condition_is_true(): # condition should evaluate to a boolean
    # code to repeat at this level of indentation
    
for elem in collection_of_elements: # iterate through elements 
    # code to repeat at this level of indentation

and if statements look like so:

                        
if condition_is_true(): # condition should evaluate to a boolean
    # code to repeat at this level of indentation
elif other_condition_is_true():
    # sick code here 
else:
    # sicker code here

Variables in Python

Variables in Python don't need to be typed at time of declaration, leading to the following pleasant-looking declaration:

                        
x = 3

Honestly, there isn't a ton else to know about variables in the language: other than the mechanics discussed in the general trivia section, they're pretty standard.