TEACHING PROGRAMMING: SOME LESSONS FROM PROLOG

David Callear
University of Portsmouth
Department of Information Systems
Burnaby Terrace, PO1 3AE
David.Callear@port.ac.uk
http://www.dis.port.ac.uk/~callear

ABSTRACT
Prolog (Programming in Logic) is the language of
Artificial Intelligence (AI), and is renowned as a
difficult language to learn. It embodies a
programming paradigm that is radically different
from the usual procedural languages, and even
students who find other languages easy can
struggle with Prolog. It is so different that students
have to learn it as a completely new experience,
even if they have reached a competent level in
procedural languages.
Recently more programming paradigms have made
an appearance. Currently there is a fashion for
teaching Java, much sought-after by students, who
see it as the internet language, but found very
difficult when they come to learn it, especially if they
encounter it as a first language.
This paper outlines some strategies that have been
found successful with Prolog, and extrapolates them
to the teaching of programming generally. The
suggestions are backed up by the findings of a
survey of Prolog lecturers and students carried out
in a recent project. The paper also makes
suggestions about which languages we should be
teaching, and which ones we should be teaching
first.
Keywords
Prolog, Java, Logic Programming,
Languages, Declarative Programming.

Computer

1. INTRODUCTION
Certain problems have been associated with the
teaching of Prolog, a language which has been
around since the early seventies. Many of these are
problems associated with any new language which
represents a substantial paradigm-shift. Some of the
problems are apparent with new object-oriented
Permission to make digital or hard copies of all or part of this
work for personal or classroom use is granted without fee
provided that copies are not made or distributed for profit or
commercial advantage and that copies bear this notice and the
full citation on the first page. To copy otherwise, to republish, to
post on servers or to redistribute to lists, requires prior specific
permission.
th

8 Annual Conference on the Teaching of Computing, Edinburgh

2000 LTSN Centre for Information and Computer Science

languages, particularly Java, and because of the

popularity of Java it is important to look at these
problems.
By now, the reasons for some of the problems with
Prolog can be seen and understood, and some
solutions are evident. This paper attempts to identify
the problems and suggest solutions.

2. THE BACKGROUND
Logic Programming, in the form of Prolog, is now
widely taught in UK universities. In fact it is claimed
that Prolog is taught in more UK universities than any
other programming language [1]. This may have
something to do with the fact that the opposition is
divided, but there is no doubt that Prolog is now very
well-established in academic circles.
Prolog has been used recently for programming the
database of the hugely successful Human Genome
Project. Some who have had a great deal of contact
with Prolog believed, in fact, when it appeared, that
it had the potential to become the most commonly
used programming language of all, as well as the
most widely taught. In a pilot scheme at Imperial
College which was ahead of its time, Robert
Kowalski and Richard Ennals devised a version of
Prolog for children called micro-Prolog [2]. It met
with good response, but did not gain ground in
schools because BASIC won the battle for hearts
and minds.
Prolog is gaining ground in industry, but at an almost
imperceptible pace. The faith put into it by the
academic world in teaching it on all those courses is
not mirrored to any appreciable extent in industry. The
reason is not hard to find. Students do not gain from
their courses an appreciation of Prolog.
Why are all those students studying Prolog, but failing
to be impressed by it? The inference is inescapable
that in the universities our teaching of Prolog is
inadequate, or misconceived, or both.

3. AN ANALOGY
Let us suppose for a moment that until now the world
has been without Algebra, which in fact we all learned
at school. (Algebra is not unlike a computer language,
being part of the language of Mathematics.) A group
of academics comes along with Algebra.

It is recognised immediately by thinking people that

