What happened to all the Lisp code ?

[Spiros Bousbouras]

When I look at the various "Issues" in CLHS , I see several Common Lisp
implementations being mentioned. I haven't counted but I estimate around 20.
Some of them are commercial. This suggests that a lot of Lisp code was being
written at the time the standard was being developed (1980s). The code might
not have been Common Lisp but was in Lisp languages close to Common Lisp. So
does anyone know what kind of code all those people were writing back then ?
It's even more striking considering that computer hardware was much slower
back then so , for various tasks which a Lisp would be fast enough on today's
hardware , it might not have been fast enough back then.

Also , what happened to that code ? How much of it is still available today ?
Did it stop being useful and was eventually erased ? Was it eventually
rewritten in C++ or Java or whatever ?

--
vlaho.ninja/prog

[Helmut Eller]

On Tue, Apr 19 2022, Spiros Bousbouras wrote:

> When I look at the various "Issues" in CLHS , I see several Common Lisp
> implementations being mentioned. I haven't counted but I estimate around 20.
> Some of them are commercial. This suggests that a lot of Lisp code was being
> written at the time the standard was being developed (1980s). The code might
> not have been Common Lisp but was in Lisp languages close to Common Lisp. So
> does anyone know what kind of code all those people were writing back then ?

The Lisp machines were some of the early personal computers, a bit like
the Smalltalk machines from Xerox PARC. They had relatively good
graphic capabilities and were, for a time, quite fast. Lisp was the
system language, on so everything from device drivers, file-systems,
databases, gui frameworks etc. was written in Lisp (and microcode).
Also keep in mind, Lisp machines were expense; in todays dollars
probably 50k upwards.

It seems that the primary customers of Lisp machines were the big
national laboratories in the USA. At that time, those were fully
occupied with Cold War activities. Not sure what they used the Lisp
machines for, maybe they played "WarGames" ;-). But they certainly
could afford the best and most expensive hardware. That's probably also
the reason why DARPA funded the standardization of Lisp.

On the commercial side, the most important application for Lisp were
probably expert systems. At that time there was a big hype around
expert systems and a lot of money was spent on them (and Lisp) before
the bubble burst.

> It's even more striking considering that computer hardware was much slower
> back then so , for various tasks which a Lisp would be fast enough on today's
> hardware , it might not have been fast enough back then.
>
> Also , what happened to that code ? How much of it is still available today ?
> Did it stop being useful and was eventually erased ? Was it eventually
> rewritten in C++ or Java or whatever ?

When Suns and other Unix workstations appeared, Lisp machines were no
longer interesting as Suns were faster, cheaper and better. Some Lisp
code was ported and some applications, e.g. Maxima or Axiom, are still
around. On Unix, Lisp was never as relevant as C and after the AI
Winter (collapse of expert system hype) Lisp never quite found a niche.

Helmut

[Jeff Barnett]

You might try searching for history of Lisp machines, especially those
built by Symbolics. Lisp entwines two problems - storage size, processor
speed, and costs of CPU and I/O devices. Small memories actually can
take a bigger byte out of your time budget than slow processor speed.
They can entail input/output to external devices (swapping, etc.).
Today's computers and their architectures are much better suited to
support commercial Lisp performance but the popularity and deployment of
Lisp has dropped below critical mass.

I note another performance issue: The Lisp language makes it very much
easier to write algorithmically superior systems. I'm not talking about
one liners that have little to do with anything: I'm talking about
larger systems for complex domains that involve several programmers. The
choice of basic tools and programming metaphors supported allow one to
consider varieties of architectures and approaches where proper basic
support is already in place. This is the basic reason that most early AI
experimental systems were developed in Lisp; In those early days, the
systems tended to be heavily symbolic as opposed to string and number
manipulators and that was where Lisp excelled.

A million years ago (1979), I wrote an article on the tradeoffs among
memory size, I/O performance, processor speed, and hardware costs that
appeared in something called Operating System Review. A pdf can be found at

https://notatt.com/gc-vs-swap.pdf

The assumptions and models are no longer valid but might provide some
insight into the various tradeoffs. In any event, it should help any
body not all ready convinced that the our commodity hardware market
could well support an active Lisp community if there were only one
around to take advantage of the opportunity.
--
Jeff Barnett

