| Ch1 Ch2 Ch3 Ch4 Ch5 |
|
In the 1970s, a Stanford graduate student named Rich Pattis decided that it would be easier to teach the fundamentals of programming if students could somehow learn the basic ideas in a simple environment free from the complexities that characterize most programming languages. Drawing inspiration from the success of Seymour Papert’s LOGO project at MIT, Rich designed an introductory programming environment in which students teach a robot to solve simple problems. That robot was named Karel, after the Czech playwright Karel Čapek whose 1923 play R.U.R. (Rossum’s Universal Robots) gave the word robot to the English language. Karel was quite a success and had soon spread to universities all across the country.
The original implementation of Karel the Robot was designed for use with Pascal, which was the most common programming language for introductory computer science courses throughout the 1970s and 1980s. This version of Karel is patterned after the programming language Python, which is now the most common language used to teach introductory computer science courses.
Karel is a very simple robot living in a very simple world. By giving Karel a set of instructions, you can direct it to perform certain tasks within its world. Those instructions constitute a program. At the beginning, Karel understands only a few predefined instructions, although you will soon be able to teach it new ones. When you write a Karel program, you must do so in a very precise way so that Karel can correctly interpret it. In particular, the programs you write must obey a set of syntactic rules that define what instructions and language forms are legal. Taken together, the predefined instructions and syntactic rules define the Karel programming language.
In many respects, the Karel programming language is similar to more sophisticated programming languages, such as Java or C++. Karel programs have a similar structure and involve the same fundamental elements as programs written in those other languages.
The important difference is that Karel’s programming language is extremely small, in the sense that it has very few operations and rules. It is easy, for example, to learn the entire Karel language in an hour. At the end of that time, you will know everything that Karel can do and how to specify those actions in a program. Those details are easy to master. Even so, you will discover that solving a problem can be extremely challenging. Problem solving is the essence of programming; the rules are just a minor concern along the way.
Real-world programming languages involve so many details that learning about them tends to dominate the first few weeks of a programming course. All too often, those details become the focus of the course, and the much more critical issues of problem solving get lost in the shuffle. By starting with Karel, you can begin to concentrate on solving problems from the very beginning. And since the Karel environment encourages imagination and creativity, you can have quite a lot of fun along the way.
Karel’s world is defined by avenues running (north-south) and streets running horizontally (east-west). The intersection of an avenue and a street is called a corner.
Karel can only be positioned on corners and must be facing one of the four standard compass directions (north, south, east, west). A simple Karel world is shown below. Here Karel is located at the corner of 1st Avenue and 1st Street, facing east.
Several other components of Karel’s world can be seen in this example. The object in front of Karel is a beeper. According to Karel’s inventor Richard Pattis, beepers are “plastic cones which emit a quiet beeping noise.” Karel can only detect a beeper if it is on the same corner. The solid lines in the diagram are walls. Walls serve as barriers within Karel’s world. Karel cannot walk through walls and must instead go around them. Karel’s world always has walls along the edges, but the world may have different dimensions depending on the specific problem Karel needs to solve. Here, for example, there are walls that surround three sides of the corner at 2nd Avenue and 2nd Street, creating a (cul-de-sac that Karel can enter only from the north.
When Karel is shipped from the factory, it can execute only the following instructions:
move() |
This instruction tells Karel to move forward one block to the next corner. Karel cannot move forward if there is a wall blocking its way. |
turn_left() |
This instruction tells Karel to rotate 90 degrees to the left (counterclockwise). |
pick_beeper()
|
This instruction tells Karel to pick up one beeper from the current
corner and stores that beeper in its beeper bag, which has no
limit on its capacity.
Karel can execute a
pick_beeper
instruction only if there is a beeper on that corner. |
put_beeper() |
This instruction tells Karel to put a beeper from its beeper bag
down on the current corner.
Karel can execute a
put_beeper
instruction only if there are beepers in its beeper bag. |
The empty pair of parentheses that appears in each of these commands is part of the common syntax shared by Karel and Python and is used to specify the invocation of the instruction, which is an example of a programming construct called a function because of its close relationship to functions in mathematics. When you move on to more advanced languages, your programs will include additional information in the space between the parentheses, but such information is not part of the Karel’s primitive world. These parentheses will therefore be empty in standard Karel programs, but you must remember to include them nonetheless.
It is also important to recognize that these definitions place certain restrictions on Karel’s activities. If Karel tries to do something illegal, such as moving through a wall, an error condition occurs. At this point, Karel simply stops and does not execute any further instructions.
At this point, it is helpful to play with Karel’s built-in functions to see how they work. Figure 1-1 shows the world from the earlier example along with buttons that execute each of these operations.
|
|
Use the buttons along the left side of the animation to test your understanding of how each of the instructions work. Try, for example, to apply the necessary instructions to get Karel to pick up the beeper, climb to the north edge of the world along 3rd Avenue, make its way into the cul-de-sac, and then drop the beeper there.
You might also experiment with asking Karel to perform an illegal operation. If you do, the animation will display an error message on top of Karel’s world telling you what you did wrong. You can dismiss the error message by clicking on it.
Although the metaphor of streets and avenues in a traditional grid pattern is appropriate for many Karel programs, creating interesting problems for Karel often requires thinking about the world in a different way. Consider, for example, the following world:
If you imagine yourself looking down at Karel’s world from above, you see it as a two-dimensional grid. If you change your perspective, you can imagine you are looking at Karel’s world from the side, in which case you see Karel moving along a flat surface that will soon be blocked by a wall representing a ledge that Karel must climb.
Your challenge in Animation #2 is to get Karel to pick up the beeper, carry it up over the barrier, and drop it at the center of the ledge before moving one square further to the eastern wall. The final position looks like this:
Use the buttons in Figure 1-2 to solve this problem.
|
|
As you developed the series of instructions you needed to solve the problem of moving the beeper to the ledge, you probably had to stop and think for a moment when you reached the following position:
What you want to do at this point is turn to the
right, but Karel’s collection of built-in
methods includes turn_left but not
turn_right.
As you presumably realized as you solved the problem, all is not lost
because Karel can achieve the effect of turning right by turning left
three times.
Even though it is possible to turn right by turning left
three times, doing so is neither convenient nor intuitive.
Your solution strategy would be much clearer if you could define a new
turn_right function and then use that
in your solution, just as if it were part of Karel’s standard
repertoire.
Fortunately, Karel allows you to do precisely that, as described in the
next chapter.
| Ch1 Ch2 Ch3 Ch4 Ch5 |
|