
The Evolution of Lisp (1993) [pdf] - tosh
https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
======
fizixer
Off-topic, just had this (micro)-epiphany that I wanted to share:

It is well-known that a majority of programmers dread mathematics beyond
something basic like high-school math, sometimes even less.

What these programmers don't know is that a significant fraction of
mathematicians (probably majority of them) who haven't been involved with
programming, computers, computer algebra systems etc, have a similar dread
about programming, in addition to the envy of programmers getting paid at much
better rates.

It's also said by many, though without universal consensus, that programming
is more rigorous than mathematics (here 'rigor' means mathematical rigor,
nothing to do with everyday usage of the term).

When you start as a math major after high school, you take computational
classes like calculus and linear algebra. Then you move on to theoretical
stuff and "high mathematics" like real analysis and abstract algebra. Then, at
an even more advanced level, you get into logic and foundations of
mathematics, and at some point you get familiarized with the concept of
constructive mathematics.

What I just realized is that programmers are essentially doing constructive
mathematics (as well as logic, to a fair degree) all along, without realizing
it, the moment they start coding!!! and yet the same programmers dread
mathematics. That is funny (although not to say it makes it any easier for
those programmers to learn all the rest of mathematics; IMO mathematics is
still harder than programming as a discipline).

I think this is one example of many, I've found over the years but can't
recall of the top of my head, where an expert of a given discipline is so
encumbered by the "underlying machinery" of their field, that they fail to see
that once they reach a higher level of abstraction, it sometimes becomes
easier, rather than harder, if you forget about the details while working at
that level, or you hadn't gone through the harder path to get there.

Another example being electrical engineers toiling through the difficult
issues of power electronics, analog and digital design, computer
architectures, instructions sets, only to find out that computer science
people, who don't know all these things, have a much easier time working at
the assembly language level, and those who don't even know assembly-language
either, have no problem just sticking to a higher level language like ruby,
javascript, and not worrying about or even aware of how the whole machinery
works.

~~~
omaranto
I doubt any of the "many" people that say that programming is more
mathematically rigorous than mathematics are mathematicians. For
mathematicians rigor is about proof and they would never say that a discipline
that usually does not involve writing proofs is more rigorous than
mathematics.

Maybe these people mean that formally verified programming is more rigorous
than mathematics. That seems reasonable, but it is a tiny part of programming,
isn't it?

(Computer science, on the other hand, particularly the subfield affectionately
called "theory", is typically mathematically rigorous.)

~~~
fizixer
What I said is along the lines of 'every program is a proof' and what people
like Philip Wadler say that we should treat propositions (essentially
theorems) as types and programs as proofs.

Now, where the mathematicians disagree-with/dislike such an idea has something
to do with the question "If a program is a proof, what is the theorem?".

Since we can have buggy programs, the norm rather than the exception, in my
opinion the program is still a proof, just not for the theorem the programmer
had in mind.

When I say programming is more mathematically rigorous, what I mean is that a
computer is way more precise at going through the program (a sequence of
statements in a formally specified language) than a human-mathematician is at
going through a proof (again a sequence of a statements in a formally
specified langauge). In fact a computer never makes a mistake (unless there is
a bug in the hardware or the compiler, i.e., something treated as an
impossibility while programming). The mistakes are still at the human end
(creating a proof/program for the wrong theorem/spec).

A second, very strong, argument in favor of programming being more
mathematically rigorous than mathematics: increasing reliance on computers for
proof checking and assistance (not even including multi-terabyte proofs that
would be impossible without a computer).

~~~
tunesmith
It doesn't really mean much, though, if the working program (proof)
corresponds to a theorem like "Given an Int, I can turn it into some other
kind of Int", or "Given some sort of String, it's possible to turn it into a
Boolean", or "Given an arbitrary input, I can yield some sort of arbitrary
output". Those theorems are rather pointless. That's what most programs "as
proofs" are like, where the value in them is in the side effects rather than
their types. Now, when dependent types become more of a thing in the industry,
maybe we can argue that our programs are getting more rigorous.

------
googoo00
This appears to be an attack file.

Objects with Javascript code (34): [10, 16, 18, 22, 26, 30, 38, 44, 50, 56,
64, 70, 88, 94, 98, 120, 126, 132, 136, 138, 144, 161, 165, 167, 169, 174,
176, 180, 182, 184, 192, 214, 221, 225]

Recommend pdftops!

~~~
jgalt212
someone please elaborate on this.

------
yumaikas
Is this current, or can we get a (date) on this?

~~~
auvi
Published in 1993

~~~
dang
Ok, added. Thanks all.

