
Evaluating Vax Lisp 3.1 - mr_tyzic
https://netzhansa.blogspot.com/2018/08/evaluating-vax-lisp-30.html
======
lispm
> At some point, I brought a MicroVAX with me to a vintage computer
> convention, and a friend had his MacIvory Symbolics Lisp Machine on display.
> As the two systems were from the same era, we thought that we should try to
> bring up some network between them. My VAX ran a fairly recent version of
> VMS, though, and when we tried to establish a DECNET connection, the Lisp
> machine would signal an error and put us into a debugger. What got me hooked
> on Lisp was that my friend could display the source code of the failing
> DECNET device driver, figure out that the problem was the too-new DECNET
> version number that the VAX had reported in the connection setup packet, fix
> the Lisp code in the DECNET driver of the Lisp Machine and then continue the
> file transfer operation that had signaled the problem. I certainly
> understood that this would theoretically be possible back then, but I had
> never seen a system that would have that level of integration of operating
> system and programming language. I was intrigued.

~~~
kristianp
Makes one wonder if an OS should be built using LISP these days to make
available that kind of hackability. Or port Genera OS [1] to x86 or arm. The
languages used by the VPRI project were bootstrapped on lisp if I recall
correctly [2]. It would be great if that projects code was released as open
source too.

[1] [http://wiki.c2.com/?GeneraOs](http://wiki.c2.com/?GeneraOs) [2]
[http://www.vpri.org/writings.php](http://www.vpri.org/writings.php)

~~~
tjalfi
Movitz[0] is a Lisp-based environment for x86 hardware. I have only cursory
knowledge of Common Lisp and x86 assembly but found the code quite easy to
follow. It isn’t under active development but there is nothing stopping you
from dusting it off.

[0] [https://www.common-lisp.net/project/movitz/](https://www.common-
lisp.net/project/movitz/)

~~~
rjsw
There is a bug in the compiler that I never managed to fix.

------
protomyth
The language survey class I took as part of my CSci degree, had us use Lisp on
a MicroVAX. The resources that Lisp required versus the machine we were
running it on made it very much like programing a batch system. The terminals
were slow when Lisp was running. It was so bad we typed our programs out on a
PC and ftp'd it up to the VAX and then loaded it, check if we got the syntax
right, run it, and repeat. The whole interactive lesson was lost on us since
it would take forever to do anything. The only good that came out of it was
winning enough money at poker played in the lab to pay for pizza that weekend.

~~~
nils-m-holm
The VAX was really a beautiful architecture and a good fit for systems that
ran lots of small processes subsequently. However, it was also notoriously bad
at running LISP because of its huge page table overhead. A page was 512 bytes
in size, giving an address space of 2^23 pages. So when a process grew larger,
the machine started to swap out parts of the page table and everything went
down to a crawl. This is probably what you observed.

512-byte pages worked fine on a 18-bit or 22-bit architectures, like the
various models of the PDP-10 and the PDP-11, but were simply too small for the
VAX. So the VAX did solve the memory shortage of its predecessors, but in the
case of LISP at the price of abysmal performance when running memory-intensive
applications, which many LISP programs unfortunately were.

------
Jaruzel
This is slightly tangential, but it details my first real professional screw-
up on a VMS system.

My first serious job was working as a Junior Sysadmin on a large VAXCluster. I
literally had NO idea what I was doing. On my first day my boss said to me,
"Here's your account details, it's got the same rights as SYSTEM, if you screw
up, we'll fire you. Good Luck.". The senior admin showed me the ropes, and
especially the HELP command, and basically spent the next week typing HELP
followed by every command I encountered.

Fast forward three months, and I'm fairly comfortable with VMS, writing
scripts and improving some of the daily housekeeping tasks to make them faster
and more efficient. I'm working on the startup script that boots the cluster,
stepping through the existing one to understand what it does and I encounter a
command I've never seen before, so I duly flip terminal screens (VT420 dumb
terminal with dual inputs), and type HELP followed by the command.

Except I didn't actually type HELP. I just typed the command.

As I watched the terminal fill up with output, I realised what it did.
Basically it flushed all core processes out of memory. Including the one that
allowed people to logon.

Normally this would be a fairly embarrassing screw up requiring a simple
reboot, except that this VAXCluster belonged to the MoD, and it was running
military combat scenarios (wargames), and had been running a large war
scenario for several weeks, non-stop. Somewhere on the site where I was
working, there were two large rooms each filled with soldiers and each day
they'd been planning out their campaign tactics against each other and these
decisions were being plumbed into the running scenario in real time by an
operator.

I'd basically broken everything, and potentially destroyed the whole scenario.
The scenario was still running in memory, but no-one could talk to it anymore.
Rebooting the cluster was _not_ an option.

Immediately, white faced, I admitted to what I'd done. One of the 'real' VMS
coders on my team also went ashen. After lots of head scratching, he set to
work. I don't know in detail what he did, but from what I understood at the
time, he effectively manually restarted the 100s of processes that the Cluster
needed to operate, as if it was rebooting but without actually flipping the
switch.

Several hours later, the Cluster was fixed and running normally. I'd also not
been fired.

This event, left me with a massive appreciation of multi-user systems and how
one small error can affect 100s of people. A year or so later, I transitioned
into PC support, as Desktop PCs were slowly replacing the dumb terminals
across the site, and later on I started working for an international bank
where again networked PCs were new. I found that having cut my teeth and been
burned on a large multi-user system gave me an impact perspective that most
people working in the fledgling PC support industry didn't yet have.

Because of this, VAX/VMS systems will always be special to me.

