Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ergonomics of the Symbolics Lisp Machine

lispm.de

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Ergonomics of the Symbolics Lisp Machine

#41

Post by lispm »

mehmetemre wrote: post #33

> It was completely programmable with all source code. It was also not for 'playing' around - for that it was too expensive. As a software developer you could focus on your task and the whole operating system was supporting you. There was no piece of software that was not accessible in a few mouse clicks. Everything could be inspected, everything was up for modification. Software was live and dynamic. Not dead and st…

Pharo runs on top of something, running on top of something else, ...

Genera on the Lisp Machine runs on the metal. It is the process scheduler, it does handle the bus interrupts, it receives the network packets, it writes the bytes to the disk controller, it sets the bits in the graphics card, it writes the sound bytes to audio interface, the network packets are Lisp arrays, ...

Re: Ergonomics of the Symbolics Lisp Machine

#42

Post by bitwize »

cturner wrote: post #37
ScottBurson wrote: post #29

Earlier quoted context omitted.

Security was literally nonexistent. If you were at the console, you had control of the machine. Pwning one over the network was probably not difficult, though it wasn't the kind of thing people spent much time on back then.

Is that a bad thing? I wonder sometimes how much we lose in develop collaboration due to security layers. I can imagine running a cool multiuser image in a prototyping language like to.

If security is important, you lose something in terms of getting shit done. It's up to you or your organization what the tradeoff is. Fun fact: At one company I worked at, it was a matter of security policy that every machine in the company run the Bit9 binary whitelisting software. Every. Single. One. Including all the dev machines. In addition, it was decided that valuable corporate assets such as source control be airgapped from the outside network, making it difficult to run a dev machine that could access both the repo and the Web where all your documentation is. But Security was determined to be Priority One at that company, so productivity had to take the hit. If you develop the tech ten times slower and with ten times greater annoyance to your engineers, that was a worthy price to pay for not having it stolen by scary foreign spear phishers.

Re: Ergonomics of the Symbolics Lisp Machine

#43

Post by lispm »

gumby wrote: post #40
lispm wrote: post #23

Earlier quoted context omitted.

Lisp Machines were usually networked machines. Their were two branches: * Interlisp-D from Xerox were smaller machines, networkd with a server + printer. PARC developed networked collaborative software for them, the first remote GUI was written for Interlisp, the first IMAP client was written for Interlisp-D, ... * the MIT Lisp Machines were developed with CHAOS, an Ethernet-based protocol. TCP/IP was available early…

One small correction: the D machines weren't all smaller; there was the Dandelion (later sold as the Star), the Dolphin and the Dorado (which was a full rack, the size of a 32-bit CADR machine, and built of ECL logic). There were at least three different standard microcoded environments you could boot with, Interlisp-D, Smalltalk and Mesa. When I was at PARC if I worked late I could connect to a Dorado, but most of t…

Right, but the large one weren't sold, IIRC. Xerox sold the smaller ones, not the Dorado. That was also why some users upgraded to the Lisp Machines from LMI, Symbolics and TI: they had larger address spaces and could run larger software.

Re: Ergonomics of the Symbolics Lisp Machine

#44

Post by edwintorok »

eudox wrote: post #5
endlessvoid94 wrote: post #2

seems to be down, does anyone have a mirror?

Neither the archive nor Google Cache seem to have it.

I tried web.archive.org/save/" rel="nofollow">http://, but I got 'Access Forbidden for URI http://lispm.de/symbolics-lisp-machine-ergonomics'. The site itself loads fine in both firefox and chromium, but doesn't work with wget/curl. Probably some protection against robots / automated downloaders.

Re: Ergonomics of the Symbolics Lisp Machine

#45

Post by JoachimSchipper »

bane wrote: post #21

Out of curiosity, what were things that these systems did poorly or that we know not to do these days?

Current hardware wouldn't contemplate supporting only a single, oddball (even then) language.

(Although the C spec is carefully written to allow C-on-Lisp - e.g. by making it illegal to compare pointers not pointing to the same array, allowing a C-"object"-per-Lisp-object implementation - real C code tends to make assumptions.)

Re: Ergonomics of the Symbolics Lisp Machine

#46

