KAREL THE ROBOT
LEARNS JAVA
Eric Roberts
Department of Computer Science
Stanford University
September 2005
Chapter 1
Introducing Karel the Robot
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 Capek, whose 1923 play R.U.R. (Rossum’s Universal
Robots) gave the word robot to the English language.
Karel the Robot was quite a success. Karel was used in introductory computer science
courses all across the country, to the point that Rich’s textbook sold well over 100,000
copies. Many generations of CS106A students learned how programming works by
putting Karel through its paces. But nothing lasts forever. In the middle of the 1990s, the
simulator we had been using for Karel the Robot stopped working. We were, however,
soon able to get a version of Karel up and running in the Thetis interpreter we were using
at the time. But then, a year ago, CS106A switched to Java, and Karel again vanished
from the scene. For the last three quarters, the hole in the curriculum left by Karel’s
departure has been competently filled by Nick Parlante’s Binky world, but it seems about
time to bring Karel back. The new implementation of Karel is designed to be compatible
with both Java and the Eclipse programming environment, which means that you’ll get to
practice using the Eclipse editor and debugger from the very beginning of the course.
What is Karel?
Karel is a very simple robot living in a very simple world. By giving Karel a set of
commands, you can direct it to perform certain tasks within its world. The process of
specifying those commands is called programming. Initially, Karel understands only a
very small number of predefined commands, but an important part of the programming
process is teaching Karel new commands that extend its capabilities.
When you program Karel to perform a task, you must write out the necessary
commands in a very precise way so that the robot can correctly interpret what you have
told it to do. In particular, the programs you write must obey a set of syntactic rules that
define what commands and language forms are legal. Taken together, the predefined
commands and syntactic rules define the Karel programming language. The Karel
programming language is designed to be as similar as possible to Java so as to ease the
transition to the language you will be using all quarter. Karel programs have much the
same structure and involve the same fundamental elements as Java programs do. The
critical difference is that Karel’s programming language is extremely small, in the sense
that it has very few commands and rules. It is easy, for example, to teach the entire Karel
language in just a couple of hours, which is precisely what we do in CS106A. At the end
of that time, you will know everything that Karel can do and how to specify those actions
in a program. The 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.
In sophisticated languages like Java, there are so many details that learning these
details often becomes the focus of the course. When that happens, the much more critical
issues of problem solving tend to get lost in the shuffle. By starting with Karel, you can
concentrate on solving problems from the very beginning. And because Karel encourages
imagination and creativity, you can have quite a lot of fun along the way.
2
Karel’s world
Karel’s world is defined by streets running horizontally (east-west) and avenues running
vertically (north-south). The intersection of a street and an avenue 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 sample Karel world is shown below. Here
Karel is located at the corner of 1st Street and 1st Avenue, facing east.
123456
1
2
3
4
Several other components of Karel’s world can be seen in this example. The object in
front of Karel is a beeper. As described in Rich Pattis’s book, 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
is always bounded by walls along the edges, but the world may have different dimensions
depending on the specific problem Karel needs to solve.
What can Karel do?
When Karel is shipped from the factory, it responds to a very small set of commands:
move() Asks Karel to move forward one block. Karel cannot respond to a
move() command if there is a wall blocking its way.
turnLeft() Asks Karel to rotate 90 degrees to the left (counterclockwise).
pickBeeper() Asks Karel to pick up one beeper from a corner and stores the beeper
in its beeper bag, which can hold an infinite number of beepers. Karel
cannot respond to a pickBeeper() command unless there is a beeper
on the current corner.
putBeeper() Asks Karel to take a beeper from its beeper bag and put it down on
the current corner. Karel cannot respond to a putBeeper() command
unless 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 Java and is used to specify the invocation of the
command. Eventually, the programs you write 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 several of these commands place restrictions on
Karel’s activities. If Karel tries to do something illegal, such as moving through a wall or
picking up a nonexistent beeper, an error condition occurs. At this point, Karel displays
an error message and does not execute any remaining commands.
Karel’s commands, however, cannot be executed on their own. Before Karel can
respond to any of these commands, you need to incorporate them into a Karel program.
3
You will have a chance to see a few simple Karel programs in Chapter 2, but before
doing so, it is useful to make a few general remarks about the programming philosophy
that underlies this particular implementation of the Karel programming language.
Karel and the object-oriented paradigm
When Karel was introduced in the 1970s, the prevailing approach to writing computer
programs was the procedural paradigm. To a large extent, procedural programming is
the process of decomposing a large programming problem into smaller, more manageable
units called procedures that define the necessary operations. Although the strategy of
breaking programs down into smaller units remains a vital part of any style of
programming, modern languages like Java emphasize a different approach called the
object-oriented paradigm. In object-oriented programming, the programmer’s attention
shifts away from the procedural specification of operations and focuses instead on
modeling the behavior of conceptually integrated units called objects. Objects in a
programming language sometimes correspond to physical objects in the real world, but
just as often represent more abstract concepts. The central feature of any object—real or
abstract—is that it must make sense as a unified whole.
One of the primary advantages of the object-oriented paradigm is that it encourages
programmers to recognize the fundamental relationship between the state of an object and
its behavior. The state of an object consists of a set of attributes that pertain to that object
and might change over time. For example, an object might be characterized by its
location in space, its color, its name, and a host of other properties. The behavior of an
object refers to the ways in which that object responds to events in its world or
commands from other objects. In the language of object-oriented programming, the
generic word for anything that triggers a particular behavior in an object is called a
message (although it generally seems clearer to use the word command in the context of
Karel). The response to a message typically involves changing the state of an object. For
example, if one of the properties defining the state of an object is its color, then it would
presumably respond to a setColor(BLUE) message by changing its color to blue.
In many ways, Karel represents an ideal environment for illustrating the object-
oriented approach. Although no one has actually built a mechanical implementation of
Karel, it is nonetheless easy to imagine Karel as a real-world object. Karel is, after all, a
robot, and robots are real-world entities. The properties that define Karel’s state are its
location in the world, the direction it is facing, and the number of beepers in its beeper
bag. Karel’s behavior is defined by the commands to which it responds:
move(),
turnLeft(), pickBeeper(), and putBeeper(). The move() command changes Karel’s
location, turnLeft() changes its direction, and the remaining two affect both the number
of beepers in Karel’s bag and the number of beepers on the current corner.
The Karel environment also provides a useful framework for defining one of the
central concepts of object-oriented programming. In both Karel and Java, it is essential to
differentiate the notion of an object from that of a class. The easiest way to understand
the distinction is to think about a class as a pattern or template for objects that share a
common behavior and collection of state attributes. As you will see in the next chapter,
the word
Karel in a Karel program represents the entire class of robots that know how to
respond to the move(), turnLeft(), pickBeeper(), and putBeeper() commands.
Whenever you have an actual robot in the world, that robot is an object that represents a
specific instance of the Karel class. Although you won’t have occasion to do so in
CS 106A , it is possible to have more than one instance of the Karel class running in the
same world. Even when there is only a single robot, however, it is important to remember
that object and class are different concepts and to keep those ideas straight in your mind.