[paul wallich]

On 4/19/22 2:28 PM, Jeff Barnett wrote:

> A million years ago (1979), I wrote an article on the tradeoffs among
> memory size, I/O performance, processor speed, and hardware costs that
> appeared in something called Operating System Review. A pdf can be found at
>
>   https://notatt.com/gc-vs-swap.pdf
>
> The assumptions and models are no longer valid but might provide some
> insight into the various tradeoffs. In any event, it should help any
> body not all ready convinced that the our commodity hardware market
> could well support an active Lisp community if there were only one
> around to take advantage of the opportunity.

I think at this point it's a sort of catch-22 issue. The value is only
partly in the code that *does* stuff. So much is in the IDEs (broadly
speaking) and the libraries that connect to the rest of the world. And
for that, the learning curves appear to be too high, too expensive or
both. Unless the learners have jobs that will pay for the tools and/or
the time.

Oddly enough, cheap embeddable microcontrollers are getting pretty close
to the memory capacity of the early Lisp machines (there already if you
could deal with read-only swap). Cross-compilers that would give you the
full expressive power of Lisp at the speed of those chips might be an
interesting thing. (Right now, the closest approximation is Python,
where the chips effectively execute byte code at hundreds of kilohertz
instead of tens of megahertz.

paul

[Stefan Monnier]

> The assumptions and models are no longer valid but might provide some
> insight into the various tradeoffs. In any event, it should help any body
> not all ready convinced that the our commodity hardware market could well
> support an active Lisp community if there were only one around to take
> advantage of the opportunity.

FWIW, I think current web-browsers can be considered as the modern-day
Lisp machines. They don't use a language with parentheses and they're
much more oriented towards powerless users rather than the Lisp machines
whose mindset was more based on the idea of the user being all-powerful,
so they're quite different, but there's a clear historical lineage
(arguably going through things like Emacs).


Stefan

[Zyni Moë]

Think there is the standard romantic 'Lisp is dead / dying / the golden age
has passed' thing in answers here. How many active Lisp implementations
were there in 1984? How many are there now? How much code, really, was
written in Lisp before 1984: how much since? Yes, certainly Lisp is now
smaller fraction of all code being puked out. But almost all of that code
is what people puke out: a nasty colour and it smells bad except to dogs.

--
the small snake

[Jeff Barnett]

Well one thing has certainly changed: the complexity of writing a Lisp
system. The introduction and general acceptance of Common Lisp by the
community upped the ante quite a bit. I use to say that every serious
programmer needs to write a compiler or interpreter based system every
few years in order to recall how to well organize code. I always did my
due diligence by doing some sort of Lisp for a piece of hardware that
would appear in my environment. I gave this up after finding Common Lisp
so appealing. The only unfortunate thing was its complexity and volume
removed it from the "let's do an implementation to keep are hands in the
game" list of exercises at the brain sauna.
--
Jeff Barnett

[Madhu]

* Stefan Monnier <jwv8rs0j42h.fsf-monnier+comp.lang.lisp @gnu.org> :
Wrote on Tue, 19 Apr 2022 14:58:53 -0400:

> FWIW, I think current web-browsers can be considered as the modern-day
> Lisp machines. They don't use a language with parentheses and they're
> much more oriented towards powerless users rather than the Lisp machines
> whose mindset was more based on the idea of the user being all-powerful,

the endtimes distinction between Empowerment vs Enslavement. The web
browser is based on a philosophy of disempowerment, enslavement
surveillance and central control. The spirit of lisp as a PL is
fundamentally incompatible with the goals which are fuelling the present
computing economy

[Madhu]

* paul wallich <t3n0m0$jt7$1 @reader1.panix.com> :
Wrote on Tue, 19 Apr 2022 14:57:03 -0400:

> On 4/19/22 2:28 PM, Jeff Barnett wrote:
> I think at this point it's a sort of catch-22 issue. The value is only
> partly in the code that *does* stuff. So much is in the IDEs (broadly
> speaking) and the libraries that connect to the rest of the world. And
> for that, the learning curves appear to be too high, too expensive or
> both. Unless the learners have jobs that will pay for the tools and/or
> the time.

today there is plenty of deficit-funding-out-of-the-wazoo to support the
javascript, rust, go developer markets where the developer is the
market. each successfully reimplementing the model I first encountered
with Java. i guess it works on some derivative basis.

[Zyni Moë]

Stefan Monnier <mon...@iro.umontreal.ca> wrote:

> FWIW, I think current web-browsers can be considered as the modern-day
> Lisp machines. They don't use a language with parentheses and they're
> much more oriented towards powerless users rather than the Lisp machines
> whose mindset was more based on the idea of the user being all-powerful,
> so they're quite different, but there's a clear historical lineage
> (arguably going through things like Emacs).
>

Friend of mine also said this. Especially with debugging tools in things
like Firefox you can really poke around in them like you could on LispM (I
believe: LispMs mostly are before I was born and also were not things that
would have bern available in Soviet sphere of influence when I was small).

Difference to me is two things: JS is deeply unpleasant to write, Lisp is
pleasant (but there are wrappers for JS I think) & has no macros (but
again, wrappers? with macros?); and browsers are increasingly getting
worried about security which is a good thing but makes life more hard
(someone will now claim that Lisp solves this second problem by some
undescribed magic to which I say publish a paper and write a system that
shows this in practice).

On the other hand for example LispWorks is a deeply comfortable and
powerful programming environment. Is just not free (but very cheap
compared to LispM). Probably the free ones are approaching it now? I do
not know.


--
the small snake

[Spiros Bousbouras]

On Tue, 19 Apr 2022 20:00:53 +0200
Helmut Eller <eller....@gmail.com> wrote:
> On Tue, Apr 19 2022, Spiros Bousbouras wrote:
>
> > When I look at the various "Issues" in CLHS , I see several Common Lisp
> > implementations being mentioned. I haven't counted but I estimate around 20.
> > Some of them are commercial. This suggests that a lot of Lisp code was being
> > written at the time the standard was being developed (1980s). The code might
> > not have been Common Lisp but was in Lisp languages close to Common Lisp. So
> > does anyone know what kind of code all those people were writing back then ?
>
> The Lisp machines were some of the early personal computers, a bit like
> the Smalltalk machines from Xerox PARC. They had relatively good
> graphic capabilities and were, for a time, quite fast. Lisp was the
> system language, on so everything from device drivers, file-systems,
> databases, gui frameworks etc. was written in Lisp (and microcode).
> Also keep in mind, Lisp machines were expense; in todays dollars
> probably 50k upwards.

So then , after the Lisp machines lost relevance , a lot of that code also
lost relevance and porting it to other hardware woudln't even be meaningful.

> It seems that the primary customers of Lisp machines were the big
> national laboratories in the USA. At that time, those were fully
> occupied with Cold War activities. Not sure what they used the Lisp
> machines for, maybe they played "WarGames" ;-).