here is a tool of enormous value and potential, and it
begins to be taught in universities. The academics
who were clever enough to invent Algebra are not
primarily teachers. They have written their theories up
in learned papers and a single book, and the people
who start to teach Algebra, mostly other academics
with little more experience of how to teach than the
originators, often with only a sketchy idea of this new
subject themselves, inevitably base their approach on
the written papers and the book, which becomes a
'bible' of the subject.
The book was intended as a medium for concisely
setting out the new subject, written by academics in
the field for other academics in the field. It was never
intended as a textbook for all abilities of
undergraduate student, coming to the subject with no
knowledge of it at all. Not surprisingly,
undergraduates following the approach of the book
see Algebra as very obscure and difficult, and they
learn it reluctantly, dreading their weekly dose.
In time people learn how to teach Algebra. It is
realised that it cannot be taught in two or three
sessions, but requires a carefully thought out course
over a year or more. Students cannot just be told in
one lecture how it works, but need to be given many
examples and exercises to do, and helped with them.
The exercises have to be structured so that students
can do them at each stage. The examples given in
the learned papers are too difficult for beginners, and
have to be left out. The mathematical jargon which
appeared in the learned papers is gradually dropped
from the subject. In time Algebra shakes off its
bogeyman image. Students of average ability can
now cope with it, and they see the usefulness of it.
Those of an intellectual disposition begin to enjoy it.
For Algebra read Prolog. For 'the papers' read, for
example, Colmerauer, [3]. For 'the book' read
Clocksin and Mellish, [4]. The basics of Prolog itself,
although still evolving, are now largely fixed, but to
use Kuhn's terminology, the teaching of the subject is
still in its pre-paradigm stage [5].

4. HOW WE MIGHT TEACH PROLOG

BETTER
There are certain conceptual steps in learning Prolog
which, if they are presented in the wrong order, or if
they are presented several at the same time, leave
the average student impossibly confused.
The first way to improve things is to spend time
introducing students to the basics. Many students
used to using compiled Pascal, for example, will not
have used an interpreter before. Many will be so used
to the idea of instructions being executed that the idea
of searching for a goal in the database takes a while
to get used to. The idea of continuing the search for
more solutions also takes time to get used to. It is
important to introduce these basic concepts slowly

enough for them to sink in. The students' confidence

needs to be built up with easy exercises.
An important topic in itself is how variables are dealt
with by Prolog, and how they are used to extract
values from the database, including use of the
anonymous variable. A medical expert system can be
constructed at this stage from facts, and queried from
the interpreter.
The introduction of rules is a major step, traditionally
attempted with examples of family relationships.
Students find this particular example a hard one, and
because it is tricky to get the logic of family
relationships right, they get the impression that rules
are hard to cope with. The textbook by Bratko [6]
opens almost on the first page with the family
database and simultaneously introduces both facts
and rules. Clocksin and Mellish [7] also introduce
facts, rules and the family database in the first
chapter.
While practising the use of rules, students can be told
how to write a 'procedural' program in Prolog, and
programs using menus. They can cover backtracking,
'fail' and 'repeat'. One of the things students find most
baffling in Prolog, if it is not explained to them, is the
use of variables in rules. They do not intuitively realise
that a variable cannot be re-assigned in a rule, a
process that is one of the mainstays of procedural
programming. It has to be explained to them that a
variable can have only one value within a particular
rule. Nor do they realise, without being told, that the
scope of a variable is only the rule it occurs in, and
values have to be passed from one rule to another as
arguments. There are no global variables such as
they are used to in languages like Pascal and C.
Another thing students have to be told, as it is not
self-evident, is that you cannot have rules defined
within rules. There are no explicit explanations of
such points as these in common textbooks like
Clocksin and Mellish and Bratko.
Recursion, an essential tool of Prolog, can come
several weeks into the course. Bratko introduces it
unheralded halfway through the first chapter. Neither
Bratko nor Clocksin and Mellish accord recursion a
chapter to itself, and it does not appear in the
contents of either book as such, even as a subsection. It just pops up during a discussion of
something else. Repetition is one of the most
essential programming tools, but students anxious to
find out how it is achieved in Prolog have to go on a
lengthy treasure hunt.
A big conceptual step to students of Prolog is when
they encounter lists. The syntax of lists is simple, but
many of the commonest list manipulation routines
involve all the techniques learned so far at once, like
use of variables, recursion and backtracking. It is
essential that a student has a good grounding in
everything else before starting on lists.
The two books mentioned, charging along at
breakneck speed, both get onto lists in chapter three

(they have 11 and 16 chapters in all). Admittedly

Bratko attempts to cover a lot of AI as well as just
Prolog in his book, but in each case lists are covered
before discussing such things as backtracking,
asserting and retracting, and input and output, all
conceptually much simpler.

5. SOME RULES OF THUMB FOR

TEACHING COMPUTER LANGUAGES
Prolog is considerably different from most other
languages, and thus offers an opportunity to examine
student learning afresh, independently of prior
experience of programming. The following rules,
which would seem to apply to the learning of any
computer language, can be proposed:
(a)

(b)

They need to be taught at an appropriate

pace, which usually means fairly slowly,
allowing time for new concepts to sink in.
They need to be taught one topic at a time;
introducing several concepts at once, or very
close together, confuses students.

