Students will be able to:
Programming languages must necessarily define the meaning of a set of commands which are generally useful and applicable. In order to extend their functionality, nearly all programming languages provide a means for defining and calling new commands which programmers design to fit the needs of the problems they are trying to solve. Defining functions is an example of how computer scientists use abstraction to solve problems. A programmer will design a solution to a small, well-defined portion of the task and then give a name to the associated code. Whenever that problem arises again, the programmer can invoke the new function by name, without having to solve the problem again. This ability to refer to complex functionality by simple, meaningful names allows for programs to be written in more intuitive ways that reflect the relationships between different blocks of code.
In this Quorum CSP curriculum, we will use the word "Action" in place for the "Function" that is used in the Code.org CSP curriculum.
In the previous lesson, students created simple turtle drawings using only four commands. At some point they probably wished that more commands were available to them. Ask them to describe a command they wanted to be able to use and explain why they wanted to use it.
Programming languages will always have some commands that are already defined, but there will be many instances when the exact command that the students want isn't available. Today the students are going to start exploring a powerful feature of most programming languages that will allow them to overcome this issue and create commands of their own. They have been solving turtle challenges with a limited set of commands. They can create these new commands themselves, using the original turtle commands as building blocks. They may like to add the following commands:
In the following video, the concept of "Functions" is described with the example of "Turtle Programming" tool used in the Code.org curriculum. While the Code.org Turtle Programming tool primarily uses a "block language" (a language that could be written by combining picture blocks on the computer screen), the "Quorum Turtle Module" uses a "text language." Although the style of the coding is different between the two languages, the concept that supports the execution of the code/command is very similar. Therefore, viewing this video before you start the activity is still beneficial for your learning.
In order to "define an action" in Quorum Language, there are a few simple rules and suggestions students should follow when they code. When the students define an "action," they should write the word "action" (with lower case) first in the line, then type one blank space and the name of the action. The most important thing when defining an action is that they need to write the "end" a few lines below to indicate the end of the particular action. They would write what the action does on the lines in-between the lines showing the name of the action and the line showing the corresponding "end."
action NameOfTheAction //what the action does end
When they give a name to the action - declaring the action, it is a good idea to give it a name that makes sense to describe what the "action" does. It is also recommended in the Quorum Language that the students start the name of the action with uppercase letter. If the name is long, they would use the convention called "Pascal Naming Convention" - also called "Camel convention." With Pascal Convention, they would capitalize the beginning letter of the each word used in the action. For example, if they are creating the action that makes the "turtle" to spin three times, they would write the line in the following manner:
action SpinThreeTimes end
When they are calling this action in Quorum Language, they would add opening and closing parenthesis right after the name of the action, and write it outside of the action. The following is an example.
In summary, the students should be aware of the following:
Start the turtle on the dot named (5, 5). Then, define an action called TurnAround which turns the turtle around. Then, move the turtle forward one space.
This time the students will write their action code in the area outside the TurtleCommands region and inside the Main region. Once they have defined the action, they have to call it in inside the TurtleCommands region. Typically, someone will call an action in lines of code above the action definition - this might make the students feel like they are working in reverse, since they first write the code to define the action and then add a line to call it.
This challenge allows the students to get some more practice calling an action by using TurnAround() along with the MoveForward() action.
Start the turtle at (6, 5). Create a plus sign around the turtle's first position. The turtle should end where it started, which is the middle of the plus sign, facing up. Each of the four segments of the plus sign are one MoveForward() long.
Students should see the following lines: (5, 5) to (6, 5) to (7, 5); (6, 4) to (6, 5) to (6, 6) (The order would depend on how the students wrote their code.)
The exemplar programs have been written in the style that will be favored in this curriculum. These choices do not affect the functionality of a program but may affect the clarity with which a program can be read. In practice, so long as a consistent style is used, programs will be easier to read and write.
Let the turtle start on the dot (6, 5). Create an action called TurnRight(). Start by adding code inside the action definition that will turn the turtle to the right (by turning left three times) when called. Then use this action in some code to draw a rectangle. Make sure the turtle ends facing the same direction and in the same location it started. As an example, try to make a rectangle that is 2 moveForwards tall and 1 moveForward wide.
The turtle starts on dot E5. When the students have finished running their code, ask them to check the lines drawn by using the OutputLines() command. The following is an example the lines that should be drawn: (5, 4) to (5, 5) to (5, 6) to (6, 6) to (6, 5) to (6, 4) to (5, 4).
Modern life is filled with complex systems. For example, consider a train system. It's theoretically possible to know the exact dimensions and turns of every rail on the system, what trains are used to take us to our destination, and how much fuel the train would need. If we just want to get from one place to another, however, these details are useless and even distracting.
We need simpler representations of this complex metro system, like a map. Since all of the details of the dimensions of the rail, what kind of train, and how much fuel is needed is taken care of the company that provide the train rides, we only need to know the surface of how to use the train system. And "how to use the train system" is summarized on the map, where the map is the abstraction of the train system.
The image below shows a simplified map of a train route system in a metropolitan area. The map shows multiple colored lines, intersecting each other. It also shows hundreds of train stops on each line with their names.
Programs are complex systems. Individual commands may be easy to understand, but it can quickly become difficult to understand the logic and relationships connecting them. We need abstractions in our program's code to let us "box up" these details so that we can focus on the bigger problem we're trying to solve.
Procedures are abstractions that the students will create in this lesson. For example, by writing a function called drawRectangle(), they can "box up" and name the code necessary to draw a rectangle. Once they have tested that function and it works, they don't need to worry about the details of how it works anymore.
The same concept applies in the Quorum Programming Language. Instead of "boxing up" as a block language would do, the students will give the starting point of the action on one line by defining the action - such as "action DrawBox." Then they should put "end" on the line that defines where action stops.
This unit is largely about teaching the students:
Take your code from previous challenges that draws the rectangle and move into a new action called DrawRectangle(). The first line of the code inside TurtleCommands should be a single call to DrawRectangle(). The rest of the code should just be action definitions.
NOTE: the program will still do the same thing. We are just changing the way it is written to demonstrate to the students that they can use functions that they have already written as building blocks in new functions.
This is the introduction to the "Drawing a Diamond" series of challenges that shows the students the benefit of thinking about programming tasks in terms of writing functions. The goal of this introduction is to facilitate discussion in class.
Discuss the following:
Start the turtle at the location (0, 4). Define an action named action DrawStep() that makes the turtle move forward and left, and then turns itself to the position facing up.
After they test their code, their code should draw the following lines: (4, 0) to (4, 1) to (3, 1).
//this is an example of a mistake action DrawStep action TurnRight //this is an action definition, but you are not calling the action end end
//this is an example of a correct implementation action DrawStep //some other code that you want to add TurnRight() //this calls the TurnRight action //some other code that you want to add end action TurnRight //define how you are going to turn right end
The students are going to continue to build up towards a diamond by defining a action that draws one side of the diamond. If we look at the whole image we are trying to draw, we'll notice that each of 4 sides is compromised of 3 calls to DrawStep(), plus a few extra moves. Right now we'll write the code for one of those sides.
Start the turtle on (4, 0), then:
The turtle should start from position (4, 0) [SetStartCoordinate(4,0)]. When the students are successful on their code, their code should draw the following lines in the exact order: (4, 0) to (4, 1) to (3, 1); (3, 1) to (3, 2) to (2, 2); (2, 2) to (2, 3) to (1, 3).
Now the students are finally ready to make the diamond!
Start the turtle on (4, 0). Define a action named action DrawDiamond() that calls DrawSide() multiple times in order to draw a diamond. Your final solution should be triggered by a single call to DrawDiamond().
The code should draw the following lines in the exact order: (4, 0) to (4, 1) to (3, 1); (3, 1) to (3, 2) to (2, 2); (2, 2) to (2, 3) to (1, 3) to (1, 4); (1, 4) to (2, 4) to (2, 5); (2, 5) to (3, 5) to (3, 6); (3, 6) to (4, 6) to (4, 7) to (5, 7); (5, 7) to (5, 6) to (6, 6); (6, 6) to (6, 5) to (7, 5); (7, 5) to (7, 4) to (8, 4) to (8, 3); (8, 3) to (7, 3) to (7, 2); (7, 2) to (6, 2) to (6, 1); (6, 1) to (5, 1) to (5, 0) to (4, 0).
In the end the students will have 4 actions defined:
These 4 actions work sort of like a hierarchy of top-down design. At the top is DrawDiamond() which makes calls to DrawSide(), which makes calls to DrawStep() and TurnRight().
Review pages 9-11 which introduces the Create PT from the document below with the students. Activate the link to download the document.
The class will be doing a Practice Create PT that mimics most components of the AP Create PT later. So for this lesson, the class should quickly review those components now, but the class will have opportunities to review and practice them in the next few lessons as well. For right now the students don't need to understand all the details, just the big picture.
Benefits of functions -- Possible responses:
Functions are examples of Abstraction -- Possible responses:
In your own words, explain at least one reason why programming languages have functions. Include an example of something you did in this lesson that demonstrates the reason you describe.
In this lesson, the students learned about top-down design for building up solutions to larger programming problems. Ask the students to plan the code that they would use to draw this image below. Also, ask them to describe each of the actions that they would create. They should not write all the code, only the names of the actions that they would create with a brief description of what each action would do. Ask them to write their plan using the following the format:
The image shown below consist of five plus signs. One plus sign is pace at the center. On each arm end of this center plus sign, one plus sign is connected at with its own arm end.
If students complete the diamond challenge early, ask them to compare their solution with another group. They should then try to create the version of the program that they believe is best with an associated justification. Challenge students to think about potential tradeoffs between efficiency and readability.
Groups that finish early can continue working with their functions to make more complex figures. Ask groups to continue building functions they think are generally useful for drawing.