Interface Builder's Alternative Lisp Timeline (2013)(paulhammant.com)
paulhammant.com
Interface Builder's Alternative Lisp Timeline (2013)
https://paulhammant.com/2013/03/28/interface-builders-alternative-lisp-timeline/
30 comments
This comment, and the parent post are perhaps my favorite HN type of content.
Dylan [1] the language underpinning the Newton was also a kind of LISP. Fairly close timeframe as well. I wonder what the overlap was there; would be interesting to track the lineage of the LISP contingent at Apple. I would imagine Alan Kay would have some overlap with those folks as well.
1: https://en.m.wikipedia.org/wiki/Dylan_(programming_language)
Dylan [1] the language underpinning the Newton was also a kind of LISP. Fairly close timeframe as well. I wonder what the overlap was there; would be interesting to track the lineage of the LISP contingent at Apple. I would imagine Alan Kay would have some overlap with those folks as well.
1: https://en.m.wikipedia.org/wiki/Dylan_(programming_language)
Dylan was used in early prototypes of Newton-like systems and an early Newton. Dylan was a Lisp-derived language (originally with a Lisp-like syntax), mostly developed in Macintosh Common Lisp and itself. The released Newton MessagePad product used C++ and NewtonScript (because of extremely small RAMs of just 640kb).
Apple developed lots of new stuff in their Advanced Technology Group (ATG), which used Lisp in many projects. Lisp was used for Dylan, but even the prototype for the NewtonScript development environment was written in Macintosh Common Lisp - and then released in a C+ version.
Alan Kay was there, but Alan was more interested in Smalltalk projects, I'd guess. But one driving force for Lisp at Apple was Larry Tesler ( https://de.wikipedia.org/wiki/Larry_Tesler ), who also worked with Smalltalk at Xerox Parc. See here: http://lispm.de/docs/prefix-dylan/book.annotated/foreword.ht...
Apple developed lots of new stuff in their Advanced Technology Group (ATG), which used Lisp in many projects. Lisp was used for Dylan, but even the prototype for the NewtonScript development environment was written in Macintosh Common Lisp - and then released in a C+ version.
Alan Kay was there, but Alan was more interested in Smalltalk projects, I'd guess. But one driving force for Lisp at Apple was Larry Tesler ( https://de.wikipedia.org/wiki/Larry_Tesler ), who also worked with Smalltalk at Xerox Parc. See here: http://lispm.de/docs/prefix-dylan/book.annotated/foreword.ht...
Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed.
Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements.
It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral.
Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years.
Alan Kay was around Apple then, and seemed to be interested in pretty much everything.
Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered.
Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS.
Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements.
It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral.
Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years.
Alan Kay was around Apple then, and seemed to be interested in pretty much everything.
Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered.
Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS.
Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
I know my comment doesn’t add much value to the conversation, but I’d be remiss if I didn’t say thank you for taking the time to respond here and below with such interesting history.
Sure. My memories of Newton, Dylan, and SK8 are fond. I loved working with them and I like writing about them.
Anyone who wants to pay someone to work on similar things is encouraged to contact me. :-)
Anyone who wants to pay someone to work on similar things is encouraged to contact me. :-)
Is there some version of SK8 floating around the net that one could boot up in Sheepshaver or similar? I'd really like to experience this for myself
I was able to find this userguide [1], which is from 1994. It's very interesting. Since the project seems to have gone on until 1997 I imagine this doesn't represent the later versions, but perhaps they weren't documented like this.
[1] https://macintoshgarden.org/sites/macintoshgarden.org/files/...
[1] https://macintoshgarden.org/sites/macintoshgarden.org/files/...
If you read all the way through the section about creating a Concentration game, you can sort of get an idea of what it could do. It doesn't really give you a very good feel for what it was like, though. Nobody used SK8 in the sort of stilted one-action-at-a-time-in-sequence way that the the tutorial describes; that's an artifact of technical writing. You have to write it that way in order to clearly explain each step and each tool used without misleading ambiguities.
In actual use, it was more like working with HyperCard or a Mac drawing program. The difference from HyperCard was that you weren't limited to five predefined graphical widgets and only strings for representing data. You could build arbitrary data structures and assemble arbitrary widgets interactively from graphical primitives.
You might be able to find a copy of the SK8 Technology release by googling for something like "SK8 Apple technology release". The Wikipedia article has two links that purport to offer the SK8 sources, though neither link seems to be working this morning.
I think Rainer (lispm) at some point posted a link to an archive of the SK8 technology release; maybe he still knows where it is. Good luck running it, though. You'll need a very faithful emulation of a specific range of Mac System releases on a specific set of 68K or PPC hardware.
The Wikipedia article also has a screenshot of the SK8 environment:
That weird look is interesting in itself. It was achieved by writing WDEFs in Lisp. A WDEF was a code resource in the old (pre-OSX) mac system, used for rendering windows on the screen. You could customize the apperance of a program's windows by supplying WDEF resources that the program used to render its windows.
WDEFs were usually written in assembler or, in latter years, C. With Macintosh Common Lisp, though, you could write them in Lisp. In fact, you could write them in a mix of Lisp and assembler, using MCL's built-in interactive assembler.
(Approximately the first time I met him, Dave Vronay, who wrote much of SK8's graphical infrastructure, waxed eloquent about how wonderful it was to have an interactive assembler that could wrap machine code in convenient higher-level code. He had previously hacked on arcade games.)
In actual use, it was more like working with HyperCard or a Mac drawing program. The difference from HyperCard was that you weren't limited to five predefined graphical widgets and only strings for representing data. You could build arbitrary data structures and assemble arbitrary widgets interactively from graphical primitives.
You might be able to find a copy of the SK8 Technology release by googling for something like "SK8 Apple technology release". The Wikipedia article has two links that purport to offer the SK8 sources, though neither link seems to be working this morning.
I think Rainer (lispm) at some point posted a link to an archive of the SK8 technology release; maybe he still knows where it is. Good luck running it, though. You'll need a very faithful emulation of a specific range of Mac System releases on a specific set of 68K or PPC hardware.
The Wikipedia article also has a screenshot of the SK8 environment:
https://en.wikipedia.org/wiki/SK8#/media/File:SK8_startup_state.png
That weird look is interesting in itself. It was achieved by writing WDEFs in Lisp. A WDEF was a code resource in the old (pre-OSX) mac system, used for rendering windows on the screen. You could customize the apperance of a program's windows by supplying WDEF resources that the program used to render its windows.
WDEFs were usually written in assembler or, in latter years, C. With Macintosh Common Lisp, though, you could write them in Lisp. In fact, you could write them in a mix of Lisp and assembler, using MCL's built-in interactive assembler.
(Approximately the first time I met him, Dave Vronay, who wrote much of SK8's graphical infrastructure, waxed eloquent about how wonderful it was to have an interactive assembler that could wrap machine code in convenient higher-level code. He had previously hacked on arcade games.)
Since you are someone who seems to have been in on this in the heyday, I'll share my story with you (I think it is, in a way, telling).
In short: I was a Hypercard kid. It's strange to look back on it this way, but the early/mid 90s seems like a completely different kind of computing. It was in that period where I first started seriously using computers, writing my first stacks probably at about 9 or 10 years old. I was inspired by all of the compelling stackware and, as you might guess, Myst, which was a pretty big deal at the time.
Back then I saw Hypercard as "serious" for the following reasons: - You made "programs" that looked like the rest of the system (OS), and hence were the "real thing"; - You could make games in it yourself, but so could professionals, so it had to be "serious" - It was not just for doing one thing, but most possible things
What happened as the years went on was that the outside world continuously told me that Hypercard was, in fact, not the real thing; it was not "real programming." Materially this became even more clear as the software was left to die on the vine by Apple. One of the reasons I did not pursue CS in college (and I'm very happy I didn't) is because I didn't like all this C++ stuff that the other kids claimed was "real programming" -- if that was the real thing, I didn't want any part of it ("how in the world do you make a button with that?").
Only in recent years have I started to read up on PARC, Alan Kay, and some of the genesis of the ideas about personal computing systems. I've realized that my younger, initial instinct was probably correct: Hypercard was more like "real computing" than anything else I've encountered. It's a shame that what I expected to happen back then didn't come to pass -- that the whole future Mac OS, as presented to the user, would be a kind of Hypercard (inspectable, adjustable, open to limitless tinkering and creation, and able to be learned by interactive live examples).
I hadn't heard of SK8 until this exchange. It is very heartening to see that the grown-ups were thinking along the same lines. On the other hand, it's easy to become crestfallen at the state of computing today by comparison.
In short: I was a Hypercard kid. It's strange to look back on it this way, but the early/mid 90s seems like a completely different kind of computing. It was in that period where I first started seriously using computers, writing my first stacks probably at about 9 or 10 years old. I was inspired by all of the compelling stackware and, as you might guess, Myst, which was a pretty big deal at the time.
Back then I saw Hypercard as "serious" for the following reasons: - You made "programs" that looked like the rest of the system (OS), and hence were the "real thing"; - You could make games in it yourself, but so could professionals, so it had to be "serious" - It was not just for doing one thing, but most possible things
What happened as the years went on was that the outside world continuously told me that Hypercard was, in fact, not the real thing; it was not "real programming." Materially this became even more clear as the software was left to die on the vine by Apple. One of the reasons I did not pursue CS in college (and I'm very happy I didn't) is because I didn't like all this C++ stuff that the other kids claimed was "real programming" -- if that was the real thing, I didn't want any part of it ("how in the world do you make a button with that?").
Only in recent years have I started to read up on PARC, Alan Kay, and some of the genesis of the ideas about personal computing systems. I've realized that my younger, initial instinct was probably correct: Hypercard was more like "real computing" than anything else I've encountered. It's a shame that what I expected to happen back then didn't come to pass -- that the whole future Mac OS, as presented to the user, would be a kind of Hypercard (inspectable, adjustable, open to limitless tinkering and creation, and able to be learned by interactive live examples).
I hadn't heard of SK8 until this exchange. It is very heartening to see that the grown-ups were thinking along the same lines. On the other hand, it's easy to become crestfallen at the state of computing today by comparison.
You might also want to look at Notecards (https://en.wikipedia.org/wiki/NoteCards).
HyperCard was pretty great, and it rapidly developed a devoted community. It had some fairly severe limitations (only about five built-in widgets and a scripting language in which the only data structure was text strings), but people still managed to make a lot of cool stuff with it--sometimes by writing extensions called XFCNs and XCMDs, generally in C.
SK8 removed HyoerCard's limitations, but it never really made it out of ATG. Well, there were a few technology-sharing projects with universities and industry.
But Apple's management had no idea what to do with HyperCard, much less SK8. They couldn't figure out what marketing category to put it in or how to charge for it. Heck, the only reason it existed at all was because of a promise they had made to Bill Atkinson to try to keep him from leaving.
I hear you about the current state of computing. I do miss the tools I was regularly working with in the early 90s.
HyperCard was pretty great, and it rapidly developed a devoted community. It had some fairly severe limitations (only about five built-in widgets and a scripting language in which the only data structure was text strings), but people still managed to make a lot of cool stuff with it--sometimes by writing extensions called XFCNs and XCMDs, generally in C.
SK8 removed HyoerCard's limitations, but it never really made it out of ATG. Well, there were a few technology-sharing projects with universities and industry.
But Apple's management had no idea what to do with HyperCard, much less SK8. They couldn't figure out what marketing category to put it in or how to charge for it. Heck, the only reason it existed at all was because of a promise they had made to Bill Atkinson to try to keep him from leaving.
I hear you about the current state of computing. I do miss the tools I was regularly working with in the early 90s.
Yeah, HyperCard was great. It was a wonderful experience when it was released.
Sk8 was developed as a base technology tool to develop these things.
See for example: https://homepages.cwi.nl/~steven/sigchi/bulletin/1998.2/spoh...
http://worrydream.com/refs/Spohrer%20-%20ATG%20Education%20R...
Sk8 was developed as a base technology tool to develop these things.
See for example: https://homepages.cwi.nl/~steven/sigchi/bulletin/1998.2/spoh...
http://worrydream.com/refs/Spohrer%20-%20ATG%20Education%20R...
That was definitely very cool: Larry Tesler joining the Dylan hackers in his sabbatical.
As I said, he was really great to work with. He wrote the initial draft of the simple frame language that bauhaus used for "intelligent assistance". He was a capable Lisp hacker, and a big fan of Lisp and Smalltalk. He's also just one of the nicest people I've ever met.
He left Apple some time around when Steve Jobs returned. I don't know why why he left, but I wouldn't be surprised if Steve had something to do with it.
I worked for Steve at NeXT for a little while, and he came and sat in my office one day and went on at length about everything that was wrong with Apple in his view. Prominent on his list were the Advanced Technology Group and the Human Interface Group. Larry was involved one way or another with both of those institutions, and Steve wasted no time getting rid of them when he took over again.
He left Apple some time around when Steve Jobs returned. I don't know why why he left, but I wouldn't be surprised if Steve had something to do with it.
I worked for Steve at NeXT for a little while, and he came and sat in my office one day and went on at length about everything that was wrong with Apple in his view. Prominent on his list were the Advanced Technology Group and the Human Interface Group. Larry was involved one way or another with both of those institutions, and Steve wasted no time getting rid of them when he took over again.
From me being far away: ATG was one of the things which made Apple cool.
I agree; it was.
I think firing the Human Interface Group was a mistake, too. I think the usability of Apple's products has suffered, and so has the usability of technology products in general.
I think firing the Human Interface Group was a mistake, too. I think the usability of Apple's products has suffered, and so has the usability of technology products in general.
How do you feel about it? I had a bunch of Newton MessagePad and the 2100 model was especially great.
The MessagePad UI was not in color and was less animated than something like the early released iPhone or iPad. Okay, probably hardware limitations of the time: screen price, lower power draw, less powerful graphics processing, ...
I always found the UI model of the iPhone (and iPad) limited to what the Newton MessagePad did. It is still boring in the main OS screens. Was it to reach mass market? was it a conscious choice? or was it the non-dynamic programming system introduced with the iPhone, which limits the experience?
The MessagePad UI was not in color and was less animated than something like the early released iPhone or iPad. Okay, probably hardware limitations of the time: screen price, lower power draw, less powerful graphics processing, ...
I always found the UI model of the iPhone (and iPad) limited to what the Newton MessagePad did. It is still boring in the main OS screens. Was it to reach mass market? was it a conscious choice? or was it the non-dynamic programming system introduced with the iPhone, which limits the experience?
I liked the Newton products, and used them for a while. I thought the MessagePad was an awkward size, though; too big to fit in a pocket, but too small to have a good-sized screen. It would have been better if it were either smaller, like the Palm Pilot, or larger, like the unreleased Senior and Cadillac prototypes (I had a couple of those and liked them quite a bit).
Hardware limitations did have an important effect on them. Pretty much everything you see on the shipping Newton was a compromise between trying to give the device enough power and capacity to be interesting and trying to keep it small and cheap enough for people to buy. We didn't hit the sweet spot.
Yeah, iOS gave up a lot of flexibility and capability as compared to Newton, but Steve was never going to reuse a failed product conceived under someone else's leadership, and anyway, he chose to abandon the whole idea of a device for creating stuff and went with a device for consuming.
Hardware limitations did have an important effect on them. Pretty much everything you see on the shipping Newton was a compromise between trying to give the device enough power and capacity to be interesting and trying to keep it small and cheap enough for people to buy. We didn't hit the sweet spot.
Yeah, iOS gave up a lot of flexibility and capability as compared to Newton, but Steve was never going to reuse a failed product conceived under someone else's leadership, and anyway, he chose to abandon the whole idea of a device for creating stuff and went with a device for consuming.
This reminds me a bit of hyperfiddle[0], which I've looked at a few times but never really explored. I know the author (dustingetz) hangs out around here, and I wonder if any of this interface builder stuff was prior art.
In any case, I wish we had more tools for interactivity these days. I use emacs and it's given me a taste for what's possible, and I'm excited to see Guix[1] mature because it has fantastic sympathies with emacs. But it seems destined to be niche, even though it's such a wonderful vision of what computing could be.
[0]http://www.hyperfiddle.net/ [1]https://guix.gnu.org/
In any case, I wish we had more tools for interactivity these days. I use emacs and it's given me a taste for what's possible, and I'm excited to see Guix[1] mature because it has fantastic sympathies with emacs. But it seems destined to be niche, even though it's such a wonderful vision of what computing could be.
[0]http://www.hyperfiddle.net/ [1]https://guix.gnu.org/
Great write up.
Denny’s company ExperTelligence sold a product that I wrote in Lisp. He got Apple to pay for a full page ad in Scientific American for my product. He was really a lot of fun to work with.
Denny’s company ExperTelligence sold a product that I wrote in Lisp. He got Apple to pay for a full page ad in Scientific American for my product. He was really a lot of fun to work with.
that video was fascinating and depressing to watch at the same time. I know it's not apple to apple comparison, but I feel like 30 years of computer progress should've put us in better place in terms of ease of app dev.
I feel the same way when I watch Doug Engelbart‘s “mother of all demos” video: https://www.dougengelbart.org/content/view/209/448/
It does seem like we found all the low hanging fruit very early and if we are being honest with ourselves have not discovered much in the way of profound ideas since.
But in terms the video here, if you have been around the UI space since desktop apps and are familiar with modern FE frameworks it does seem like we have gone backwards in many ways.
It does seem like we found all the low hanging fruit very early and if we are being honest with ourselves have not discovered much in the way of profound ideas since.
But in terms the video here, if you have been around the UI space since desktop apps and are familiar with modern FE frameworks it does seem like we have gone backwards in many ways.
i am reminded of this every time i work with lisp or smalltalk. it feels like we barely made any progress since half a century ago. at best rust is a form of progress, and maybe pure functional programming (which lisp isn't), although the latter feels more like an exploration of boundaries (how pure can we make functional programming) rather than a technological advancement that actually helps us write better code.
I'm with the Raskins, the problems derive from interacting with computers via applications. This may or may not be at the forefront of your mind but your fondness of Lisp and Smalltalk systems supports my claim. Other systems such as Oberon fall into this camp but I would also include early PC systems like the Commodore 64 and DOS machines, even though they loaded individual applications.
The commonality with these systems is the somewhat ubiquitous interface. I think this is why power users love the command line. These HCIs reduce the cognitive load of the application model where there are wildly disparate UIs to deal with on a continual basis. The growth of "web apps" has made this exponentially worse on the user because they're not bound by widget tool kits.
I also see modern markers to support the claim. From what I understand, in China a huge amount of activity on smartphones that we would conduct through various apps, they conduct through WeChat and WeChat bots. They do this because it's more convenient and my claim is this is the normie's equivalent of attempting to push all their computing needs into Emacs.
The commonality with these systems is the somewhat ubiquitous interface. I think this is why power users love the command line. These HCIs reduce the cognitive load of the application model where there are wildly disparate UIs to deal with on a continual basis. The growth of "web apps" has made this exponentially worse on the user because they're not bound by widget tool kits.
I also see modern markers to support the claim. From what I understand, in China a huge amount of activity on smartphones that we would conduct through various apps, they conduct through WeChat and WeChat bots. They do this because it's more convenient and my claim is this is the normie's equivalent of attempting to push all their computing needs into Emacs.
It is absolutely nuts that we don't have a greater diversity of computing platforms (as we did in 80s 90s) considering we have such widely adopted standards today that overcome the "compatibility" problems. There's fertile ground for exploring more Smalltalk/Oberon/Hypercard/Lisp-machine like computing systems, with the confidence that they will be able to interact in a meaningful way with the outside world.
Unfortunately, Computer Science continues to train people in Unix.
Unfortunately, Computer Science continues to train people in Unix.
> It is absolutely nuts that we don't have a greater diversity of computing platforms (as we did in 80s 90s)
I'm seeing signs of a possible resurgence here with the reduced cost of PCBs, FPGAs and the like along with the increased approach-ability to the space.
I'm seeing signs of a possible resurgence here with the reduced cost of PCBs, FPGAs and the like along with the increased approach-ability to the space.
I felt the same way. I'm mucking about with Netbeans GUI builder with Clojure integration and it feels like such a hack.
Nice timeline! As the author of “Action!”, I’ve mused over the years at the poor quality of interface tools / environments. I’m happy to say that Apple is on to something with “SwiftUI’. They have completely rethought out a declarative UI, kept it quite interactive, and made it much easier to build quality IOS applications.
Most of the currently popular frameworks follow the pattern of organizations that make the case that "Designers" and "Programmers" need to be strictly separated.
Interfaces should be strictly separated from the internal application code, with generic layers between them. To do it otherwise means ending up with a "big ball of mud" style app, that cannot have its interface redesigned in any way other than by refactoring it completely.
It runs on a Lisp Machine board for the Mac II range: the TI MicroExplorer. That was a Nubus board with TI's Lisp chip. The Lisp system was originally developed at MIT and then by LMI. TI had a license and developed their own range of machines and the software for it for a few years. Beginning of the AI winter TI closed that business.
The TI Lisp chip was a 32Bit microprocessor designed to run Lisp applications in compact computers. Earlier Lisp Machines were much larger.
The Lisp Machine inside the Mac had an interface to the Mac OS, so that one could write Lisp applications on the MicroExplorer with Mac-like user interfaces.
The software was probably already written in Common Lisp (or ZetaLisp). It was also ported to the Mac using Common Lisp directly on the MacOS, without needing a Lisp Machine board. Earlier versions actually originated on the Mac and were written in LeLisp, a french Lisp dialect.