Smiley noted but I wonder , is examining different scenarios (wargames
related or whatever) , i.e. going through a large number of different
combinations of moves , something Lisp would be good at ? This seems much
closer to the strengths of C or C++ or Fortran and I believe chess engines
get written in C or C++ with a bit of assembly thrown in. I can only imagine
Lisp being relevant if the evaluation of the final positions (after a
sequence of moves has been followed) is dynamic ; in other words if the
evaluation function changes in some complicated manner as the programme runs.
Or if the algorithm for choosing which moves to examine first and which later
changes in some complicated manner as the programme runs. I note that in
existing chess engines , moves which have been found more promising with
shorter lookahead , get examined first as the engine moves to longer
lookaheads. But such a simple heuristic would be no easier to achieve in Lisp
than in more static languages.

> But they certainly
> could afford the best and most expensive hardware. That's probably also
> the reason why DARPA funded the standardization of Lisp.
>
> On the commercial side, the most important application for Lisp were
> probably expert systems. At that time there was a big hype around
> expert systems and a lot of money was spent on them (and Lisp) before
> the bubble burst.

Were those expert systems delivering what the companies buying them hoped for
or were the companies too much influenced by hype and did not evaluate
correctly if they were getting their money's worth from Lisp code or Lisp
machines ?

> > It's even more striking considering that computer hardware was much slower
> > back then so , for various tasks which a Lisp would be fast enough on today's
> > hardware , it might not have been fast enough back then.
> >
> > Also , what happened to that code ? How much of it is still available today ?
> > Did it stop being useful and was eventually erased ? Was it eventually
> > rewritten in C++ or Java or whatever ?
>
> When Suns and other Unix workstations appeared, Lisp machines were no
> longer interesting as Suns were faster, cheaper and better. Some Lisp
> code was ported and some applications, e.g. Maxima or Axiom, are still
> around. On Unix, Lisp was never as relevant as C and after the AI
> Winter (collapse of expert system hype) Lisp never quite found a niche.