(c)

Topics need to be returned to and rehearsed

by means of frequent exercises, at a suitable
level.

(d)

Ordering of topics is important; simple topics

whose understanding is required for more
complex topics need to be taught first.

(e)

Easier topics should be taught first to build up

confidence.

These simple rules seem almost self-evident, but

most programming textbooks do not follow them,
because they do not really set out to be textbooks for
students, but manuals on the language. Perhaps
authors regard it as the job of the lecturer to put the
material into a suitable teaching order, but many
lecturers will not do this, but will take their teaching
order from the textbook they decide to use. Also,
many students largely teach themselves from the
recommended textbook, and follow its order.

6. TESTING THIS APPROACH

The textbook Prolog Programming for Students [8]
attempted to put this approach into practice. The aim
was to try to popularise Prolog with a book which was
(a) affordable and (b) understandable by students. I
have taught Prolog for the last seven years or so
using this approach.
Four years ago a final year degree student carried out
a survey to investigate various aspects of teaching
Prolog (G. Collier, unpublished final year dissertation,
Department of Information Systems, University of
Portsmouth, 1996). It is possible to use some of the
data of this project, and additional data which the
student did not receive in time to include, to compare
the usual non-structured AI approach to teaching
Prolog with a more structured approach as outlined
above.

Taking students from three universities who had

chosen Prolog to study as an option subject, and who
thus had an interest in it at the start, Figure 1 shows
the students subjective opinions of the hardness of
seven topics in Prolog. The blocks of the histogram
represent student gradings on a scale 1 to 5, which
can be described as easy, fairly easy, average, fairly
hard, and very hard, with the structured approach on
the left, and the non-structured approach on the
right. The sample sizes were 21 and 41 respectively,
and the figures have been converted to percentages
for comparison. The graph puts together 423
separately made gradings.
35
30
25
20
15

Structured

10

Non-Struct

5
0
Very
Easy

Very
Hard

Figure 1

While the distribution for the structured approach is

fairly normal, but skewed towards the students finding
the subject easy, that for the non-structured approach
is an odd distribution, the students appearing to find
the easy topics very easy, and the harder topic very
hard.
40
35
30
25
20

Structured

15

Non-Struct

10
5
0
Very
Easy

Very
Hard

Figure 2

A similar graph for the three hardest topics, which

were found to be backtracking, recursion and lists, is
shown in Figure 2. This graph puts together 178
separately made gradings, and shows a clear trend;
while the data is still fairly normally distributed for the
structured approach, a much higher proportion of the
students taught by the AI approach found the hard
topics very hard.
Where students had been taught another computer
language, they were also asked to say how the
teaching methods compared in Prolog and the other

language, again on a five point scale, with Prolog on

the left and the other language(s) on the right. Figure
3 shows the results of this exercise, with sample sizes
of 15 and 37.
60
50
40
30

Structured

20

Non-Struct

10
0
Prolog

Other
Langs

Figure 3

Although this is a fairly crude measure, with no

coaching of the students, for example, in what should
constitute teaching methods, it indicates that the
students who were taught by the structured method
had a more favourable view of the way they had been
taught.

7. THE CASE OF JAVA

Recently Java has become enormously popular as a
language for students in universities. This popularity is
largely application led. Java is used for web
programming; the web is the latest highly successful
computing development; and students want to learn
Java so as to get into the exciting and lucrative world
of web programming and design.
Nearly all universities have found that they have had
to introduce Java courses, in response to student
demand. However, it is a common experience that
students who have been anxious to learn Java find it
very difficult to master, having tried it. Java is based
on C syntax, but includes object-oriented features
which originated with Smalltalk. Students have
difficulty with both C, which was designed purely as
an
application
language
for
professional
programmers, and with Smalltalk, which was
designed to put certain programming principles into
practice and with little thought of students. It is not
surprising that students should struggle with Java.
This is not so hard for students who have cut their
teeth on other languages, like Pascal, Ada or C, but in
many universities a decision has been made to cut
out Pascal, which was partially designed as a
teaching language, in favour of using Java as a first
language. It seems that most Java textbooks, if they
are actually designed with the students in mind at all,
are not intended to introduce students to
programming for the first time.
As an example, objects in Java are essentially
programs, saved as separate files, which can send
data to each other. It would seem sensible if teaching
Java as an introduction to programming to explain

what a program is, and give some grounding in writing

