Symbolics Lisp Machine demo Jan 2013

You mean like the command line on Lisp machines, such as this example from Symbolics Genera? [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.

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

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. [VIDEO]

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] [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

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): [VIDEO] [LINK]

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

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; [VIDEO] . That shows off a LISP machine roughly as it was written in the 80s/90s.

> 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. [VIDEO]

It's JPEG, not PNG, but here you go, a demo by Kalman Reti (one of the Symbolics' developers): [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.

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: [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]

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

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: [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.

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: [VIDEO] He has another video where he does some actual hacking (smooth scrolling of sheet music for display while playing an instrument): [LINK]

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: [VIDEO]

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

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. - [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

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: [VIDEO]

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

>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] [VIDEO] [2] [LINK]

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