Written by Peter Deutsch, then a then-high school student on a tiny 4K (admittedly, 4K 18-bit words) machine. Amazingly usable - and lives on in the Python REPL concept.
Posting this in the hope that someone will feel triggered to backport Eliza, it was done in the 1960s but it's been lost :-)
blooalien•Jun 30, 2026
> Posting this in the hope that someone will feel triggered to backport Eliza, it was done in the 1960s but it's been lost :-)
Some of us who remember actually playing with Eliza are absolutely amused by all the hype around LLMs (because it's so similar to the hype heard from "normies" who saw Eliza and thought we were "just around the corner from real AI"; The same folk who thought we'd all have a flying car in every garage by now, LOL!). Still really impressed by what LLMs actually can do though, despite them being not much closer to true "thinking machines". ;)
ozymandiax•Jun 30, 2026
When we visited some of the 1970s 'heros' of the MIT AI Lab, we were told the informal story behind SHRDLU, the AI living in a PDP-10 3D world. How this graphical AI triggered the first AI Summer --
-- and as it fell short of first impressions, perhaps the first winter too?
blooalien•Jun 30, 2026
Fun times, gettin' in early on the "tech scene" and watching it progress so quickly (yet at the same time so slowly in many ways compared to how it could have gone had greed and ignorance not held it back by decades). :)
ozymandiax•Jun 30, 2026
I was born too late (not a bad thing necessarily) to have experienced that founding era. But I think that for later generations, there's a lot to learn still from what evolved in the earliest years. We've gained a lot since then, but we also lost a lot. Mean and lean programming, closeness to the hardware, inventiveness. And the liberating absence of 'software stacks'...
It's fascinating how on such a tiny computer, something like a comfortable interactive Lisp just emerged. Relatively comfortable.
pjmlp•Jun 30, 2026
Which is yet another reason to folks open their minds to what is actually possible on their super computers, instead of thinking only C and similar languages will deliver.
We already have it running on the PDP-10 reconstruction, and it is known that people around Deutsch at BBN ported it back to the PDP-1. But that version has been lost. From the link you gave, a backport would be feasible... especially because the PDP-1 simulator has the full memory upgrade to 64Kw!
>Posting this in the hope that someone will feel triggered to backport Eliza, it was done in the 1960s but it's been lost :-)
you can run eliza in emacs, just " M-X doctor " enter
ozymandiax•Jun 30, 2026
But we'd need to backport emacs to the PDP-1 then :-)
AdieuToLogic•Jun 30, 2026
> Posting this in the hope that someone will feel triggered to backport Eliza, it was done in the 1960s but it's been lost :-)
When in doubt, there is always the option to implement Eliza in a Forth[0] embedded within a dish washing machine's firmware. It could converse about one's thoughts regarding pre-soak techniques. :-)
I am very impressed by the simulator, and I really wish I could defend taking time to dig into PDP-1 programming. You make it look like an absolute blast!
> Just one little story…I remember…The name Bob Hargraves [Robert F. “Bob” Hargraves, Jr. ʻ61] should come up somewhere in this business because he was the class I think of 1962, but he was a physics major at Dartmouth. He went on to get a Ph.D. in physics. He came back to Dartmouth as associate director of the computer center many years later. At any rate, he was one of those that worked on the LGP-30 that first summer and he devised a simple higher-level language program. By todayʼs standards, it was pretty crude, but it was FORTRAN-like, you know – sort of – in just six weeks.
> One student, without any prior background in computing, prepared a simple higher level language and language processor he called DART (Hargraves, 1959). Obviously influenced by FORTRAN, but wishing to avoid scanning general arithmetic expressions, he required parentheses around all binary operators and their operands. Hardly earth-shaking, but one conclusion was inescapable: a good undergraduate student could achieve what at that time was a professional-level accomplishment, namely, the design and writing of a compiler. This observation was not overlooked.
But at the same time Edgar T. Irons https://dl.acm.org/profile/81100268091/ is in town working on ALGOL syntax, and when Kemeny and Kurtz grab the wheel back they steer language development at Dartmouth towards more syntax (Kurtz assigns four undergraduates including Hargraves to implement ALGOL 58, resulting in ALGOL 30) and more lumpen, assembler-like semantics (Kemeny's DOPE https://en.wikipedia.org/wiki/Dartmouth_Oversimplified_Progr... in particular is a pseudo-assembler.) It was definitely DART that got Kurtz interested in implementing ALGOL on the LGP-30 in the first place though—see pp. 1-2 of the ALGOL 30 report ("ALGOL for the LGP-30"): https://people.csail.mit.edu/garland/publications/Reprints/1... : "It should be mentioned that our becoming involved in this project was a direct result of Hargraves’ having devised a complete language system (DART) during the summer of 1959."
But back to the point ... an interpreter (surely) for a high-level programming language relying on explicit parentheses, written in Dartmouth, in the summer of 1959? How much did Hargraves know about at that point about the IBM 704 implementation of LISP, finished by March 1959? To be sure, I doubt that DART was anything much like a full implementation of even LISP 1, but just the idea of doing a simple interpreter for FORTRAN-like nested mathematical expressions by requiring parentheses everywhere seems familiar. (McCarthy himself was still trying to do LISP as a FORTRAN extension as late as mid-1958 https://interlisp.org/history/bibliography/gi8mchkf .)
sourdecor•Jun 30, 2026
Kind of a non sequitur: I bought "The Genius of Lisp"[0] and it is not what I thought (a book entirely devoted to the history of Lisp - from MIT to Common Lisp and then to Clojure). Would anyone recommend another book?
The PDP-1 Lisp page has 4 rather good books linked as PDFs.
Oh - but all on the earliest history of Lisp as well! That is not what you're looking for I think.
retrac•Jun 30, 2026
It's not a history book or even all that much a book about Lisp, despite its name, but Lisp in Small Pieces incidentally covers a lot of Lisp history. The book at its core is about implementing compilers and interpreters. It starts with something close to the McCarthy meta-evaluator, and the rest of the book iteratively elaborates on why the naive meval is not a practical programming language, somewhat mirroring the evolution of historical Lisp implementations in the process.
It dates to the early 90s so it doesn't touch on Clojure or anything recent. The bibliography and citation is excellent.
> Literature about Lisp rarely resists that narcissistic pleasure of describing Lisp
in Lisp. This habit began with the first reference manual for Lisp 1.5 [MAE+62] and
has been widely imitated ever since. We'll mention only the following examples
of that practice: (There are many others.) [Rib69], [Gre77], [Que82], [Cay83],
[Cha80], [SJ93], [Rey72], [Gor75], [SS75], [A1178], [McC78b], [Lak80], [Hen80],
[BM82], [CH84], [FW84], [dRS84], [AS85], [R3R86], [Mas86], [Dyb87], [WH88],
[Kes88], [LF88], [Dil88], [Kam90].
(The third one includes the source code to PDP-1 Lisp.)
ozymandiax•Jun 30, 2026
Wow! How did I manage to miss this treasure trove! Thank you.
ozymandiax•Jun 30, 2026
I was wrong - it was not Peter Deutsch who ported Eliza to Lisp, it was Bernie Cossell at BBN (one of the famous IMP Guys a few years later!). And it is here:
5 Comments
Our PiDP-1 simulator on github lets you try it out on any Linux machine (not just a Raspberry PI): https://github.com/obsolescence/pidp1
Posting this in the hope that someone will feel triggered to backport Eliza, it was done in the 1960s but it's been lost :-)
Some of us who remember actually playing with Eliza are absolutely amused by all the hype around LLMs (because it's so similar to the hype heard from "normies" who saw Eliza and thought we were "just around the corner from real AI"; The same folk who thought we'd all have a flying car in every garage by now, LOL!). Still really impressed by what LLMs actually can do though, despite them being not much closer to true "thinking machines". ;)
https://www.youtube.com/watch?v=8ZGQcJVdjj8
-- and as it fell short of first impressions, perhaps the first winter too?
It's fascinating how on such a tiny computer, something like a comfortable interactive Lisp just emerged. Relatively comfortable.
you can run eliza in emacs, just " M-X doctor " enter
When in doubt, there is always the option to implement Eliza in a Forth[0] embedded within a dish washing machine's firmware. It could converse about one's thoughts regarding pre-soak techniques. :-)
0 - https://www.forth.com/starting-forth/
> Just one little story…I remember…The name Bob Hargraves [Robert F. “Bob” Hargraves, Jr. ʻ61] should come up somewhere in this business because he was the class I think of 1962, but he was a physics major at Dartmouth. He went on to get a Ph.D. in physics. He came back to Dartmouth as associate director of the computer center many years later. At any rate, he was one of those that worked on the LGP-30 that first summer and he devised a simple higher-level language program. By todayʼs standards, it was pretty crude, but it was FORTRAN-like, you know – sort of – in just six weeks.
The HOPL BASIC paper https://dl.acm.org/doi/pdf/10.1145/800025.1198404 has more about this language:
> One student, without any prior background in computing, prepared a simple higher level language and language processor he called DART (Hargraves, 1959). Obviously influenced by FORTRAN, but wishing to avoid scanning general arithmetic expressions, he required parentheses around all binary operators and their operands. Hardly earth-shaking, but one conclusion was inescapable: a good undergraduate student could achieve what at that time was a professional-level accomplishment, namely, the design and writing of a compiler. This observation was not overlooked.
But at the same time Edgar T. Irons https://dl.acm.org/profile/81100268091/ is in town working on ALGOL syntax, and when Kemeny and Kurtz grab the wheel back they steer language development at Dartmouth towards more syntax (Kurtz assigns four undergraduates including Hargraves to implement ALGOL 58, resulting in ALGOL 30) and more lumpen, assembler-like semantics (Kemeny's DOPE https://en.wikipedia.org/wiki/Dartmouth_Oversimplified_Progr... in particular is a pseudo-assembler.) It was definitely DART that got Kurtz interested in implementing ALGOL on the LGP-30 in the first place though—see pp. 1-2 of the ALGOL 30 report ("ALGOL for the LGP-30"): https://people.csail.mit.edu/garland/publications/Reprints/1... : "It should be mentioned that our becoming involved in this project was a direct result of Hargraves’ having devised a complete language system (DART) during the summer of 1959."
But back to the point ... an interpreter (surely) for a high-level programming language relying on explicit parentheses, written in Dartmouth, in the summer of 1959? How much did Hargraves know about at that point about the IBM 704 implementation of LISP, finished by March 1959? To be sure, I doubt that DART was anything much like a full implementation of even LISP 1, but just the idea of doing a simple interpreter for FORTRAN-like nested mathematical expressions by requiring parentheses everywhere seems familiar. (McCarthy himself was still trying to do LISP as a FORTRAN extension as late as mid-1958 https://interlisp.org/history/bibliography/gi8mchkf .)
[0]: https://www.amazon.com/Genius-Lisp-Cees-Groot/dp/1069886416/
It dates to the early 90s so it doesn't touch on Clojure or anything recent. The bibliography and citation is excellent.
> Literature about Lisp rarely resists that narcissistic pleasure of describing Lisp in Lisp. This habit began with the first reference manual for Lisp 1.5 [MAE+62] and has been widely imitated ever since. We'll mention only the following examples of that practice: (There are many others.) [Rib69], [Gre77], [Que82], [Cay83], [Cha80], [SJ93], [Rey72], [Gor75], [SS75], [A1178], [McC78b], [Lak80], [Hen80], [BM82], [CH84], [FW84], [dRS84], [AS85], [R3R86], [Mas86], [Dyb87], [WH88], [Kes88], [LF88], [Dil88], [Kam90].
https://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec/d...
https://softwarepreservation.computerhistory.org/LISP/lisp15...
https://softwarepreservation.computerhistory.org/LISP/lisp15...
https://softwarepreservation.computerhistory.org/LISP/lisp15...
(The third one includes the source code to PDP-1 Lisp.)
https://github.com/jeffshrager/elizagen.org/tree/master/1966...
That makes a PDP-1 Lisp backport very tempting... amazing how ancient code comes back from presumed extinction.
But only if your language has tail recursion resolution!
But it appears to be valid in PDP-1 Lisp (though not in either Lisp 1.5 or modern Lisps). From https://s3data.computerhistory.org/pdp-1/DEC.pdp_1.1964.1026...
"Doing a CDR of an atom is permissible and will get the atom's property list. Doing a CAR of an atom may very easily wreck the system."