As another example , the "Issues" in CLHS sometimes mention Kyoto Common Lisp
which still exists as Embeddable Common Lisp.

--
Somebody was trying to tell me that CDs are better than vinyl because
they don't have any surface noise. I said, "Listen, mate, life has
surface noise."
John Peel

[Helmut Eller]

On Wed, Apr 20 2022, Spiros Bousbouras wrote:
[...]

> Smiley noted but I wonder , is examining different scenarios (wargames
> related or whatever) , i.e. going through a large number of different
> combinations of moves , something Lisp would be good at ?

I'm not sure, but Lisp/SIPE-2[1] may have been used in DART[2]:

During the Persian Gulf crisis of 1991, U.S. forces deployed a Dynamic
Analysis and Replanning Tool, DART (Cross and Walker, 1994), to do
automated logistics planning and scheduling for transportation. This
involved up to 50,000 vehicles, cargo, and people at a time, and had
to account for starting points, destinations, routes, and conflict
resolution among all parameters. The AI planning techniques generated
in hours a plan that would have taken weeks with older methods. The
Defense Advanced Research Project Agency (DARPA) stated that this
single application more than paid back DARPA’s 30-year investment in
AI.

> This seems much
> closer to the strengths of C or C++ or Fortran and I believe chess engines
> get written in C or C++ with a bit of assembly thrown in. I can only imagine
> Lisp being relevant if the evaluation of the final positions (after a
> sequence of moves has been followed) is dynamic ; in other words if the
> evaluation function changes in some complicated manner as the programme runs.
> Or if the algorithm for choosing which moves to examine first and which later
> changes in some complicated manner as the programme runs. I note that in
> existing chess engines , moves which have been found more promising with
> shorter lookahead , get examined first as the engine moves to longer
> lookaheads. But such a simple heuristic would be no easier to achieve in Lisp
> than in more static languages.

Yes, for chess there exist highly optimized engines and a Lisp program
could never compete with them on efficiency grounds. However, chess was
solved (mostly) in a brute-force fashion and the evaluation functions of
todays engines are optimized with a kind of machine learning: the engines
play countless hours against variations of themselves.

[...]

> Were those expert systems delivering what the companies buying them hoped for
> or were the companies too much influenced by hype and did not evaluate
> correctly if they were getting their money's worth from Lisp code or Lisp
> machines ?

I guess some were successful, but many weren't. Citing Russel&Norvig:

Overall, the AI industry boomed from a few million dollars in 1980 to
billions of dollars in 1988, including hundreds of companies building
expert systems, vision systems, robots, and software and hardware
specialized for these purposes. Soon after that came a period called
the “AI Winter,” in which many companies fell by the wayside as they
failed to deliver on extravagant promises.

Helmut

[1] https://www.ai.sri.com/~sipe/installation-sun/installation-sun.html
[2] https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool

[Spiros Bousbouras]

On Tue, 19 Apr 2022 19:42:02 -0000 (UTC)
Zyni Moë <no_e...@invalid.invalid> wrote:
> Think there is the standard romantic 'Lisp is dead / dying / the golden age
> has passed' thing in answers here. How many active Lisp implementations
> were there in 1984?

As I said in my opening post , I haven't kept count but I estimate around 20.
Since making my opening post , I remembered that I actually created a file a
while ago in which to put every Lisp implementation that I see in "Issues".
I have forgotten to update this in a while but here's what I have so far.
Upper line of each entry is the name of the implementation and bottom line
the "issue" where I saw the mention.

{
"Lucid 4.0 and Chestnut's Lisp to C translator support this."
CLASS-OBJECT-SPECIALIZER:AFFIRM

VaxLisp , Lucid Lisp
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

HPCL-I
MACRO-DECLARATIONS

Procyon Common Lisp and Symbolics
PACKAGE-DELETION

Symbolics Genera Symbolics Cloe TI Explorer
COMPILER-DIAGNOSTICS

Envos Medley
Issue DESTRUCTURING-BIND Writeup

"IIM Common Lisp's compiler"
Issue COMPILER-DIAGNOSTICS Writeup
}

