steven@boring.UUCP (02/25/86)
(I am speaking as someone who has taught introductory programming with
several different languages, including Pascal, and who is now involved in a
project designing a new programming language for 'non-professional'
programmers (which includes students)).
In my view, an introductory programming course should teach as much as
possible about algorithms and programming, and as little as possible about
the nuts and bolts of programming languages. The programming language used
should therefore support this as much as possible by allowing algorithms to
be expressed as closely as possible to their formulation, without the
language imposing itself too much.
Furthermore, the language should help the student and teacher as much as
possible, by reducing the need for the student to ask about trivial matters
(a better syntax for Pascal or C for instance would reduce problems with
semi-colons). Strong typing for example is a boon to teachers (I believe)
because many problems are picked out far earlier and can be solved by the
student without reference to the teacher.
So, an introductory language should have several basic properties:
- It should be simple
So that as little time as possible is spent teaching the language, and as
much as possible on teaching programming.
- It should have a simple syntax
For the same reasons. An editor that flags syntax errors as you type them
in would be a great time saver and educational tool too.
- It should be high level
To take the emphasis away from the machine, and put it on the algorithms
- It should be structured
For expressing algorithms
- It should have strong typing
and other static checks, to detect errors earlier, and speed up
development time.
An interactive system is also far more helpful than a batch one.
A language that satisfies these requirements is B (the new one, NOT the
predecessor to C): it is simple (only 2 basic types, and 3 structured ones),
has a simple syntax (without semicolons) with an editor that does a lot of the
syntax work for you (no missing brackets for instance), it is high level and
structured, has strong typing (without declarations: it checks that all uses
are consistent), and it is interactive.
As an example of what I mean, consider what would be necessary to teach in
Pascal or C in order to be able to teach about garbage collection, and how
long a program simulating it would be, and how long it would take a student
to write.
Here is a program in B to do it. B has numbers and texts (=strings) and
(sorted) lists. So {1; 4; 9; 16; 25} is a list of numbers, and
{"cow"; "goat"; "dog"} a list of texts. Tables are a generalisation of
arrays: the indexes and elements may be of *any* type, so:
PUT {} IN graph
initialises the variable 'graph' with an empty table
PUT {1; 45; 61} IN graph[2]
PUT {8; 27; 96; 125} IN graph[61]
adds two elements to the table. Lists can be updated:
INSERT 42 IN graph[2]
REMOVE 61 FROM graph[2]
WRITE graph[2]
{1; 42; 45}
The keys (=indexes) of a table can be got as a list:
WRITE keys graph
{2; 61}
So here is the garbage collection program. The store is a graph, represented
by a table where each index represents the 'address' of a data-object, and
the element associate with that index is a list of addresses that that
data-object references. The program is a function that takes such a graph,
and a root node, and returns the graph with all nodes not reachable from the
root deleted. It works by first collecting the addresses of all nodes
reachable, and then deleting those not in that list.
YIELD graph accessible'from root:
MARK
SWEEP
RETURN graph
MARK:
PUT {root}, {root} IN accessible, to'do
WHILE to'do > {}:
SELECT'NODE
TREAT'NODE
SELECT'NODE:
PUT min to'do IN node
REMOVE node FROM to'do
TREAT'NODE:
FOR sub'node IN graph[node]
IF sub'node not'in accessible:
INSERT sub'node IN accessible
INSERT sub'node IN to'do
SWEEP:
FOR node in keys graph:
IF node not'in accessible:
DELETE graph[node]
B is actually in use in a couple of schools in the Netherlands, with some
others planning it. The major problems are that the implementations are not
really fast enough for large groups of students on one machine (though the
Dutch schools are doing this; on personal computers it is fast enough for
education), and there are not (yet) any introductory text-books.
Steven Pemberton, CWI, Amsterdam; steven@mcvaxjimc@ucla-cs.UUCP (02/28/86)
In article <6796@boring.UUCP> steven@mcvax.UUCP (Steven Pemberton) writes: >In my view, an introductory programming course should teach as much as >possible about algorithms and programming, and as little as possible about >the nuts and bolts of programming languages. The programming language used >should therefore support this as much as possible by allowing algorithms to >be expressed as closely as possible to their formulation, without the >language imposing itself too much. > I certainly agree. A family member learning programming started out going through chapter 1 of Kernighan and Ritchie, and learned a lot, but started getting bogged down when algorithm design started to dominate the programming task. She started an intro to DP class, in which was assigned "Karel the Robot" by (sorry, book not at hand). It turned out to be a VERY effective introduction to structured programming and algorithm design, with all the messes of math, data types, etc.etc. stripped away. The idea is, there's this programmable robot which can move, pick up objects, iterate... An emulator for the robot is available, sort of as shareware i.e. not free (see the book for address). But it's quite practical to emulate the robot by hand. -- James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU