From: Tamas K Papp on
On Tue, 29 Dec 2009 21:34:08 +0000, Alan Mackenzie wrote:

> You can compile that language with the lisp machine as the target
> architecture. The lisp machine is just as general, it just emphasises
> languages dominated by heavily nested function calls, rather than those
> made up of assignment statements. The architectures that came to
> dominate (Intel, Motorola 68000, some RISCs) did so because "C-like"
> languages had far more programmers that "lisp-like" languages.

Maybe, but I am still not convinced that this was the main reason.
First, the number of programmers is itself endogenous: programmers
gravitate to languages which they find useful. Sure, there are some
other factors, but in the days of Lisp machines, these worked in favor
of Lisp much more than today (it was much more widespread, had a
significant presence at universities, etc).

Second, Intel-like architectures could have had other advantages which
have nothing to do with the number of programmers. Maybe they were
simpler, cheaper to produce, easier to optimize, etc. I don't think
we can explain how these architectures came to dominate without taking
these factors into account, and when we do this, I would be surprised
if the "Lisp had less programmers" story still retains a lot of
explanatory power.

Tamas
From: Tamas K Papp on
On Tue, 29 Dec 2009 11:04:23 -0800, Pillsy wrote:

> On Dec 29, 1:41 pm, Tamas K Papp <tkp...(a)gmail.com> wrote: [...]
>> As Pascal remarked above, you can write a Lisp VM on an Intel PC and
>> have your very own Lisp Machine, with many (if not all) of the claimed
>> benefits. But no one is doing this, so the benefits must be quite
>> small.
>
> It just means benefits don't outweigh not having a decent web browser.

:-)

> But they could be amazingly huge and still not make up for that lack.

If some tool has "amazingly huge" benefits, people usually end up
creating it. Eg many people consider having a Common Lisp
implementation to be very beneficial, so they are willing to devote a
substantial amount of effort (free implementations) or money
(commercial ones) in order to have one.

Yet when I asked about the benefits of Lisp Machines, all I got were
either (1) vague arguments about how nice it would be to have all the
"environment" in Lisp, (2) patronizing responses on how I can't
imagine how great it is unless I have used one, without any details.

(1): I still can't see why it would matter to have the OS etc in Lisp.
This may be because I don't want to hack the OS: my ideal state of
existence is when I can ignore the OS entirely and get on with my
work. I don't want to hack device drivers and filesystems, I prefer
not to know that such things exist. Yes, sometimes I have to deal
with them, but that's usually a PITA and I hate doing it. Fortunately
for me, there are people who do like doing these things. They seem to
prefer C, and I am fine with that. I imagine that if I tried telling
them how they would be better off using Lisp, I would get a
well-deserved laugh.

(2): The tone that some people use when they talk about Lisp Machines
reminds me of other groups which enjoy reminiscencing about solutions
that they hold in high regard but disappeared for various (mostly
economic) reasons. I still hear people talking about NeXTstep or
Amiga as if nothing that has happened ever since can compare. Maybe.
I think that even if a particular product line disappears, worthwhile
solutions resurface in other forms.

Cheers,

Tamas
From: Tamas K Papp on
On Tue, 29 Dec 2009 22:41:37 -0800, Citizen Jimserac wrote:

> On Dec 29, 1:41 pm, Tamas K Papp <tkp...(a)gmail.com> wrote:
>> You didn't provide any arguments to substantiate this.  I don't deny
>> the possibility that Lisp machines are a neat thing to have, but to
>> argue that they provide some magical benefit that revolutionizes cancer
>> research etc is nonsensical.
>
> I disagree but without a common frame of reference, it is impossible to
> convince you!!

It is also impossible to convince someone without arguments :-)

>> and have your very own Lisp Machine, with many (if not all) of the
>> claimed benefits.
>
> I MOST VOCIFEROUSLY disagree! I don't think you have a clue as to what
> those machines can do.

Yes, I see that you disagree most vociferously. If you could learn to
disagree by providing some arguments, you would be more convincing.

> I've had my say and will shut up - ponder what I said. Those who are
> interested can google for more info on what those old machines could do.
> It's out there.

I don't see anything that I could ponder on. "You are wrong, I am right,
just google for it, it is out there." Sheesh.

Tamas
From: Frode V. Fjeld on
Tamas K Papp <tkpapp(a)gmail.com> writes:

> Yet when I asked about the benefits of Lisp Machines, all I got were
> either (1) vague arguments about how nice it would be to have all the
> "environment" in Lisp, (2) patronizing responses on how I can't
> imagine how great it is unless I have used one, without any details.

