Going from syntax to CS concepts

Question

I am going to be teaching a small-ish group of people to write code to control a device. The code is built around a giant framework made to make it easy to write the actual code. My job nominally is to teach the students how to make the device do things, so I have to begin with the syntax to control the device. This would look like:

leftArm.setPower(10);
while (gamepad1.buttonA.pressed) {
  leftArm.setPower(20);
}
if (time.seconds == 30) {
  logger.log("There are 30 seconds elapsed");
}

I will have to start with a list of the methods on the objects that are exposed (e.g. leftArm, time, logger, gamepad1) and how to use them, and cover basic if statements and loops.

From there, I'd like to expand their knowledge of computer science concepts while still relating it back to this device. I thought about beginning to explain the framework it's built in, but I started looking at it and it was far to complex to introduce at this point.

So, how can I take students from this simple understanding of syntax and methods and give them a base of solid, cross-language, CS knowledge?

Answer 1

tl;dr Make the mapping between the software and the hardware explicit at the start and then show the code, rather than the other way round. Draw pictures. Give them a mental overall image, not just detail. Detail with no context is hard to follow, and hard to learn.

In many ways this question is like another here in that you have a complex system that must be taught all at once. See the answers to that one, including mine.

A useful strategy for this would be to turn it around a bit and start out by saying that the code they are about to see is a model of the physical device. The parts of the model match the parts of the device. The robot has two arms and so its model has two "Arm objects". Objects in the model need a description and the description (in Java) is provided by a class: RobotArm.

The physical robot's parts have functionality of various kinds and these are modeled in the RobotArm class with methods: move, etc. Once we have the class (at least in skeleton form) we can instantiate it: new RobotArm().

The Robot class itself is built by composition (arm fields: Robot.leftArm...

So what you do is make a mapping between the code and the physical thing and point out that (as I assume is true of the code) the mapping is pretty direct. This is actually pretty faithful to the idea of OOP, in fact. Modeling is a good first metaphor for OO programming.

At this point you can show them some code, but I'd show it heavily ellipsed, with only the detail needed shown in full. In other words, only show some of the methods and maybe only parts of some methods.

So the code you show above in your Question doesn't come first, but only now after they have seen the map, even if the map is incomplete. The class is an abstract description of the physical thing and the code completes the description. When you show methods, don't make them naked (as if this were just C coding), but show them as part of their class.

I've assumed that the robot itself is an actual object in your framework. It is possible that it isn't, if there is only one. The robot "object" may be implicit. Or possibly your code (above) is really part of a method of the Robot class so you wrote leftArm... rather than this.leftArm...

Note that if the "Robot" were not a physical device, but a screen simulation instead, the same ideas as above work well.

Another way to put all of this is that you do the integration step for them and present that, rather than depending on each student to integrate the detail into a consistent whole and all in the same way.

So, you introduce three big ideas (Class, object, method) and show how they relate to each other and to the physical thing. There are a few smaller ideas also (instantiate, part-whole composition), of course that you incorporate into your lecture. It should only take 15-20 minutes to do this at a high level.