Live data from Hacker News

Ergonomics of the Symbolics Lisp Machine

lispm.de

31–40 of 94 posts

Re: Ergonomics of the Symbolics Lisp Machine

#31
post #8

Related: A huge collections of images showing Symbolics UI and the software written for it: http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....

Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures.

Re: Ergonomics of the Symbolics Lisp Machine

#32
post #15

that keyboard, along with the space cadet one, is an aberration. It is too complex for novices, with too many keys. And not optimal to the initiated, as key combinations are much more efficient. anyone with the slightest ergonomic knowledge cringe just by glancing at those things.

Both that keyboard and the space cadet have fewer keys than an IBM PC keyboard.

Re: Ergonomics of the Symbolics Lisp Machine

#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 static like today. There was no boundary between software development and software usage.

This reminds me of Smalltalk environment like Pharo. I recently realised that there were so much things in common between Lisp and Smalltalk environments (by Lisp environments I mean what we have today like SLIME+Emacs or LightTable). I also think that LightTable has a huge potential for being a successor of Lisp machines and _really_ integrated development environments.

Re: Ergonomics of the Symbolics Lisp Machine

#34
post #15

that keyboard, along with the space cadet one, is an aberration. It is too complex for novices, with too many keys. And not optimal to the initiated, as key combinations are much more efficient. anyone with the slightest ergonomic knowledge cringe just by glancing at those things.

I used this keyboard, as well as the ones for MIT-AI's graphics terminals from which it was inspired, and a 2nd generation of those (long story), at the same time I was using "standard" keyboards including the IBM PC's, and if you have the ability to ignore keys you don't need, you can focus on the home keys and Control and Meta (and ideally use the key left of A as rubout/backspace; it not being Caps Lock is not really a problem for coders).

The big issue is that the IBM layout is Ctrl-Alt, whereas the Lisp Machine was [too many other "bucky bits"]-Meta-Ctrl. Since I learned EMACS with the latter layout, for many years I just remapped those keys on other systems.

Re: Ergonomics of the Symbolics Lisp Machine

#35
post #4

Sometimes I wonder how much better the computing would be if Lisp Machines had succeeded in the industry and UNIX never left the lab.

Well, the 8-bits, Lisa, Macintosh, and Windows would have still been with us. So, I guess AT&T Sys V and BSD would have not happened which gets rid of Sun and makes one wonder what Dr. Tanenbaum and Mr. Torvalds would have worked on. I guess the second vector would have been what Steve Jobs would have built after leaving Apple (NeXTSTEP, the ultimate user friendly LISP machine?!?). Maybe Dylan would have worked in it…

The ancestors of InterfaceBuilder for NeXT STEP were written in Lisp, though not for Lisp Machines.

Re: Ergonomics of the Symbolics Lisp Machine

#36
post #35

Earlier quoted context omitted.

Well, the 8-bits, Lisa, Macintosh, and Windows would have still been with us. So, I guess AT&T Sys V and BSD would have not happened which gets rid of Sun and makes one wonder what Dr. Tanenbaum and Mr. Torvalds would have worked on. I guess the second vector would have been what Steve Jobs would have built after leaving Apple (NeXTSTEP, the ultimate user friendly LISP machine?!?). Maybe Dylan would have worked in it…

The ancestors of InterfaceBuilder for NeXT STEP were written in Lisp, though not for Lisp Machines.

Actually they were. The Interface Builder was sold also for the TI Lisp Machine - the TI MicroExplorer running in a Mac. Expertelligence developed the access to the Macintosh Toolbox for TI and also ported the Interface Builder to the MicroExplorer. Thus you could develop Mac-style user interfaces on the TI Microexplorer, including using the Interface Builder, which ran on the Lisp Machine and talked to the Mac for the UI display/interaction.

Here is a video which shows it running on a TI Micro Explorer, a Nubus Board in a Mac II.

https://vimeo.com/62618532

Re: Ergonomics of the Symbolics Lisp Machine

#37
post #21

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

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.

Re: Ergonomics of the Symbolics Lisp Machine

#38
post #36
post #35

Earlier quoted context omitted.

The ancestors of InterfaceBuilder for NeXT STEP were written in Lisp, though not for Lisp Machines.

Actually they were. The Interface Builder was sold also for the TI Lisp Machine - the TI MicroExplorer running in a Mac. Expertelligence developed the access to the Macintosh Toolbox for TI and also ported the Interface Builder to the MicroExplorer. Thus you could develop Mac-style user interfaces on the TI Microexplorer, including using the Interface Builder, which ran on the Lisp Machine and talked to the Mac for t…

It was originally written for LeLisp running natively on the Mac though.

Re: Ergonomics of the Symbolics Lisp Machine

#39

Site's down, here's a pastebin of the text: http://pastebin.com/6kkCTgjg Neither archive.org nor Google Cache have this. Weird. Video from article: http://vimeo.com/83886950 Image 1: http://i.imgur.com/r62FSfE.jpg Image 2: http://i.imgur.com/xsxutc3.png Image 3: http://i.imgur.com/zL9DFbr.png

Another video showing Symbolics: http://www.youtube.com/watch?v=o4-YnLpLgtk

Re: Ergonomics of the Symbolics Lisp Machine

#40
post #23

Earlier quoted context omitted.

It is a bit more nuanced than that, ARPANet was a lot of DEC machines, USC and USC-ISI had a number of DEC-10's on the network. Usenet was however primarily a bunch of UNIX (or UNIX like) machines. They traded in their modems for nifty connections to the Internet and carried a lot of the same protocols with them. Much of the Internet protocols were developed in college labs with the ability to 'plug in' different UNI…

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 the time I used a Dolphin (plus my group had some Dandelions which ran some custom microcode). They could also run Alto microcode by the way.

I preferred the MIT lispm environment better because I grew up with it. For a while I had a job where I had both a dandelion and a 3600 in my office; later I had two 36xx machines, one with a color display.

They were pretty fast for their time. The late, hyper-dynamic window system was probably too heavyweight for its time, especially when later translated over X, but I generally used the simpler base window system because it was faster.

It was the most productive (in terms of amount of useful code generated per unit time) system I have ever used and I still miss it. The Interlisp D, though quite different to use (and in some ways better), is a close second.

Post reply on HN