back
85 comments
My company bought me a Xerox 1108 Lisp Machine running Interlisp D in 1982. I write a commercial product for that environment that we sold for $5K, and it was a lot of fun. I run the latest Medley releases occasionally just for nostalgia. For present day hacking enjoyment I go with SBCL Common Lisp+Emacs, or Racket, or Python when I need the ecosystem.

Xerox really did a great job creating their Lisp Machines, a joy to develop on.

I often fantasize about a world where lisp or smalltalk machines took off instead of the Windows/Linux we have now. I know things weren't perfect, but it just seems like such a cool system and that we've evolved in a much less powerful direction.
We almost had it in OS/2, I guess many aren't aware that Smalltalk was kind of ".NET for OS/2" during its heyday.

Hence why it is a first party on SOM (OS/2 COM version), and SOM does support metaclasses.

But then OS/2 went as we all know, and with IBM's backing of Java, Visual Age products turned into Eclipse.

http://www.edm2.com/index.php/VisualAge_Smalltalk

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

In 2000, I worked for a company that had been acquired by IBM. When I discovered that I had access to things like VisualAge, APL, OS/2 I had a blast downloading and exploring these.

You're right; there was a pretty good vision for the future within IBM back then. It just didn't catch on.

I'm curious, how do you feel about PowerShell?

I think it's quite amazing in that it's basically the scripting language for dotnet. I love that it allows for interactive usage of dotnet libraries.

To me it has the feel of a lot of the dynamic languages from the past, but in a framework that acknowledges types.

I've been using it for finance/economic data stuff lately. For example:

https://github.com/dharmatech/net-liquidity.ps1

The only downside is a lack of a Pandas-like library for it, so I occasionally reach for Python for larger datasets.

Always a pleasure to see your comments in hn threads, pjmlp.

Happy Thanksgiving.

I feel the exact same way. I’m grateful for modern computers and what they can do, but I think the substrates of Lisp and Smalltalk machines make building flexible component-based software easier than the Linux, Windows, and Web ecosystems we have today. If I had the spare time, I’d work on a modern-day OS inspired by the Lisp and Smalltalk environments of old.

If I had the time and the money, I’d like to pick up where Xerox PARC left off when they stopped working on Smalltalk, Cedar, Mesa, and similar projects. I’m also very fascinated by Apple projects of the 1990s such as SK8, Dylan, and the original proposal for a Lisp-based Newton. During the “interregnum” years at Apple many people with interesting ideas on system design and usability worked at Apple, such as Don Norman and Larry Tesler. I’m grateful for Steve Jobs’ return and for NeXT-based macOS, but unfortunately as time passed by, the Smalltalk, Lisp, and even NeXT influences at Apple faded away. It would be cool if somebody continued this vision. I’d do it in a heartbeat if I had the time and the financial resources.

You're not alone. When someone asks "What OS do you prefer, Windows, Linux, or Mac?" my answer is: "none". Anyhow, back to dreaming. Someday maybe...
two things come to mind:

- good ideas too early don't grow, but they reemerge as genes for subsequent generations (closure, pattern matching, immutability etc are all back in fashion)

- there's a paradoxical idea of great pioneering ideas that die before becoming mainstream on their own but need future lesser vessels to shine anonymously. somehow the past was better but couldn't be.. how many other nice things were partially lost ?