Lisp would be a tool to make a tool (the OS) that supports tools
(applications) that help you do what you want to do. I'm guessing this
rather long chain of tools explains something of why it's hard to give a
list of concrete benefits. Also, there's nothing that is inherently only
possible to do in lisp and not other languages/systems. The question is
rather in what direction(s) the languages/systems tends to lead in terms
of the end-user experience. That is, "given this basic system, what is
easy/natural to build on top of it?"

There has been a huge collective effort over the last few decades to
build good "desktop" systems based on the predominant C/unix technology
(that includes linux, windows, mac, etc.), and the observation is I
believe that there's still significant aspects of the old lisp-machines
that were better, even if the number of man-years put into those lisp
systems were minuscule in comparison.

That's not to say that it's impossible for some hypothetical future
"ubluntu linux 18.0" to provide everything the lisp machines did and
more. But I do think (also) this suggests that there are serious
drawbacks to the way we are making operating systems today, and that
these have negative effects on the end-user experience.

> (1): I still can't see why it would matter to have the OS etc in Lisp.

The point would be to provide a better overall end-user experience. I
don't think "Lisp" as such is the full answer to that call, but it might
be part of the answer.

> This may be because I don't want to hack the OS: my ideal state of
> existence is when I can ignore the OS entirely and get on with my
> work. I don't want to hack device drivers and filesystems, I prefer
> not to know that such things exist. Yes, sometimes I have to deal
> with them, but that's usually a PITA and I hate doing it. Fortunately
> for me, there are people who do like doing these things. They seem to
> prefer C, and I am fine with that. I imagine that if I tried telling
> them how they would be better off using Lisp, I would get a
> well-deserved laugh.

To simply reimplement the OS kernels we use today in lisp would indeed
be laughable.

> (2): The tone that some people use when they talk about Lisp Machines
> reminds me of other groups which enjoy reminiscencing about solutions
> that they hold in high regard but disappeared for various (mostly
> economic) reasons. I still hear people talking about NeXTstep or
> Amiga as if nothing that has happened ever since can compare. Maybe.
> I think that even if a particular product line disappears, worthwhile
> solutions resurface in other forms.

Arguably much of the last few years of development in software has been
a resurfacing of solutions/ideas from the lisp machines, such as GC and
language/VM-based security/safety. That's not to say there aren't more
good ideas to reuse :)

--
Frode V. Fjeld
From: Alan Mackenzie on
Tamas K Papp <tkpapp(a)gmail.com> wrote:
> On Tue, 29 Dec 2009 21:34:08 +0000, Alan Mackenzie wrote:

>> You can compile that language with the lisp machine as the target
>> architecture. The lisp machine is just as general, it just emphasises
>> languages dominated by heavily nested function calls, rather than
>> those made up of assignment statements. The architectures that came
>> to dominate (Intel, Motorola 68000, some RISCs) did so because
>> "C-like" languages had far more programmers that "lisp-like"
>> languages.

> Maybe, but I am still not convinced that this was the main reason.
> First, the number of programmers is itself endogenous: programmers
> gravitate to languages which they find useful.

Kind of, perhaps. Programmers use whatever language their boss says, or
what the free software project they've just joined uses. I doubt many
consciously chose their language, though some do.

> Sure, there are some other factors, but in the days of Lisp machines,
> these worked in favor of Lisp much more than today (it was much more
> widespread, had a significant presence at universities, etc).

> Second, Intel-like architectures could have had other advantages which
> have nothing to do with the number of programmers. Maybe they were
> simpler, cheaper to produce, easier to optimize, etc.

The Intel 80x86 architecture came to predominate for exactly one reason,
namely that it was chosen by IBM for their PC back in the early 1980s.
Microsoft's software predominates for exactly the same reason. Nobody
would claim that the 80x86 was particularly good; other 16-bit machines
of that era used the Motorola 68000 (the Atari ST, Amiga, the Apple Mac).
Since that time, better RISC chips have appeared, yet the 30 yo Intel
architecture is as entrenched as ever. If RISC chips couldn't displace
the 80x86, what chance did a Lisp Machine have?

> I don't think we can explain how these architectures came to dominate
> without taking these factors into account, and when we do this, I would
> be surprised if the "Lisp had less programmers" story still retains a
> lot of explanatory power.

You're right here, I think. However, let's put it this way: If the
number of competent Lisp programmers in the 1980s had been higher by a
factor of 100, I think we would still have lisp machines today.

> Tamas

--
Alan Mackenzie (Nuremberg, Germany).