It's interesting that Texas Instruments , which is a well known company for
reasons unrelated to Lisp , were also in the game.

> How many are there now?

Less than 12 I would guess. Not that it's that important and , if anything ,
there are too many given the current number of CL users.

> How much code, really, was
> written in Lisp before 1984: how much since?

Good question. I don't know the answer. Another question is , should one
try to estimate the answers in absolute numbers or relative to some
measure of how easy it has become to write code ? I mean with the rise
of cheap and powerful hardware , open source movement and spread of
usenet and internet which makes taking advice from experts much easier ,
writing and studying code written by others has also become much easier.

--
Good design adds value faster than it adds cost.
Thomas C. Gale

[Jeff Barnett]

On 4/20/2022 9:53 PM, Spiros Bousbouras wrote:
> On Tue, 19 Apr 2022 19:42:02 -0000 (UTC)
> Zyni Moë <no_e...@invalid.invalid> wrote:
>> Think there is the standard romantic 'Lisp is dead / dying / the golden age
>> has passed' thing in answers here. How many active Lisp implementations
>> were there in 1984?
>
> As I said in my opening post , I haven't kept count but I estimate around 20.
> Since making my opening post , I remembered that I actually created a file a
> while ago in which to put every Lisp implementation that I see in "Issues".
> I have forgotten to update this in a while but here's what I have so far.
> Upper line of each entry is the name of the implementation and bottom line
> the "issue" where I saw the mention.

<SNIP>
----------------------------------

Spiros,

If you haven't already, I suggest that you visit
http://www.softwarepreservation.org/projects/LISP/ where you will find
documentation (and maybe listings and publications) for a large number
of Lisp system. The person responsible for the Lisp portion of the
Software Preservation collection is Paul McJones. Paul worked his ass
off on it. For example, I sent him some old dusty listings of some Lisp
system implementations (output on line printers!) and he got them copied
in pdf format and posted. Many of the documents and listings in the Lisp
collection were from "last remaining copies".

In any event, you can merge your list with theirs. If you have some
information on Lisp systems that they do not, please contact Paul; his
email address is one of the first things you'll see if you follow the
URL above. Thanks in advance for any contributions you can make.
--
Jeff Barnett

[Paul Rubin]

Helmut Eller <eller....@gmail.com> writes:
> Soon after that came a period called the “AI Winter,” in which many
> companies fell by the wayside as they failed to deliver on
> extravagant promises.

Ah yes, that was when the investors came to their senses and decided to
put their money in quantum computers instead ;-).

[Zyni Moë]

Helmut Eller <eller....@gmail.com> wrote:

>
> Overall, the AI industry boomed from a few million dollars in 1980 to
> billions of dollars in 1988, including hundreds of companies building
> expert systems, vision systems, robots, and software and hardware
> specialized for these purposes. Soon after that came a period called
> the “AI Winter,” in which many companies fell by the wayside as they
> failed to deliver on extravagant promises.
>

Of course exact same thing is now happening with machine learning / neural
networks. Except on far larger scale.

--
the small snake

[Zyni Moë]

Spiros Bousbouras <spi...@gmail.com> wrote:
>
> It's interesting that Texas Instruments , which is a well known company for
> reasons unrelated to Lisp , were also in the game.

They made Lisp machines in MIT family.

>
> Less than 12 I would guess. Not that it's that important and , if anything ,
> there are too many given the current number of CL users.
>

Claim (which may be false): only one Common Lisp implementation has died
for reasons other than being tied to platforms which have died.

The one I know of is Lucid / Liquid which may in fact still be available
for some legacy users but clearly LW would rather sell you LW. Also note
Lucid was not killed by its Lisp business, which was profitable.

I do not count in this the various companies offering rebranded
kcl/akcl/gcls: the kcl family is alive and well.

--
the small snake

[Spiros Bousbouras]

On Tue, 19 Apr 2022 12:28:54 -0600
Jeff Barnett <j...@notatt.com> wrote:
> On 4/19/2022 5:40 AM, Spiros Bousbouras wrote:

