We have been struggling with the definition of abstraction. Unit 3 the intro to programming section has a simple abstraction example of creating a function to turn the turtle right by turning left 3 times. It makes sense but doesn’t hit the nail on the head. So I have created two examples to show them.
Here is another example to show. https://studio.code.org/projects/applab/1l9gJvt6IpglAu4-mn0b7OJUhzs9SBWbGkrUm8t5gdg What I have done there is create an abstraction for drawing a diagram that consists of colored squares. The drawing itself doesn’t matter. I have two sections of code following that. The first section implements the abstraction using turtle graphics. The second is commented out to start with and implements the exact same abstraction but with drawing commands on a canvas.
You can show them how the abstraction is first created using turtle graphics. Run it. You then comment out the turtle part and un-comment the canvas part and run it again. That shows them that the actual drawing portion of the program remains unchanged because of the abstraction. By hiding the details of how the drawing is made you can easily switch from turtle graphics to canvas and back. You can even add to the drawing without knowing if it will use turtle or canvas drawing. That is the very definition of abstraction.
Easy instructions to switch implementations: Go into text mode. Take out the / at the end of “turtle graphics */” so it becomes “turtle graphics *”. That causes the turtle section to turn green and become a comment. Add a / at the end of “the diagram *” so it becomes “the diagram */”. That section changes from green comment to purple, blue, and black code.
I just ran into another abstraction opportunity. Unit 5 lesson 10, the Color Sleuth. The way checkCorrect() is developed misses an opportunity to take it one step farther and highlight the idea of abstraction. I recommend doing that by creating this function instead of making checkCorrect more complex:
function playerTakesTurn (guess) {
checkCorrect(guess);
checkGameOver();
setBoard();
switchPlayer();
}
What we have done here is created a language using domain specific actions and specified what it means for a player to take a turn. All implementation details are hidden. It is a simplistic example but I think it would help our kids when they have to figure out what part of their Create Task is an abstraction or as is more likely the case, create one.
I have been thinking about abstraction lately since we are prodding the kids to get the create task done. The definition of abstraction we get is managing complexity in one’s program. That results in us pushing the creation of functions. Is every function an abstraction?
To me no. Using functions to reduce duplication or explain what a program is doing is just good practice. An abstraction to me is bigger than that. For me I look for implementation hiding, extending the language with domain specific functions, complex data types created from primitives or objects, and simplified APIs to manage complexity. The problem is our students don’t wrestle with applications complex enough to prove the value of abstraction.
So how do we encourage our students to embrace this best practice they don’t actually need? I have been trying a new way to program in App Lab. I will call it coding by color. You divide up the code to be written into sections with allowed colors of blocks. You provide a template with the sections in it.
What I find, at least when I code this way, is it forces me to think about functions and how they support each other.
A second thing I did was to create unit tests. I tried TDD (test driven development). TDD is a new way to write code that has become popular over the last 20 years. The idea is to write tests before you write the code with the test verifying when your code runs.
It changes the way you program in fundamental ways. Usually for the better. You can look at the project here. The tests are at the bottom.
TDD like the “code by color” described above encourages programmers to break code into small pieces making it easier to understand. TDD also keeps you out of the debugger. App Lab has excellent debugging tools but most people think TDD makes coding easier. If the App Lab staff finds this, consider adding blocks to specifically support unit testing built into App Lab and Game Lab.
Since libraries are now an App Lab feature, I decided to take up Don’s suggestion and build a library that will allow students to use blocks and/or a simple JavaScript syntax for unit testing.
Use this ID to import the library k9lMltOxqXBqO60Qgv8VWiHwemxePHwOk-1PwJDWEeM
