Skip to content
HHackerTube.videoSurprise me

Symbolics Lisp Machine demo Jan 2013

Symbolics Lisp Machine demo Jan 2013 on HackerTube: recommended by 5 Hacker News commenters across 5 separate months, 2014–2024.

Kalman Reti

demo · evergreen

Open on YouTube

Symbolics developer Kalman Reti gives a short introductory demo of a Symbolics Lisp Machine running Genera in an emulator. It shows the context-aware command line, typed on-screen objects, and the live-editable system, including swapping in a C-compiled JPEG decoder.

Why Hacker News recommends it

The go-to demo whenever HN discusses what Lisp machines were like and what modern shells and editors lack.

people recommended it
5
separate months
5
strong recommendations
1
discussed on HN
2014–2024
“It makes working on VSCode today look like banging rocks together”
— hcarvalhoalves, Oct 2024, in “The Rise of Worse Is Better (1991)”

What HN commenters said

20 Hacker News comments link this video. Each one links back to its thread.

hcarvalhoalvesOct 2024Strongly recommends

See these demos for the kinds of interactive systems LISP enabled back in the day: ▶ this video [link] It makes working on VSCode today look like banging rocks together, let alone 30 years ago.

in “The Rise of Worse Is Better (1991)” · View on HN

yourapostasyOct 2023Recommends

>My dream is to make everything visualizable at runtime. Check out demos of the old Lisp Machines, [1] is a brief overview demo, [2] links to a timestamp with a view of some simple diagramming, but I’ve seen TI-Symbolics beasts routinely display complex relationships in Lisp code on their massive (for the time) bitmapped screens. The limitation was the end user managing the visualization complexity. With open source llvm, clang and similar making available abstract syntax trees and even semantic analysis and type checking results, LLM’s assisting with decompiling binary blobs, and modern hardware (goggles, graphics cards, and so on), I sometimes wonder how close we can come to reproducing that aspect of the Lisp Machine experience on open source operating systems. [1] ▶ this video [2] [link]

in “Making Hard Things Easy” · View on HN

rmlApr 2021Recommends

If you are into Lisp Machines, this talk on Symbolics by Kalman Reti (who worked there) is worth watching (1h): [link] If you only have 15 minutes, he gives another demo here: ▶ this video He has another video where he does some actual hacking (smooth scrolling of sheet music for display while playing an instrument): [link]

in “What have we lost? [video]” · View on HN

mikelevinsMay 2020Recommends

There's this recent video showing a little of what the Pharo Smalltalk environment is like: [link] The video was made by a Ruby programmer, rather than an experience Smalltalker, so it's more a newbie showing you cool things he's discovered, rather than an expert showing the power of the system. On the other hand, there's this one: ▶ this video That one is an expert, Kalman Reti, showing some of what it's like to work with a Symbolics Lisp Machine. (It's not a real Lisp machine; they're all at least thirty years old now; this is an emulator running the old Symbolics OS on Linux). Go to YouTube and search for Rainer Joswig and you'll find a few video demos of Lisp Machines and MCL and so forth. Finally, here are a few images from about eighteen years ago, also from Rainer. They show various views of the Macintosh Common Lisp and SK8 environments. It's not an experienced user showing you around, but at least you can get some idea what the environments looked like: [link]

in “Ask HN: Production Lisp in 2020?” · View on HN

zaarnJun 2019Recommends

Since he did AI work in the 50's, probably a lot of his work was written in LISP or IPL, which had many of the concepts that LISP later used. Most of his high-profile inventions (Computer mice, Hypertext, Interactive Computers) were first commercialized on LISP machines in the 80s. LISP Machines also pioneered some other concepts such as windowing ystems, graphic rendering, modern networking, garbage collection, etc. There is a fun little demo on youtube here; ▶ this video . That shows off a LISP machine roughly as it was written in the 80s/90s.

in “Mezzano – An operating system written in Common Lisp” · View on HN

thrown_22Nov 2022Cites it