simple programs or objects, before going on to the
more complex subject of how collections of programs
link with each other.
The large majority of Java books which claim to be
introductions to programming do not do this. (It is not
always clear from the titles whether a book is an
introduction to programming using Java or an
introduction to Java programming). See, for
example, Farrell [9], Decker and Hirshfield [10],
Harrington [11], Horstmann [12], Wu [13], Garside
and Mariani [14], Kamin, Reingold, and Mickunas [15]
and Winder and Roberts [16], which all have chapters
on classes, methods and objects right at the start,
before they deal with basics like repetition, strings and
arrays. The publishers sales material for Winder and
Roberts, in fact, makes a big play of objects up front
and an objects early approach. There are many
more books on Java which on closer inspection are
not intended to be introductory programming texts,
but which could easily be mistakenly used as such.
Publishers naturally do not warn against such use, in
the interests of greater sales. One book which does
use a common-sense, structured approach, however,
genuinely aimed at first-time students, is the excellent
Holmes [17].
Object-oriented language advocates may disagree,
but the use of Java as an introductory language at all
is more than questionable. My own department
considered this strategy, but at a memorable staffstudents meeting the students themselves advised
against it, suggesting using Pascal (long abandoned
by the department as yesterdays language) as a
good introductory language. If Java must be used
thus, then the Holmes approach, following the
approach outlined above, is surely preferable to that
of the others.

8. SOME CONCLUSIONS
A predictable process is repeated fairly regularly when
a new language comes along. The language is used
by those who invented or designed it; its use spreads
to other academics; books are written, by academics
for other academics; the language begins to be
taught; it is taught by academics who base their
teaching on the academic books; students struggle
with the language; books begin to be written for
students, in simpler language but keeping the same
structure as the academic books; only after some
years do books appear which are properly structured
for learning the language.
A book setting out the credo of a new language tries
to show its structure, its differences from other
languages, and its advantages. It aims to set out
everything in the language and often resembles a
specification. A book for students, on the other hand,
should present things in a sequence of steps of
gradually increasing complexity and difficulty. The

order of topics and the speed of progression are allimportant.

[6] Clocksin, W. F. and Mellish, C. S. Programming

in Prolog, Springer-Verlag (1984).

Our present approach to teaching most computer

languages seems to be like teaching people to swim
by throwing them into a deep pool and letting them
find out. It works with very determined students, but
there is a high casualty rate of less able ones, and in
many cases, even if they survive, it prejudices them
against the subject for life.

[7] Callear, D. H., Prolog Programming for

Students, DP Publications (now Letts), London
(1994).

9. REFERENCES
[1] Scowen, R., Prolog Standard, paper at
Conference on Industrial Exploitation of Prolog,
organised by ALP-UK, at DTI Offices,
Buckingham Palace Road, London (1993).

[8] Farrell, J. M., Java Programming Introductory,

Thomson Publishing (1998).
[9] Decker, R. and Hirshfield, S., Programming
Java: An Introduction to Programming Using
Java, Thomson Publishing, London (1998).
[10] Harrington J. L., Java Programming: An IS
perspective, Wiley, London (1998).
[11] Horstmann, C., Computing Concepts with Java
Essentials, Wiley, London (1997).

[2] Ennals, J. R. Beginning micro-Prolog, Ellis

Horwood Ltd., and Heinemann Computers in
Education Ltd. (1983).

[12] Wu, T., An Introduction to Object Oriented

Programming
with
Java,
McGraw-Hill,
Maidenhead, Berkshire (1999).

[3] Colmerauer, A., Les systemes-Q ou un

Formalism pour Analyser et Synthesiser des
Phrases sur Ordinateur, Publication Interne No.
43, Dept. dInformatique, Universite de Montreal,
Canada (1973).

[13] Garside, R. and Mariani, J., Java: First Contact,

Thomson Publishing, London (1997).

[4] Kuhn, T. S., The Structure of Scientific

Revolutions, University of Chicago Press (1962).
[5] Bratko, I., Prolog Programming for Artificial
Intelligence, Addison-Wesley (1986).

[14] Kamin, S. N., Reingold, E. and Mickunas, D.,

An Introduction to Computer Science Using
Java, McGraw-Hill, Maidenhead, Berkshire
(1998).
[15] Winder, R. and Roberts, G., Developing Java
nd
Software, 2 Edition, Wiley, London (1999).
[16] Holmes, B., Programming with Java, Jones and
Bartlett Publishers, London (1998).