LISP 1.5 Programmer's Manual (1962) [pdf] | Hacker News Reader

LISP 1.5 Programmer's Manual (1962) [pdf]

softwarepreservation.org

123 pointskick21 comments

Every other programming language I've studied starts off showing me how to do things. As I go through this manual, I think I am seeing a language define itself from the ground up. It's kind of like chemistry; atoms to (small) molecules to functional groups to functional group transformations and onwards to bewildering complexity. I'm getting flashforwards to what this could ultimately achieve and why LISP has stayed relevant for so long.

I haven’t read it yet, but IIRC from previous discussions Thinking Forth is similar in spirit.

http://thinking-forth.sourceforge.net/

Certainly the language itself has that philosophy: a small number of constructs composed into more complex concepts.

> a small number of constructs composed into more complex concepts.

Emphasis on small; my favorite Forth quote[0] is:

  : (   41 word drop ; immediate
  ( That was the definition for the comment word. )
  ( Now we can add comments to what we are doing! )

Of course, per the original topic:

> (You [can also do that] in Lisp but they don't teach you those parts at school. They teach the pure functional parts, where you can't do things that you can in C++. Bastards.) [1]

0: philburk_pforth/fth/system.fth:12

1: http://yosefk.com/blog/my-history-with-forth-stack-machines....

If I understand [1], the author is impressed by Forth but can't commit to the mindflip required to use it. I suspect that I'll wind up in a similar place with Lisp and/or Forth but that it will be worth knowing how to solve problems by approaching them differently.

My experience is that Forth and Lisp both have a lot of useful ideas that I'd really like to take advantage of, but lack basic amenities like temporaries without LIFO semantics (Forth), control over memory layout (Lisp), static types or syntax (both).

If you liked that, you might also like one of Paul Grahams pet projects, the Bel Language: http://www.paulgraham.com/bel.html

It's a specification for a new dialect of lisp, written in lisp.

s/Bell/Bel/

Thanks, now corrected.

Thanks for the references. I've heard very good things about Forth but didn't know about Bell.

I don't have any pressing problems for these (or any other language) to solve but the conceptual differences are intriguing. I think that one has to decompose problems very differently with Lisp and Forth. It will not be as straightforward as learning a standard library and figuring out the calls.

Do people use these languages for scientific and technical computing the way one might use Matlab or Mathematica?

Earlier: the LISP I Programmer's Manual from 1960

http://history.siam.org/sup/Fox_1960_LISP.pdf

Written by the woman who implemented the ao (add one) instruction on the Whirlwind I!

https://en.wikipedia.org/wiki/Phyllis_Fox

I bought this book on Friday July 21, 1978 and learned how to program in LISP.

Simply one of the best computer books I know. I think this (or something similar to it) is the language all those toy-lisp projects should implement instead of something super minimal. It's actually useful and you learn about how lisp was actually implemented.

Is there a current implementation of 1.5?

Code in the book can easily be translated into less than 150 lines of code in a modern Lisp-like language to yield an interpreter, so someone somewhere probably has a toy implementation. But almost certainly what implementations exist are not used to implement anything practical: most languages nowadays and especially most Lisps after the publication circa 1970 of the description of the Scheme programming language scope variables lexically (unless the programmer explicitly declares the variable to be dynamically scoped).

There are a few Lisps that like 1.5 do not have lexically-scoped variables, e.g., Emacs Lisp before 10 years ago, but they dont suffer from the downward FUNARG problem that 1.5 has: in 1.5, if you specify an anonymous function as the argument to another function, you cannot specify any free variables in the anonymous function, which limits the expressiveness of 1.5. Or something like that. I am guessing that every one of the dozens of Lisps designed after the downward FUNARG problem was described does not suffer from the problem.

In summary, the OP is an important milestone in the history of programming-language design, but the design itself is quite obsolete.

I haven't tested it much but I did this a while ago: https://github.com/aap/l15 Unfortunately there is no compiler (yet?) but otherwise I implemented most of what is described in the manual.

It is really cool that much of this is still relevant over 50 years later.

Really? How? I learned LISP back in college, enjoyed programming in it and got into Clojure for a bit around 2014.

But there's no jobs doing it, so other than having a bit better understanding of Functional Programming, there's not much there.

I think the problem is the quality of the average software developer is pretty pathetic right now. Not only can most of them not understand FP, they have never even heard of LISP.

I have two small boxes of books that I’ve carried forward with me for several decades. Most other books come and go. This, and The Little Lisper, are among them.

I believe this was mentioned by Alan Kay as one of the programming books he recommended.

Reply on news.ycombinator.com