I've ran chsh on top of a (virtual) Guix(SD) installation. It was rather nice but is still _not_ a lisp machine: ▶ this video

in “Unix as a tool forge and how Emacs fits in Unix philosophy” · View on HN

Show 14 more comments
mikewarotMar 2022Cites it

The key thing about those type of systems was the ability to reach down into the system and edit the code of the system currently in operation. Here's a demonstration of Symbolics Open Genera (TM) 2.0, demonstrated running in a virtual machine. It is noted by the author of the video in the first minute or so that even in emulation, it is much faster than the original machines. - ▶ this video Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible. The same was true of the Canon Cat, Hypercard, Ted Nelson's Xanadu project, Smalltalk, and a number of other early computing systems. The main feature common to all of these systems is that they all preserve context . In Genera, Oberon, Canon Cat, Hypercard, and SmallTalk the source was always available. (as far as I know). In Xanadu, the main functionality of the web was present, but it wouldn't allow the broken links (and lost context) that now plague the web. I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments. There's nothing stopping an open source project from taking elements of these existing systems and moving forward from th

in “Why we need Lisp machines” · View on HN

bitwizeMar 2022Cites it

You are aware that Lisp machines understood several different flavors of Lisp? The Symbolics ones understood Zetalisp and Common Lisp at least. Were they on the market today they could be convinced to run Clojure and Scheme as well. There are a few old-timers developing Common Lisp applications to run on modern hardware, using Symbolics hardware. In fact, Symbolics shipped compilers for other non-Lisp programming languages, including C and Ada. These interoperated smoothly with Lisp code, much more so than they do under Unix. In this demo, Kalman Reti compiles a JPEG decoder written in C, and replaces the Lisp JPEG decoder that came with the system with it, yielding a performance boost: ▶ this video

in “Why we need Lisp machines” · View on HN

hprotagonistMay 2021Cites it

The animations in this post remind me of nothing more than a Symbolics LISP Machine: ▶ this video which also had semantically driven clickable data structures one could use to build up a command line invocation. In about 1982.

in “CLUI: Building a Graphical Command Line (2020)” · View on HN

posobinApr 2021Cites it

There are 30(!) comments on HN linking to this video, including discussions of Bret Victor's "Learnable programming", using Lisp in production from last year, comparisons with Smalltalk, a thread with examples of beautiful software, and more: ▶ this video

in “Symbolics Lisp Machine demo (2013) [video]” · View on HN

hhas01Dec 2020Cites it

Doesn’t have the beautiful Display Postscript/LeX-esque typography that I want, and less said about Lots of Irritating Silly Parentheses the better, but even 1980s tech was doing it better: ▶ this video I think there are lessons to be had from the likes of Smalltalk and Logo too. Highly expressive without insane levels of cryptic inconsistent punctuation rules and UX man-traps.

in “A terminal-based workflow for research, writing, and programming” · View on HN

tsimionescuNov 2020Cites it

The terminal is exactly an example of an app-centric workflow and why it is easier to build and/or easier to use than an API focused one. If you want to see a no-apps workflow, something like the Genera LISP OS was probably much closer[0]. People choose to use apps like ls, cat, less, echo, touch, find instead of using the FILE* object directly with readdir(), stat(), read(), write(), open(), creat() etc. All of the apps are designed to have human-readable output first, lots of options for controlling that output to make it as readable as possible etc. However, none of them exposes a rich model for its output that would make it possible to easily integrate it into more complex workflows. Instead, we rely on yet other apps, like sed, grep, xargs and essentially copy-pasting text between these apps (this is all that pipes really are, essentially). This becomes even more obvious when you use stuff like gcc or gdb, which have extremely rich and potentially useful layers of representation that they refuse to expose at all, even as APIs - only text is allowed in the interaction. Hell, the MS Office suite is a better example of a no-apps workflow, since each of the Office UIs has a deep understanding of the data produced by the others, and you can combine these in meaningful ways - much more so than terminal apps (for example, Word can show a portion of a spreadsheet without you having to guess at what contents it might have and how to parse it, like you would if you want to expose

in “Programs are a prison: Rethinking the building blocks of computing interfaces” · View on HN

p_lJan 2020Cites it

It's JPEG, not PNG, but here you go, a demo by Kalman Reti (one of the Symbolics' developers): ▶ this video It shows a debug session where C code running on the lisp machine (VLM in this case, unknown variant of the VLM though) is debugged to fix JPEG decompression error.