At an emotional level I get this and can sympathize. But at a rational level... what would be shortcomings of a Lisp programming environment or Smalltalk image, versus Win/Mac/*nix?

Perhaps I had better specify: apart from software ecosystem support.

(I see one great thread talking about downsides of image-based(as in, Smalltalk image) on related @ https://news.ycombinator.com/item?id=34300806#34302095)

Beckman Instruments got our Xerox 1108 in 1983 (and an 1186 a couple of years later). We developed Expert System commercial products in Interlisp-D but ported them to run on the PC (DOS) using the Gold Hill Common Lisp.

That was a wonderful environment to develop on. So, I'm now working on the Medley Interlisp Project!

SpinPro™ designs optimal ultracentrifugation procedures (for biology research) (Beckman manufactures and sells ultracentrifuge instruments.) SpinPro had issues with marketing, with few customers.

PepPro™ designs chemical procedures to synthesize custom peptides (small proteins). PepPro was essentially completed when Beckman Instruments dropped their entire Peptide Synthesis product line. (The PepPro user manual was in final review.)

SpinPro https://pubs.acs.org/doi/abs/10.1021/bk-1986-0306.ch023

PepPro https://cdn.aaai.org/IAAI/1989/IAAI89-010.pdf

Hey Mark

Can you tell us more about that commercial project you developed?

I ported Charlie Forgy’s OPS5 to InterLisp-D and added a nice UI and a few utilities.

Most of my development work however was doing demos for specific potential clients. It was easy enough to put something tailored together, then a senior person would bring potential clients into my office and I would mostly talk with them while showing them their demo. So, not much practical. That was 40 years ago.

What product did you write, if you can discuss it?
Related:

My encounter with Medley Interlisp - https://news.ycombinator.com/item?id=34300806 - Jan 2023 (49 comments)

2022 Medley Interlisp Annual Report - https://news.ycombinator.com/item?id=34100600 - Dec 2022 (11 comments)

Interlisp Online - https://news.ycombinator.com/item?id=32621183 - Aug 2022 (9 comments)

Larry Masinter, the Medley Interlisp Project: Status and Plans - https://news.ycombinator.com/item?id=25379238 - Dec 2020 (2 comments)

Interlisp project: Restore Interlisp-D to usability on modern OSes - https://news.ycombinator.com/item?id=24075216 - Aug 2020 (24 comments)

>Scheme is an exotic sports car. Fast. Manual transmission. No radio.

>Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."

>Common Lisp is Howl's Moving Castle.

Scheme is the intersection of all Lisps.

Common Lisp is the union of all Lisps.

https://wiki.c2.com/?NetworkExtensibleWindowSystem

https://www.donhopkins.com/home/catalog/lang/NeWS.html

>Basically, X and NeWS seem to form the right and left brain halves of windowing systems. X is basic, fast (or should be) and analytical, NeWS seems to be what you should be using if you want something more creative than boxes with chars and/or line drawings in them of a fairly fixed nature. Right now people seem to be responding to each on that atavistic level.

>X is a jeep wagoneer with all options including a tow ball if you can't fit it inside the cab, NeWS is a DeLorean turning magnificently on a stand in the main lobby of the Museum of Modern Art, the engine comes in kit form, diesel, gasoline, ethanol, any number of cylinders all available, actually the kit is just a big cube of steel, very high grade, and a textbook on modern engine design.

>The X11/NeWS merge might very well end up to be the "long-awaited" station wagon version of the DeLorean, with the jeep hanging off the back on a newly attached brushed stainless steel tow ball, just in case.

>-Barry Shein, Boston University, 6 Feb 1988, NeWS-makers@brillig.umd.edu

> Common Lisp is the union of all Lisps

Except it wasn't. Common Lisp was different from most Lisps in that it was a standard and not an implementation. Implementations were different, from small to large scale. The initial CLtL1 language definition was a small part of Lisp Machine Lisp with some stuff added in (type declarations, lexical binding, ...).

CLtL1 lacked

  * a way to start or quit Lisp
  * command line arguments
  * memory management (like garbage collection, finalization, memory areas)
  * virtual machine
  * threads
  * stack groups
  * continuations
  * interrupts
  * fexprs
  * error handling
  * object system or any way to define extensible operations
  * user defined stream types
  * networking
  * internationlization features (like international character sets, multilanguage support, ...)
  * a higher level iteration construct
  * tail call elimination
  * stack introspection (backtraces, ...)
  * pretty printer interface
  * MLISP / RLISP syntax
  * library & source code management
  * 'weak' data structures
  * extensible hash tables
  * terminal interface
  * assembler
  * advising
  * source retrieval
  * pattern matcher
  * calling external programs
  * locatives
  * big floats  
  * single namespace for functions and variables
and more. None of that was in CLtL1. Much of that also is not in ANSI CL.

Read through Lisp manuals (MIT Scheme, MacLisp, MDL, Lisp Machine Lisp, Interlisp, ...) from that time (when CLtL1 was published) and much of that existed.

Implementations provided more. Just like, say, Interlisp-D (which also was an operating system with applications) provided much more than most Common Lisp implementations.

Scheme also isn't the intersection of all Lisps. I take union/intersection comment as a quip, not to be read literally.
It can be seen as a small core language of a lexically scoped & tail call optimizing Lisp variant. R1RS was defined on just 35 pages (and they were not as densely written as in later reports).
That's right, it's just a throw-away quip, but if you want the deep nuanced story and inside history of Common Lisp and comparison with Scheme, Kent Pitman is the one to read:

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

Index of Kent Pitman's Papers:

https://www.nhplace.com/kent/Papers/

Scheme or Lisp? Kent M Pitman explains the deep philosophical differences.

https://www.reddit.com/r/programming/comments/6fa5r/scheme_o...

Kent Pitman on Scheme or Lisp?:

https://groups.google.com/g/comp.lang.lisp/c/TEk4O4-zsA8/m/H...

Common Lisp: The Untold Story:

https://www.nhplace.com/kent/Papers/cl-untold-story.html

Why Wolfram Mathematica did not use Lisp (2002) (ymeme.com):

https://news.ycombinator.com/item?id=9797936

https://web.archive.org/web/20110122140154/http://www.ymeme....

Kent Pitman's essay on why lisp doesn't have copying of lists.

https://groups.google.com/g/comp.lang.lisp/c/MmtQreo3PCM

Parenthetically Speaking with Kent Pitman: The Best Intentions: EQUAL Rights -- And Wrongs -- In Lisp:

https://www.nhplace.com/kent/PS/EQUAL.html

Kent M. Pitman Answers On Lisp And Much More:

https://developers.slashdot.org/story/01/11/03/1726251/kent-...

Kent M. Pitman's Second Wind:

https://developers.slashdot.org/story/01/11/13/0420226/kent-...

Tutorial on Good Lisp Programming Style: Peter Norvig, Sun Microsystems Labs Inc; Kent Pitman, Harlequin Inc.:

https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf

Notes from the ANSI standardisation process:

https://stackoverflow.com/questions/72414053/notes-from-the-...

Issue CLOS-CONDITIONS Writeup:

https://www.lispworks.com/documentation/lw50/CLHS/Issues/iss...

On Pitman's “Special forms in Lisp” (2011) (kazimirmajorinc.com):

https://news.ycombinator.com/item?id=29947329

https://news.ycombinator.com/item?id=29954993

DonHopkins on Jan 16, 2022 | parent | next [–]

Kent Pitman also wrote the "Revised Maclisp Manual (Saturday Evening Edition)" aka the "Pitmanual".

https://en.wikipedia.org/wiki/David_A._Moon

http://www.nhplace.com/kent/publications.html

>In 1983, I finished the multi-year task of writing The Revised Maclisp Manual (Saturday Evening Edition), sometimes known as The Pitmanual, and published it as a Technical Report at MIT's Lab for Computer Science. In 2007, I finished dusting that document off and published it to the web as the Sunday Morning Edition.

http://www.maclisp.info/pitmanual/

Not to be confused with David Moon who wrote the "MacLISP Reference Manual" aka the "Moonual", and who co-authored the "Lisp Machine Manual" with Richard Stallman and Daniel Weinreb, which had big bold lettering that ran around the spine and back of the cover, so it was known as the "LISP CHINE NUAL" (reading only letters on the front).

https://news.ycombinator.com/item?id=15185827

https://hanshuebner.github.io/lmman/title.xml

https://news.ycombinator.com/item?id=15186998

DonHopkins on Sept 6, 2017 | next [–]

The cover of the Lisp Machine Manual had the title printed in all caps diagonally wrapped around the spine, so on the front you could only read "LISP CHINE NUAL". So the title was phonetically pronounced: "Lisp Sheen Nual".

My friend Nick made a run of custom silkscreened orange LISP CHINE NUAL t-shirts (most places won't print around the side like that).

https://www.facebook.com/photo.php?fbid=74206161754&l=54ec4e...

I was wearing mine in Amsterdam at Dappermarkt on Queen's Day (when everyone's supposed to wear orange, so I didn't stand out), and some random hacker (who turned out to be a university grad student) came up to me at random and said he recognized my t-shirt!

http://www.textfiles.com/hacking/hakdic.txt

CHINE NUAL (sheen'yu-:l) noun.

The reference manual for the Lisp Machine, a computer designed at MIT especially for running the LISP language. It is called this because the title, LISP MACHINE MANUAL, appears in big block letters -- wrapped around the cover in such a way that you have to open the cover out flat to see the whole thing. If you look at just the front cover, you see only part of the title, and it reads "LISP CHINE NUAL"

toomanybeersies on Sept 7, 2017 | parent | next [–]

Link to an image of the manual, for the lazy:

https://c1.staticflickr.com/1/101/264672507_307376d26c_z.jpg

https://news.ycombinator.com/item?id=27332340

DonHopkins on May 30, 2021 | prev | next [–]

Here's the source code for Kent Pitman's "DOCTOR" in MACLISP, which was of course inspired by ELIZA. (Joseph Weizenbaum taught Kent Pitman LISP!)

https://github.com/PDP-10/its/blob/master/src/games/doc.102

And here's what happened with he (manually by typing) hooked it up with Kenneth Colby's "PARRY" (the paranoid patient):

https://www.maclisp.info/pitmanual/funnies.html

>Parrying Programs

>I didn't write the original ELIZA program, although my Lisp class was taught by Joseph Weizenbaum, who did. I later wrote a very elaborate program of similar kind, which I just called DOCTOR, in order to play with some of the ideas.

>At some point, I noticed there was a program at Stanford called PARRY (the paranoid patient), by Kenneth Colby. I understand from Wikipedia's PARRY entry that Weizenbaum's ELIZA and PARRY were connected at one point, although I never saw that. I never linked PARRY with my DOCTOR directly, but I did once do it indirectly through a manual typist. Part of my record of this exchange was garbled, but this is a partial transcript, picking up in the middle. Mostly it just shows PARRY was a better patient than my DOCTOR program was a doctor.

>I have done light editing to remove the typos we made (rubbed out characters were echoed back in square brackets).

>Also, I couldn't find documentation to confirm this, but my belief has always been that the numeric values after each line are PARRY's level of Shame (SH), Anger (AN), Fear (FR), Disgust (DS), Insecurity (IN), and Joy (J).—KMP

[...]

;;; Notes about CLI interrupts and eval-in-other-lisp:

https://news.ycombinator.com/item?id=20267415

https://news.ycombinator.com/item?id=38061207

>Here's Kent Pittman's :TEACH;LISP from ITS, which is a MACLISP program that teaches you how to program in MACLISP. (That's "Man And Computer Lisp" from "Project MAC", not "Macintosh Lisp".)

Interlisp-D is quite fascinating even without the full environment.

The spaghetti stack implementation makes continuation type things comfortably implementable and also runtime introspection of program state.

It also has NLAMBDA as well as LAMBDA - the former is operative rather than applicative, i.e. it passes the argument expressions rather than evaluating them and passing the resulting values.

Means you can do macro-like things at runtime if you have the need, though unlike e.g. Kernel Lisp and other fexpr-based lisps you don't get an environment object passed - because Interlisp is dynamically rather than lexically scoped a plain eval will DTRT so long as you haven't shadowed any of the relevant symbols.

(I have a couple of Interlisp docs, plus a couple Kernel docs, plus some other stuff archived under https://trout.me.uk/lisp/ if anybody's interested - there's probably better links elsewhere in the thread for the Interlisp things but I have a habit of keeping copies of stuff I know I'll want to refer back to)

> The spaghetti stack implementation makes continuation type things comfortably implementable and also runtime introspection of program state.

For a long time that spaghetti stack implementation was buggy because I don’t think it was really used. When I was at PARC working on 3-Lisp I wrote an emacs (being no fan of structure editing or the mouse) in Interlisp-D. I chose to make each command binding a closure (so you had all the proper mode context etc). That spaghetti light on the mouse cursor was basically perpetually on and the machine became unusable.

I showed Masinter. It seems like nobody had ever thought of creating thousands of closures before. The bug was eventually fixed but by then I’d chosen a different strategy.

I bet the bug was caused by a copy-and-pasta error!
I’m surprised given that the spaghetti stack is divinely inspired
> Developers from Fuji Xerox wrote a portable VM in C to run the environment on different host platforms, called Maiko.

I'm always confused by the relationship of C and Lisp(s). Here the VM is written in C. Yet elsewhere there seem to be at least one good example of a Lisp compiler written in Lisp [0]. What was the reason for writing Maiko in C, versus Lisp "all the way"?

[0] "The first complete Lisp compiler, written in Lisp, was implemented in 1962 by Tim Hart and Mike Levin at MIT, and could be compiled by simply having an existing LISP interpreter interpret the compiler code, producing machine code output able to be executed at a 40-fold improvement in speed over that of the interpreter.[19] This compiler introduced the Lisp model of incremental compilation, in which compiled and interpreted functions can intermix freely. The language used in Hart and Levin's memo is much closer to modern Lisp style than McCarthy's earlier code. " https://en.wikipedia.org/wiki/Lisp_(programming_language)#Hi...

A Lisp and a compiler are two different things: Lisp is the whole thing and the Lisp compiler is just a component of a Lisp system.

Now, one could write a virtual machine in Lisp, but usually one would write it in C or assembler, since that's what squeezes more performance out of the hardware and makes interfacing to the operating system 'easier' (threads, calls into the OS, memory management, interrupts, error handling, etc.).

There are examples where (parts of) a virtual machine are written in Lisp. For example the Virtual-CPU emulator may be generated as C or assembler code from a Lisp program. There are also special versions of, say, the JVM written in Lisp to prove its correctness. Ideally one may want to have the core VM emulator written in assembler to reduce it to the most minimum hardware instructions per virtual machine instruction.

The example you cited from 1962 is a Lisp compiler written in Lisp, compiled by itself, running in a Lisp whose runtime was written in assembler (IIRC).

That helps, thank you. Based on what I've seen with Smalltalk, and playing around with the online Interlisp environment [0], I was under the impression an underlying OS was not a necessity [1].

[0] https://online.interlisp.org/main

[1] Part of my confusion may stem from ideas like presented by Chuck Moore in Masterminds of Programming by Biancuzzi: "Operating systems are dauntingly complex and totally unnecessary. It’s a brilliant thing that Bill Gates has done in selling the world on the notion of operating systems. It’s probably the greatest con game the world has ever seen.

An operating system does absolutely nothing for you. As long as you had something—a subroutine called disk driver, a subroutine called some kind of communication support, in the modern world, it doesn’t do anything else. In fact, Windows spends a lot of time with overlays and disk management all [sic] stuff like that which are irrelevant. You’ve got gigabyte disks; you’ve got megabyte RAMs. The world has changed in a way that renders the operating system unnecessary.

What about device support?

Chuck: You have a subroutine for each device. That’s a library, not an operating system. Call the ones you need or load the ones you need."

it'd be entirely possible to write the vm in lisp (there are plenty of good optimising lisp compilers, e.g. sbcl).

however, typically you'd want the vm to be easily portable / buildable in new environments, and that's much easier to achieve with c.

and it is likely just easier to write this kind of low-level code in c (however i know plenty of people who will gladly demonstrate otherwise).

consider that the jvm et al are also written in c(++), for much the same reasons of practicality.

The C abstract machine is basically an overgrown PDP-11 at this point and most modern hardware is designed with that in mind with GPU and vector hardware being notable exceptions — and notably not being especially amenable to programming in C.

It’s actually been an unfortunate and pernicious codependence IMHO.

It's more that it's easier to use C for two reasons. The first is that C is really popular and therefore pretty portable. It's a lingua franca. The other is that because the hosts are largely defined in C, it's easier to interact with. Of course, the host doesn't actually "speak C", it follows some form of ABI. But the reality is that implementing each ABI is non-trivial and you can avoid a lot of pain by just using the host's C compiler/linker/etc. that implements it for you.
Like, SBCL compiles and assembles directly to machine code, that's very much the Lisp way. But SBCL has a lot of C that's involved in getting the SBCL image running and interacting with the host.
Here’s a short video showing the environment.

https://youtu.be/QDrhdsrmtAQ

I think people came to the conclusion in the mid 1980s that you couldn’t really get ahead with a specialized “LISP machine” compared to an advanced general purpose processor, particularly when you put caching, pipelining and superscalarity into the mix.

The genius of Common LISP was it had mechanical sympathy for the forthcoming ‘32-bit’ computers . Java was very much inspired by the CL spec defining a rich, efficient and implementable memory managed VM you could build over general purpose hardware with a lot of room for optimization and documenting that system very well.

I read in the article that it was possible to virtualize Medley/Interlisp on MS-DOS. If getting ahead means moving from Lisp Machines to MS-DOS then it's questionable what direction things were moving in.

I get annoyed when I read things like the Plan 9 system would seamlessly works across several heterogeneous machines making it feel like one system, yet in 2023 I have jump through hoops to access files on my computer from my phone and vice versa yet both are in the same network

> in 2023 I have jump through hoops to access files on my computer from my phone and vice versa yet both are in the same network

Syncthing is pretty good unless you use iOS. Apple products tend to only have interoperability and user freedom because they're forced to.

> The genius of Common LISP was it had mechanical sympathy for the forthcoming ‘32-bit’ computers

“Forthcoming” is a bit anachronistic.

By the time CL was being standardized in the early 80s 32 bit machines like the Vax were quite common, and there was plenty of experience from NIL and franzlisp. Also there was a decade of experience from the CADR which was a 32-bit machine.

And CL itself was based mainly on the CADR’s Lisp, a descendant of MACLISP, which was developed on 36-bit machines like the PDP-6/PDP-10/PDP-20 which was the original Lisp machine, and also the progenitor of Interlisp, that also fed CommonLisp. MACLISP also ran on Honeywell’s 36-bit hardware under Multics.

also the ibm 360 was 32-bit and shipped in 01965. it's a lot more similar to a vax or 68000 or 80386 than a cadr or pdp-10 is
Just that the CL spec says literally nothing about a VM. It's a language spec, not an implementation spec.
> Common Lisp is Howl's Moving Castle.

Common lisp isn't that big of a moving target, its also a standard which means that the standard isnt moving. In the vehicular comparison, I'd say its more like the filliping geepney (big heavy, shiny and bullies it way through heavy traffic).

The Conrad Barski lisp book used pictures of sheep and wolves to describe Scheme, Lisp, and Haskell iirc. Also cavemen to describe Fortran I think lol. I think he was trying to show scheme as being more elegant than common lisp, but also significantly less practical.
I would be able to speak to the allegedly “impractical” nature of Scheme if only I knew why Cisco hired Kent Dybvig, the principal developer of Chez Scheme. I would also like to know why Beckman Coulter Life Sciences supported the development of Swish, an extension of Chez Scheme that provides Erlang-inspired message passing.

Gambit and Scheme have been used for health applications. Here's one paper on that subject, from 2013: https://ecem.ece.ubc.ca/~cpetersen/lambdanative_icfp13.pdf

I would mention the use of GNU Guile to build Guix, which has had considerable uptake. Guile has been used to build other Linux programs.

Admittedly, Scheme isn't widely used. But impractical? No!

I feel like Racket sorta changed the "practicality" story in many respects for Scheme. Not in the sense that Racket itself is practical, but the macro system is really good and inspired other Schemes like Gerbil that are more practical.
The Notecards application is interesting.
[Article author here]

It is. The whole thing is.

Yikes! Merged hither now. Thanks!