Adrian Howard writes in <4460.9503031238@percy.cs.bham.ac.uk>
> In some respects the distinction between "systems" and "non-systems"
> programming languages is a historical one. Languages such as LISP and
> Pop-11 used to be far to inefficient in time and space to be used for
> system tasks. Now, with faster machines, cheaper memory, and improved
> compiler technology this is less true.
> Oh, I should also mention that ancestors of Pop were used as "systems
> programming languages". If fact I think I am correct in saying that
> Multipop was one of the first multi-user time sharing environments in the
> world!
As Adrian says, Multipop-68, which we developed in Edinburgh, was an early
time-sharing system. It was far from being the first; it was inspired by
Project MAC at MIT, via. a "MiniMac" project which was aborted when it
became obvious that Elliot Brothers Ltd. could not supply the necessary
disc storage. Multipop was, would argue, highly efficient in its
utilisation of machine resources to support symbolic programming (and
effective - e.g in supporting the development of the Boyer-Moore theorem
prover and of Burstall and Darlington's transformation work).
What it was NOT good at was supporting the user programs which were then
the standard fare of computing, e.g. matrix inversion. This arose from the
fact that while the POP-2 compiler generated good code for function call
(which is a lot of what layered systems like operating systems DO) it did
not generate efficient code for arithmetic or store access, because there
was no way to police the generation of illegal objects statically.
(Hindley-Milner type checking did not exist). Indeed, since many OS
features like file-access were performed by function-call (of a
closure) rather than an OS call requiring a context switch, POP-2 actually
gained.
Multipop68 was efficient primarily because the one language, POP-2
served all purposes: it was the command language for the operating system
as well as being the only available programming language. Thus there was
no need to swap in compilers etc.. And all store management was
accomplished uniformly by the garbage collector, as opposed to having store
management for the OS + store management for each application.
It has to be admitted that there WAS a substantial amount of assembler code
in Multipop68. This was primarily the interrupt handling stuff, and it is
difficult to handle this without a real-time garbage-collector.
However, the original mini-computers were very small. So, while POP was
efficient at supporting a user-community on a machine of c. 200Kbytes, the
conventional compile-load-run architecture came to dominate mini-computing.
Hence Unix and C. But it ought to be out-of-date now.
There are, however, some real differences between how you write
complex applications in C, C++, versus how you write them in
LISP,POP,.... Primarily, with C, you have a tabula-rasa with respect to
your data-structures: you can design them as you wish to support your
application. With LISP descendents there are powerful preconceptions.
Suppose, for example, you wanted an extra slot in every list-cell. You
would have to rebuild the entire language implementation, and probably
break it.
Robin Popplestone.
|