in “Lisp Symbolics Macivory 3 with loaded software” · View on HN

lispmDec 2019Cites it

> No, other languages (most of them) don't have real REPLs. What they have, at best can be categorized as "interactive shells". > Try Racket, Clojure, Clojurescript, Fennel, Chez. Give Lisp an honest, heartfelt attempt to learn it. Compared to actual Lisps, some of these have mostly interactive shells. ▶ this video

in “A programmable programming language (2018) [pdf]” · View on HN

pmoriartyOct 2017Cites it

Video of a Symbolics Lisp Machine (in Brad Parker's emulator).[1] Not surprisingly, it looks a lot like Emacs (or vice-versa). [1] - ▶ this video

in “A few things I know about Lisp Machines” · View on HN

vmorgulisMar 2016Cites it

Oberon, TempleOS or OpenGenera. These projects are vertical, consistent and use only one programming language. In OpenGenera, everything displayed on the screen is typed and can be retrieved as an s-expression (like in a web browser): ▶ this video [link]

in “Ask HN: What are some examples of beautiful software?” · View on HN

pjmlpJan 2016Cites it

Xerox controlled the whole stack, they invented it for their systems. So these workstations where an whole stack OS. You can read about their implementations on the links I provided before. Additionally, you can get the original Smalltalk-80 from from Stephane's web site. [link] This is a very ruft idea how it felt to use a Smalltalk workstation: [link] [link] The REPL was what is known in Smalltalk as transcript. Similarly the Interlisp-D workstation also had they own mixture of REPL and editing [link] Some of the ideas that lived on the Lisp Machines afterwards [link] ▶ this video Mesa was a memory safe system programming language created at Xerox, as an evolution from Extended Algol to replace BCPL. Niklaus Wirth based his Modula-2 design on it. Shortly thereafter they updated Mesa into Cedar, which added support for RC with local GC for cycle collection. The system then got called Mesa/Cedar. It allowed the same interactive experience as the other workstations, but using a GC enabled systems programming language. The REPL provided nice features, like auto-suggestion when a typo would cause a compilation failure. It is also probably the first graphical debugger for a strong typed language. Any OS API could be used on the REPL by typing modulename.procedure , which could use other OS APIs to get its input from different sources. An idea Wirth adopted into Oberon. You can see how all three environments looked like here: [link] And yes, Powershell alongside .NET is probably the cl

in “Announcing Wolfram Programming Lab” · View on HN

agumonkeyJun 2015Cites it

I am really curious about how much parsing and formatting occupy *nix source code. (IIRC 30% of ls), and if it would be a good idea to decouple the way you mention it. my json-infused distro is still on my mind. ps: this lisp machine talk mention how 'programs' (I guess functions) exchanged plain old data rather than serialized ascii streams making things very fast. There are caveats of adress space sharing though but it's another nice hint we could investigate other ways. ▶ this video

in “Unix is not an acceptable Unix” · View on HN

ScudsOct 2014Cites it

This demo appears to be running on an emulator instead of an actual antique piece of hardware but you can get the idea. ▶ this video the AI winter is something you don't hear too much about. [link]

in “Rich Command Shells” · View on HN

eschatonMay 2014Cites it

You mean like the command line on Lisp machines, such as this example from Symbolics Genera? ▶ this video The command line is contextually intelligent and presents interactive graphics and text. Not a simulation of a teletype on a simulation of a character terminal.

in “Pixel graphics in terminal” · View on HN

Topics & tags

History of computingFunctional programmingGUI, HCI & interface historysymbolicsgeneralispreploperating systemsuser interfaces