[...]

> > Also , what happened to that code ? How much of it is still available today ?
> > Did it stop being useful and was eventually erased ? Was it eventually
> > rewritten in C++ or Java or whatever ?
>
> You might try searching for history of Lisp machines, especially those
> built by Symbolics.

The history of Lisp machines only partially overlaps with what I'm asking
for in this thread. The "Applications" section of
en.wikipedia.org/wiki/Lisp_machine only mentions the following specific
applications :

The main commercial expert systems of the 80s were available:
Intellicorp's Knowledge Engineering Environment (KEE), Knowledge Craft,
from The Carnegie Group Inc., and ART ( Automated Reasoning Tool) from
Inference Corporation.

There is only a wikipedia article on the former and it doesn't say if it's
still active. Perhaps I would find more with googling but I don't want to
spend a lot of time researching. One reason I started the thread was because
I was hoping that some people which were part of the ecosystem back then
might shed light.

--
Frankly, ladies and gentlemen, I expect you not only to master music;
I expect you to save the planet.
Karl Paulnack, director of the music division at Boston Conservatory
in his 2004 talk to new students

[Spiros Bousbouras]

On Thu, 21 Apr 2022 00:04:25 -0600
Jeff Barnett <j...@notatt.com> wrote:
> On 4/20/2022 9:53 PM, Spiros Bousbouras wrote:

[...]

> > As I said in my opening post , I haven't kept count but I estimate around 20.
> > Since making my opening post , I remembered that I actually created a file a
> > while ago in which to put every Lisp implementation that I see in "Issues".
> > I have forgotten to update this in a while but here's what I have so far.

[...]

> If you haven't already, I suggest that you visit
> http://www.softwarepreservation.org/projects/LISP/ where you will find
> documentation (and maybe listings and publications) for a large number
> of Lisp system. The person responsible for the Lisp portion of the
> Software Preservation collection is Paul McJones. Paul worked his ass
> off on it. For example, I sent him some old dusty listings of some Lisp
> system implementations (output on line printers!) and he got them copied
> in pdf format and posted. Many of the documents and listings in the Lisp
> collection were from "last remaining copies".
>
> In any event, you can merge your list with theirs. If you have some
> information on Lisp systems that they do not, please contact Paul; his
> email address is one of the first things you'll see if you follow the
> URL above. Thanks in advance for any contributions you can make.

I was aware of that but I had another look. Surprisingly to me I have heard
of something which isn't on
http://www.softwarepreservation.org/projects/LISP/common_lisp_family :

https://groups.google.com/g/comp.lang.misc/c/bW-qeUxXGkk/m/-3OfG029Z5cJ
{
Jan Gray
Feb 1, 1997

[...]

From Byte, Mar. 1986:
p.32A: "Microsoft languages speak for themselves."
[an eight page insert describing Microsoft C,
Macro Assembler, FORTRAN, COBOL, Pascal,
QuickBasic, muMATH, and...Microsoft LISP:]

p.32H: "LISP: The language of Artificial Intelligence."

"What's Microsoft LISP got going for you? It runs significantly faster
than the competition. And this new version adds several advanced
libraries. Over 400 Common LISP functions, macros and
special forms. Most implemented in machine code."

"If you're putting AI on your PC, Microsoft LISP is your language."
}

I'm not clear from the quote above if the Microsoft effort was a Common Lisp.

Anyway , I'm not trying to assemble an exhaustive list of Common Lisp
implementations. I just kept reading in "Issues" in CLHS about various
implementations , at some point thought of starting a thread like this and at
a different point I decided to be a bit more systematic about it and actually
record in a file the various implementations I was seeing in "Issues".

--
vlaho.ninja/prog

[Stefan Monnier]

> So then , after the Lisp machines lost relevance , a lot of that code also
> lost relevance and porting it to other hardware woudln't even be meaningful.

I worked on porting an application from TI Explorer II machines (BTW
I highly recommend reading https://dl.acm.org/doi/10.1145/48529.48536
which documents the marvel of a GC that this machine used) to IBM
Power/AIX machines.

Porting was definitely meaningful, but the porting effort was
non-trivial because of differences in the Lisp variant and in the OS, so
in our case it we instead took advantage of this "porting" to basically
rewrite the code, using a different algorithm.

