16 Feb
2018
16 Feb
'18
4:26 p.m.
On 16 Feb 2018, at 02:41, Larry McVoy <lm(a)mcvoy.com> wrote:
I don't know all the details but lisp and
performance is not a thing.
What this actually means is three things.
(1) Once upon a time, a very long time ago, there may have been some implementations of
Lisp-family languages which, because people didn't know much about writing compilers
or memory management systems in the early 1960s, were significantly slow compared to
hand-written assembler or FORTRAN. This problem got solved in the 1970s and 1980s as
people learnt about compiling high-level languages and about how to manage memory
efficiently.
(2) The most distinctive (but never the only) compound data structure in Lisp-family
languages is the singly-linked list (which Lisp calls just 'lists').
Incompetent or poorly-taught programmers make use of lists without understanding their
performance characteristics (particularly they treat them like arrays), and this can
result in programs which have terrible performance characteristics: they're slow and
they scale poorly. This is made worse because Lisp is an enormously safer language than,
say, C. This means that incompetent programmers can make their programs work *at all*
which, in C, would be a mass of memory errors.
(3) People use Lisp-family languages to solve hard problems, such as 'attempt to show
that this metric in GR describes the same spacetime as this other metric'. Problems
which don't *have* general solutions and whose heuristic solutions involve enormous
amounts of computation, much of it speculative as the program searches for ways of
simplifying expressions. These programs are 'slow' in the sense that it takes
them many minutes to do what a human can spend three years getting a PhD doing (oh, and
the program finds that the human made some mistakes).
The end result of this is that a myth grows up: 'Lisp is slow'. This might have
been true once, although even that is doubtful: like cannibals, it turns out that the
implementation you can find was never, really, slow, but always, just across the river,
over the hills, there was another implementation, which was.
But still the myth persists: it will always persist.
--tim