Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Summary: try Pop-11
Keywords: resistance to lisp
Message-ID: <1028@syma.sussex.ac.uk>
Date: 27 May 89 07:40:06 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 128

I can't resist reacting to this (sorry Jeff)

jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

> Organization: AIAI, University of Edinburgh, Scotland
>
> Lisp often ends up in competition with C.  People disagree about the
> best way to compete (become more C-like?  less C-like?), but it has
> proved difficult to convert the world to Lisp-like ways of thinking.

There is some evidence, albeit based only on a number of cases
rather than systematic research, that it is much easier to convert
people to Lisp-like ways of thinking if you give them a Lisp-like
language (with all the benefits of incremental compilation,
integrated editor, garbage collector, pattern matcher, lists,
records, arrays, tuples, etc etc) but not a lisp-like syntax.

Instead provide a syntax that is richer, more readable, and above
all more familiar to them.

I am of course, referring to Pop-11, which is far from perfect, but
has converted many C, Fortran and Pascal users to enthusiastic AI
language users on Suns, Vaxen, HP machines, Apollos, Macs (see
review of Alphapop in Byte May 1988).

I am not criticising Lisp for any intrinsic faults - just commenting
on how its syntax makes a significant proportion of experienced
programmers react.

Try putting in front of them any lisp procedure definition involving
a few nested loops and moderately long multi branch conditionals
with 'else' clauses. Ask them to try to understand it. Then compare
their ability to understand the Pop-11 equivalent using the sort of
syntax indicated here (in a simpler example).

    define test(item, P, Q, R, S, T);
        lvars item, procedure(P, Q, R, S, T);

        if null(item) then return(false)
        elseif P(item) then return(Q(item))
        elseif R(item) then
            if S(item) then return(item)
            elseif T(item) then return(Q(item))
            else return(item)
            endif
        else return(false)
        endif
    enddefine;

Here's how you let the variables x, and y, iterate over the elements
of lists L1 and L2 in Pop-11, so that you can apply function f to
one element from each list:

    for x, y in L1, L2 do
        f(x,y)
    endfor;

This kind of syntax, with all the extra syntax words, is often more
verbose than Lisp, and parsing by machine is more complex. But the
explicit use of distinctive opening and closing brackets "endif",
"endfor" etc, and sub-syntax words like "do", "elseif" and "then"
seems to add redundancy that is better suited to HUMAN readers
(apart from those already familiar with lisp, of course), and it
also allows the compiler to help you more if you put a closing
bracket in the wrong place. You get an error message saying
something like

    MSW: MISPLACED SYNTAX WORD : FOUND endwhile READING TO endif

instead of a program that compiles and then behaves oddly.

I think the key factor is reducing the load on short term memory.
In Pop-11, like many non-AI languages, the form:

    elseif ..... then .....

makes the context clear without your having to remember or scan back
to the beginning of the conditional expression, whereas in standard
Lisp syntax

    ((.....) (.....))

could mean almost anything, depending on the context: to work out that
it is part of a conditional one has to look back to the beginning of the
expression for the keyword "cond".

More generally "(x y z)" in LISP could, depending on context, be a
procedure call, a set of formal parameters, a set of local
variables, a list of three atoms, a condition in a conditional, the
consequent of a conditional, and so on.

By contrast, POP-11 uses a large variety of keywords to distinguish
syntactic contexts, instead of relying so much on POSITION to
determine significance. Parentheses are used for procedure calls in
the normal way, but distinct brackets are used for list expressions
"[...]" and vectors "{...}" and this also helps to reduce cognitive
load during reading. (This sort of thing is particularly important
when large programs have to be maintained by programmers who were
not the original authors.)

Please note that I am not saying that Pop-11 has the perfect syntax,
only (a) I've met quite a lot of programmers who had been put off
Lisp but have found Pop-11 very attractive and (b) this is to be
expected and explained because lisp is syntactically elegant and
economical whereas Pop-11 is syntactically rich and redundant.

I conjecture that far far more programmers around the world would be
using AI tools for all kinds of software development if the AI
community had been pushing Pop-11 at least as a way of getting into
AI. Turning to Lisp after having learnt AI techniques through Pop-11
is often quite successful.

As for C - well it is popular despite having a comparatively poor
syntax (and usually deadfully unhelpful compiler error messages),
but that is partly because it is a much simpler language than either
Lisp or Pop-11, and so there is much less to learn, and much less
for the syntax to distinguish.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QN, England
    INTERNET: aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk
              aarons%uk.ac.sussex.cogs%nsfnet-relay.ac.uk@relay.cs.net
    JANET     aarons@cogs.sussex.ac.uk
    BITNET:   aarons%uk.ac.sussex.cogs@uk.ac
        or    aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu
    UUCP:     ...mcvax!ukc!cogs!aarons
            or aarons@cogs.uucp