> Smiley noted but I wonder , is examining different scenarios (wargames
> related or whatever) , i.e. going through a large number of different
> combinations of moves , something Lisp would be good at ?

What Lisp is "good at" has changed over the years, I think.

In its glory days of Lisp machines, I think Lisp stood out in many ways,
but for most applications the core quality was to offer reasonable
performance in a language with a safe automatic memory management, thus
allowing faster program development.

AFAICT for a majority of the applications developed back then its other
qualities (multi methods, macros, dynamic (re)compilation, ...) were not
used very much (or at least, could have been rewritten fairly easily
without using those features and without making the code much more
cumbersome).

I suspect that most of those applications have since moved to other
languages which offer the same "reasonable performance in a language
with a safe automatic memory management" sine there are nowadays many
more languages which also enjoy this part of Lisp's featureset.


Stefan

[Spiros Bousbouras]

On Thu, 21 Apr 2022 09:57:20 -0400
Stefan Monnier <mon...@iro.umontreal.ca> wrote:
> > So then , after the Lisp machines lost relevance , a lot of that code also
> > lost relevance and porting it to other hardware woudln't even be meaningful.
>
> I worked on porting an application from TI Explorer II machines (BTW
> I highly recommend reading https://dl.acm.org/doi/10.1145/48529.48536
> which documents the marvel of a GC that this machine used) to IBM
> Power/AIX machines.

Can you give more information like what the application did or how large the
code was or who the users were ?

[Stefan Monnier]

>> > So then , after the Lisp machines lost relevance , a lot of that code also
>> > lost relevance and porting it to other hardware woudln't even be meaningful.
>> I worked on porting an application from TI Explorer II machines (BTW
>> I highly recommend reading https://dl.acm.org/doi/10.1145/48529.48536
>> which documents the marvel of a GC that this machine used) to IBM
>> Power/AIX machines.
> Can you give more information like what the application did or how large the
> code was or who the users were ?

I don't think I can give much specifics, but it was basically
a rescheduling application for a large company, to adjust a previously
computed schedule whenever an "unexpected" event required it.
IOW, looking for nearby solutions in a set of constraints.


Stefan

[Zyni Moë]

Spiros Bousbouras <spi...@gmail.com> wrote:

> I'm not clear from the quote above if the Microsoft effort was a Common Lisp.

It was not. It was not even Microsoft Lisp: it was muLisp,
badge-engineered by Microsoft.

Is hard to know how much for sure, but certainly some of muLisp's DNA lives
on ... in calculators.

--
the small snake

[Paul Rubin]

Stefan Monnier <mon...@iro.umontreal.ca> writes:
> In its glory days of Lisp machines, I think Lisp stood out in many ways,
> but for most applications the core quality was to offer reasonable
> performance in a language with a safe automatic memory management, thus
> allowing faster program development.

My impression also is that the Lisp Machine debugging environment was
way ahead of anything else around, either at the time or today. That
also helped speed up development. But, I never really used it myself.

The other Lisp debugging environments that I've used weren't anything
special, though they were enough for me to get by.

[Stéphane CARPENTIER]

Le 20-04-2022, Zyni Moë <no_e...@invalid.invalid> a écrit :
> Stefan Monnier <mon...@iro.umontreal.ca> wrote:
>
>> FWIW, I think current web-browsers can be considered as the modern-day
>> Lisp machines. They don't use a language with parentheses and they're
>> much more oriented towards powerless users rather than the Lisp machines
>> whose mindset was more based on the idea of the user being all-powerful,
>> so they're quite different, but there's a clear historical lineage
>> (arguably going through things like Emacs).
>

> On the other hand for example LispWorks is a deeply comfortable and
> powerful programming environment. Is just not free (but very cheap
> compared to LispM). Probably the free ones are approaching it now? I do
> not know.

Didn't you hear about Nyxt?
<https://nyxt.atlas.engineer/>

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[Tom Russ]

[snipping much]

As far as scheduling-related software is concerned, there was the development of
a highly performant CL flight search software by ITA, which powered among other things
the Orbitz flight search engine. This worked much, much better than other flight search
applications of the time.

One contemporary account can be found at Franz' website:
https://franz.com/success/customer_apps/data_mining/itastory.lhtml