🚀 go-pugleaf

Like everyone else over here, I'm missing the (initial) context, but I
found this interesting:

In article <1990Oct8.135551.21639@arnor.uucp>
lowry@lusitania.watson.ibm.com (Andy Lowry) writes:
>I personally have written a great deal of code in Hermes and have
>found the lack of pointers to be no hindrance.
[...]
>Of course, our compiler and run-time system make heavy use of pointers
>and shared data for reasons of efficiency, but this is completely
>hidden from the Hermes programmer.

	In other words, here is a construct which is incredibly
useful for writing compilers and other programs, but which the
ordinary programmer is unable to use.

	I don't think languages should hide useful abstractions
from programmers;  they should hide annoying concretions instead.
I don't really want to know the machine address of a variable,
or how to represent a conditional jump in machine code, or which
registers need to be saved over a procedure call.  But I do want
to be able to express within my language all the abstractions
that naturally arise in modelling my problem.  These may well
include pointers ["keep a finger on that variable"], even when
there are no `data structures' around.

	When, as a mathematician [well, as a game player, really],
I think of a tree or a graph, I think naturally and easily of each
node as being some information plus a collection of pointers to other
nodes.  I draw them that way.  You may think of them differently;
but I think I should be allowed, within my chosen language, to program
them my way, and not have to pummel them into some other shape.

	Yes, of course compile-time checking is a Good Thing, but
the semantics that enable this should work with rather than against
the programmer.  Run-time checking is also a Good Thing;  if doing
it causes efficiency problems, then compilers and hardware need to be
better.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk