ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine
- Document
- 1 January 1966
- Event
- 1 January 1966
- Retrieved
- 16 September 2026
The conversation
Joseph Weizenbaum described his program in a paper titled "ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine", published in the January 1966 issue of Communications of the ACM while he was at MIT. The paper explains a program running on MIT's MAC time-sharing system that carried on typed exchanges with a user. Its best-known script, called DOCTOR, cast ELIZA as a Rogerian psychotherapist, a choice Weizenbaum says he made because that interview style lets the program's correspondent assume it "knows almost nothing of the real world" without seeming evasive. A user might type "I am very unhappy these days," and the program would answer with a templated question built from the same words, such as "How long have you been very unhappy these days?"
What the documents show
The paper, confirmed by the publisher's own catalog record as Communications of the ACM, volume 9, issue 1, sets out ELIZA's method mechanically: keyword identification, decomposition rules that split an input sentence into parts, and reassembly rules that recombine those parts into a reply. A script, the set of keywords and transformation rules, is data the program reads rather than code the program contains; the same engine could run other scripts on other topics. Weizenbaum states that some correspondents were "very hard to convince" the DOCTOR script was not human, calling this "a striking form of Turing's test," while stressing the program's task was pattern matching, not comprehension.
The system boundary
Weizenbaum's account draws the boundary precisely: ELIZA "throws away each of its inputs," except for the few sentences a MEMORY mechanism stores for later reuse, and he writes that the program's design had "as one of its principal objectives the concealment of its lack of understanding." There is no fallback operator and no escalation path, because ELIZA was a research demonstration rather than a service; the boundary is architectural rather than procedural. Genuine understanding, Weizenbaum argues, would require a program able to "draw valid conclusions from what it is being told," which needs storing and reasoning over information ELIZA discards by design.
Where it fails
The paper's most consequential warning is aimed at the reader: Weizenbaum writes that ELIZA shows "how easy it is to create and maintain the illusion of understanding, hence perhaps of judgment," and argues a more useful successor would need to reveal its misunderstanding rather than conceal it. A builder reusing the pattern-matching approach inherits that same risk of manufactured credibility.
- Does the interface disclose, unprompted, that responses come from pattern matching rather than comprehension?
- What does the system do with information it cannot act on, and does it say so, or paper over the gap the way a scripted interview can?
- Would the design, fully explained to the user, still produce the same impression of being understood?
Weizenbaum's own answer, decades before today's conversational systems, was that mechanism explained plainly loses its magic; that test is worth applying to any script or model that manages a similarly persuasive illusion.
Sources & reading trail
Weizenbaum's own full text describing ELIZA's keyword/decomposition/reassembly method, the DOCTOR script's Rogerian design, and his warnings about the 'illusion of understanding.'
Source published: 1 January 1966 · Retrieved: 16 September 2026
ACM's own catalog record confirms Communications of the ACM, volume 9, issue 1, January 1966; accessed via Wayback Machine because the live ACM page blocks automated retrieval.
Source published: 1 January 1966 · Retrieved: 16 September 2026
Documentation, rulings and incident records establish the entry; the boundary reading is Chatbot Field Guide editorial analysis. This retrospective draft does not imply the site published on the event date.