Introduction
Hello, welcome to the second FiveHive article for AP CSP, how fun!
In this article we will go over the learning objectives for 1.2, as covered in the AP CSP CED.
- CRD-2.A - Describe the purpose of a computing innovation.
- CRD-2.B - Explain how a program or code segment functions.
- CRD-2.C - Identify input(s) to a program.
- CRD-2.D - Identify output(s) produced by a program.
The Purpose of Computing Innovations
So we know what a computing innovation is, but now we need to learn the purpose.
There are two purposes for computing innovations: to solve a problem or to pursue a creative interest.
An example of a computing innovation that solved a problem could be the telegraph! Before the telegraph, information exchange over long distances could take weeks or months by mail, the telegraph changed this to almost instantly. Obviously, the telegraph is pretty slow by modern standards, but it was revolutionary at the time.
Pursuing a creative interest is more fun, though! An example of this could be a video game. One of the FiveHive co-leads plays a lot of Valorant and Marvel Rivals, I think. Those are very much computing innovations that pursue an interest.
In short, having a good understanding of your purpose is extremely beneficial* to understanding and developing your computing innovation.
*true in life as well.
Note: On the AP CSP Exam, it is likely you’ll be asked to describe the purpose of your create task program. For this, you should answer the purpose, not the function (my program aims to help people, vs my program gives out advice). It’s a very simple mistake, but it could cost you the point.
Programs and Code Segments
Okay, so a program is a collection of program statements that, when put together, perform a specific task. This is also known as software.
Inside of this program are code segments. A code segment is a collection of programming statements inside of a program. A function can be a code segment, 3 lines of random code can be a code segment, or any lines together, really, can be a code segment.
Let’s use GPS as an example.
The program (or software) would be the entire route, with all instructions to get from point A to point B.
A code segment could be literally any few statements, “take ramp onto highway, merge into center lane, take exit 27A” these together could be a code segment.
A programming statement in our GPS analogy would be as simple as “at the light, turn left,” a simple command, just one line.
To summarize, a computer program is made up of code segments that are made up of programming statements.
Keep in mind:
- Programming statement = individual instruction
- Code segment = group of statements
- Program = complete collection
Describing programs and inputs/outputs
A program can be described by what it does:
- My program takes users from point A to point B
or, in more depth, by what it does and how the programing statements accomplish this.
- My navigation program uses the user’s location, and desired destination, and calculates the fastest route there, makes a path on map, and displays the path and instructions to reach the destination (extremely simplified, just fyi)
Inputs
Inputs are just any data that goes into the computer processes (these can come from the user or other programs). There are a few types of inputs:
- Text (words inputted into ChatGPT, or numbers inputted into a calculator app)
- Auditory (microphone inputs; words spoken to Siri or music inputted into Shazam, for example)
- Visual (Photos opened in photoshop)
- Tactile (touchscreen taps, keyboard clacks)
Take these oversimplified examples with a grain of salt, though they should be fine for the beginner level that AP CSP is.
Inputs should be able to work for a variety of inputs. For example:
- If you’re making a calculator, your program should be able to handle a large range of numbers, but declining non-integers.
- If you’re making a chat service, your service should be able to handle almost any character thrown at it, and deliver it correctly.
- Or if you’re making an image editor, you should accept a large range of formats (PNG, BMP, JPEG), but reject ones like .EXE or .wav
And when you do encounter an input you should decline, make sure the program handles that correctly(i.e displaying a message instead of crashing)
Outputs
So, we know what inputs are, therefore it is only logical that outputs are the opposite. Outputs are any information sent from the program to a device (speaker, screen, vibration motor, etc.). Inputs directly influence the output, since the input is the data to be manipulated, the output is the input after all calculations. The input usually affects the output.
The same few types, flipped, are:
- Text (the response from ChatGPT, the final answer from the calculator app)
- Auditory (speaker outputs; Siris’ verbal response, or Shazam playing back the song once it’s found it)
- Visual (The photo after being edited in Photoshop)
- Tactile (The screen buzzing in response to the touchscreen tap, or a controller vibrating)
Again, these are honestly very simplified for the sake of beginner level.
Events
Simply put, an event is any action that causes input to the program, and therefore changes the flow of execution(or the way it runs). For example:
- Pressing A is an event
- Pressing the start button on a program is an event
- Moving your mouse is an event
- Clicking your mouse is an event
Event-driven programming
Most software nowadays is event-driven. This isn't some fancy phrase, it just means that everything is based on events.
For example, Windows OS as a whole is event-driven. Everything is based on user input. You tap the keyboard keys to type, move and click your mouse to open apps and websites, and speak into the microphone to activate Cortana (does that still exist?).
Program Behavior
Program behavior is just the way you expect a program to work. This is usually described by how a user interacts with it.
Before programming something, you should have an idea of how it will work. Figure out your purpose, any inputs and outputs, and the specific events.