🚀 go-pugleaf

(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@mcvax