Post by lispm »

JoachimSchipper wrote: post #45
bane wrote: post #21

Out of curiosity, what were things that these systems did poorly or that we know not to do these days?

Current hardware wouldn't contemplate supporting only a single, oddball (even then) language. (Although the C spec is carefully written to allow C-on-Lisp - e.g. by making it illegal to compare pointers not pointing to the same array, allowing a C-"object"-per-Lisp-object implementation - real C code tends to make assumptions.)

Symbolics sold ISO Pascal, C, Ada, Prolog and Fortran compilers for it.

I've used TeX and the original MIT X11 server on a Lisp Machine.

Re: Ergonomics of the Symbolics Lisp Machine

#47

Post by zokier »

lispm wrote: post #24
zokier wrote: post #20

Earlier quoted context omitted.

> Video from article: http://vimeo.com/83886950 The things that stood out to me were that a) boy, it was a slow system. Sure vi etc are more spartan, but even back then I'd imagine the were significantly faster than this Lisp machine. b) mouse was clearly the hot new thing, it is used lot more than what I think would be optimal.

That was a 5 MIPS machine with just 40 megabyte RAM. The UI ran over a 10 Mbit/sec Ethernet X11 connection on a remote machine.

I suppose I meant that they probably were bit ahead of their time and overly ambitious. Performance and especially latency are critically important for interactive applications. The designers must have been fully aware of the performance characteristics and hardware limitations at the time, but still they decided to ship such system. Maybe they should have taken a look in the mirror and notice that the hardware is not ready for what they were making and downscaled it to fit, then incrementally grow those features back when they become more practical.

Re: Ergonomics of the Symbolics Lisp Machine

#48

Post by cpr »

lispm wrote: post #41
mehmetemre wrote: post #33

> It was completely programmable with all source code. It was also not for 'playing' around - for that it was too expensive. As a software developer you could focus on your task and the whole operating system was supporting you. There was no piece of software that was not accessible in a few mouse clicks. Everything could be inspected, everything was up for modification. Software was live and dynamic. Not dead and st…

Pharo runs on top of something, running on top of something else, ... Genera on the Lisp Machine runs on the metal. It is the process scheduler, it does handle the bus interrupts, it receives the network packets, it writes the bytes to the disk controller, it sets the bits in the graphics card, it writes the sound bytes to audio interface, the network packets are Lisp arrays, ...

Yes, but don't forget the microcode level that runs the Lisp code. Some very small bits of the OS were written in microcode (as few as possible), IIRC. (It's been a long time since I was hanging around the AI Lab. ;-)

Re: Ergonomics of the Symbolics Lisp Machine

#49

Post by cpr »

The real ergonomics of the LispM were due to the wonderful Microswitch keyboards, which have never been equalled since. To use one was a kind of revelation into the the apotheosis of keyboard use.

(The old, original Tom Knight AI Lab keyboards were even slightly more wonderful; the later Microswitch LispM keyboards never quite equalled the originals in terms of tactilely satisfying feel.)

(For a long while after leaving MIT (ran the MIT-EECS LispM and DEC-20 machines) I used one of the custom-made Lawrence Livermore run of Microswitch keyboards, driving a custom 68K board which turned the up/down events into standard RS-232 for use with standard CRT terminals. I think I still have that keyboard somewhere in the now-long-abandoned kids' play junk.)

Re: Ergonomics of the Symbolics Lisp Machine

#50

Post by lispm »

zokier wrote: post #47
lispm wrote: post #24

Earlier quoted context omitted.

That was a 5 MIPS machine with just 40 megabyte RAM. The UI ran over a 10 Mbit/sec Ethernet X11 connection on a remote machine.

I suppose I meant that they probably were bit ahead of their time and overly ambitious. Performance and especially latency are critically important for interactive applications. The designers must have been fully aware of the performance characteristics and hardware limitations at the time, but still they decided to ship such system. Maybe they should have taken a look in the mirror and notice that the hardware is no…

The goal was not to have a fast vi, for writing applications in a slow way. If you wanted vi, there were other systems.

It was a system for research of development of advanced software, often with complex GUIs. Symbolics sold for several years into the CAD and 3d-graphics markets.

Post reply on HN