emacs vs lisp machines (was: What have we lost?)

[Javier]

Oregonian Haruspex <no_e...@invalid.invalid> wrote:
> eMacs is the modern Lisp Machine. How is it not?

I agree. But elisp, the dialect it uses, has its limitations.

Quoting from the elisp manual:

GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common
Lisp. If you know Common Lisp, you will notice many similarities.
However, many features of Common Lisp have been omitted or simplified in
order to reduce the memory requirements of GNU Emacs. Sometimes the
simplifications are so drastic that a Common Lisp user might be very
confused. We will occasionally point out how GNU Emacs Lisp differs
from Common Lisp. If you don’t know Common Lisp, don’t worry about it;
this manual is self-contained.

A certain amount of Common Lisp emulation is available via the
‘cl-lib’ library. *Note Overview: (cl)Top.

Perhaps somebody who has worked with real lisp machines can comment further.

[Stefan Monnier]

Nowadays most of the language-level functionality of Lisp Machines is
available in ELisp either "in the core" or via libraries that are
bundled with Emacs.

What is lacking is the lower-level support, i.e. the ability to hack
on the internals without leaving the Lisp world: in Emacs, a lot of the
lower-level details are written in C.


Stefan

[Jeff Barnett]

One thing I miss entirely was the Symbolics keyboard: layout, action,
and integration with Lisp. Another thing lacking in most (if not all)
modern Lisp providers is robustness. We had one Lisp machine that was
used as a development machine as well as the namespace server for about
8-10 other machines. In one stretch it was up, continuously, for a
little over two years - the computer room was shut down for some
electronics work over the Xmas holiday and that capped the uptime. Since
the machine "OS" was build in the same language and shared flavor
(latter CL objects) you could do almost anything without leaving the
Lisp abstraction. It felt clumsy returning to the world were Emacs was
twisted in; slimy you might say.
--
Jeff Barnett

[steve g]

Javier wrote:

> Oregonian Haruspex <no_e...@invalid.invalid> wrote:
>> eMacs is the modern Lisp Machine. How is it not?
>
> I agree. But elisp, the dialect it uses, has its limitations.
>
> Quoting from the elisp manual:
>
> GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common
> Lisp. If you know Common Lisp, you will notice many similarities.
> However, many features of Common Lisp have been omitted or simplified

< Perhaps somebody who has worked with real lisp machines can comment
< further.

I still have a symbolics from 1986. it runs fine. The biggest difference is
the hardware. the bitmapped display uses all PROMS. it needs to compile when
starting.

the mouse was ``taken by mistake'', with the manual. If you want pictures
let me know she is awesome but old.

the biggest difference with common lisp is lexical scope and namespaces.

[HASM]

steve g <sgoned...@gmail.com> writes:

> I still have a symbolics from 1986. it runs fine. ...

> If you want pictures let me know she is awesome but old.

Like these?

https://www.ifis.uni-luebeck.de/~moeller/symbolics-info/family.html

-- HASM

[Lars Brinkhoff]

Stefan Monnier wrote:
> all that demand for resuscitating all that LML code that's been
> waiting to re-see the light of day all these years.

That is being worked on.

[Madhu]

%
Catering to the hard-core Emacs folks is *hard*. I knew someone who
had PDP-10 assembly language in his .emacs file, and one day his
custom emacs extension worked again when he started playing with the
KLH10 PDP-10 emulator, and reused his .emacs there...

-- Ted Ts'o
%
(by way of fortunes/zork)

[Paul Rubin]

Obligatory: https://xkcd.com/1172/

[Arthur Gleckler]

The biggest thing that was lost is complete access to the source code, all the way down to the metal — not just being able to read it, but being able to interact with it through the debugger, and to update it even without rebooting. Modern systems are not living organisms in the sense that Lisp Machines were. Some versions of Smalltalk have preserved that to a degree, but usually not all the way down to the hardware like earlier versions.

[Paul Rubin]

Arthur Gleckler <a...@speechcode.com> writes:
> Modern systems are not living organisms in the sense that Lisp
> Machines were. Some versions of Smalltalk have preserved that to a
> degree, but usually not all the way down to the hardware like earlier
> versions.

Try Erlang sometime?

[Javier]

I guess that was possible because those dialects of Lisp and Smalltalk
kept source code as binary files, instead of being ascii text files.
For interpreted languages nowadays the source is a textfile that is
compiled to bytecode before execution.

As Paul Rubin said, Erlang still maintains the possibility to update
the code without rebooting, but I don't know its internals
and how exactly it manages to update the code without rebooting.

[Paul Rubin]

Javier <inv...@invalid.invalid> writes:
> As Paul Rubin said, Erlang still maintains the possibility to update
> the code without rebooting, but I don't know its internals
> and how exactly it manages to update the code without rebooting.

There is no significant magic IIRC. It's like a Lisp system with late
binding, so various system functions are attached to symbols with known
names. Then it is just a matter of replacing the old bindings with new
ones. There are a few other steps, and you have to do them in exactly
the right order to not mess everything up horribly, but it is a well
documented and supported feature of Erlang.

Non-Erlang nonstop systems (e.g. phone switches) typically don't work
like that. Instead, since on any nonstop system (including Erlang
systems) there is always at least one backup processor so the system can
keep running in case of a hardware failure, you just stop the backup
processor, upgrade its software the traditional way, restart it, stop
the primary processor so that the now-upgraded backup processor takes
over, upgrade the primary, and then swap back over.

I once asked Erlang's inventor Joe Armstrong (RIP) whether it would have
been simpler to upgrade Erlang systems the same way. He basically said
that method would have worked fine. The in-place upgrade scheme must
have some benefits in some situations, but in reality it is not that
important. It is rather complicated to use, and you have to test your
upgrade very very thoroughly before you actually deploy it, since it is
easy for stuff to go wrong.

Erlang hot-patching works a lot better during development and debugging,
where you can interactively change stuff as you hack and test. I could
imagine making an emergency patch that way to a production
high-availability system that had hit some kind of unforeseen snag. But
normally, you would not manually patch a running system in the field.
You'd prepare a new release for it, test it offline, and deploy it in an
organized way.