Why we need Lisp machines

I&#x27;m as big of a Lisp fan as can be. I&#x27;m a proud owner of Symbolics and TI hardware: a MicroExplorer, a MacIvory, two 3650, and two 3620. Not to mention an AlphaServer running OpenGenera.<p>Today, we have computers that run Lisp orders of magnitude faster than any of those Lisp machines. And we have about 3–4 orders of magnitude more memory with 64-bits of integer and floating point goodness. And Lisp is touted to have remained one of the most powerful programming languages (I think it&#x27;s true, but don&#x27;t read into it too much).<p>Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough.<p>We don&#x27;t &quot;need&quot; Lisp machines. We &quot;need&quot; Lisp software. What made a Lisp machines extraordinary wasn&#x27;t the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, interest, willpower, and&#x2F;or money.<p>Don&#x27;t get me wrong, there are some Lisp programmers today developing superlative libraries and applications [1], but the Lisp population is thin on them. I&#x27;d guess that the number of publicly known, interesting (by some metric), and <i>maintained</i> applications or libraries that have sprung up in the past decade probably fits on one side of a 3&quot;x5&quot; index card. [2]<p>Though I won&#x27;t accuse the article&#x27;s author of such, sometimes, I find, in a strange way, that pining for the Lisp machines of yore is actually a sort of mental gymnastic to absolve one for not having written anything interesting in Lisp, and to excuse one from ever being able to do so.<p>[1] Just to cherry-pick a recent example, <i>Kandria</i> is a neat platformer developed entirely in Common Lisp by an indie game studio, with a demo shipping on Steam: <a href="https:&#x2F;&#x2F;store.steampowered.com&#x2F;app&#x2F;1261430&#x2F;Kandria&#x2F;" rel="nofollow">https:&#x2F;&#x2F;store.steampowered.com&#x2F;app&#x2F;1261430&#x2F;Kandria&#x2F;</a><p>[2] This doesn&#x27;t mean there aren&#x27;t enough foundational libraries, or &quot;batteries&quot;, in Lisp. Though imperfect, this is by and large not an issue in 2022.

Meh the problem is &quot;Which Lisp?&quot; There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc).<p>In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don&#x27;t interoperate well. They haven&#x27;t built up a big ecosystem of reusable code.<p>Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others&#x27; code via Unix-style coarse-grained composition. (Not just pipes -- think about a web server running behind nginx, or git reusing SSH and HTTP as transports.)<p>You can also use link time composition. It takes some work but it&#x27;s better than rewriting your Common Lisp code from scratch in Clojure.<p>-----<p>Honest question: how do you communicate between two Lisp processes on two different machines? I know Clojure has EDN (which is sort of like JSON : JavaScript), but I haven&#x27;t heard of the solutions for other Lisps.<p>I wrote about this problem here: <i>A Sketch of the Biggest Idea in Software Architecture</i> <a href="http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2022&#x2F;03&#x2F;backlog-arch.html" rel="nofollow">http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2022&#x2F;03&#x2F;backlog-arch.html</a><p><i>&gt; The lowest common denominator between a Common Lisp, Clojure, and Racket program is a Bourne shell script (and eventually an Oil script).</i><p>I&#x27;ll definitely update it if there&#x27;s something I&#x27;m missing.<p>I would say the design of Unix is &quot;rotting&quot;, but the answer is to IMPROVE Unix. Not dream of clean slate designs that will never be deployed. Plus this post doesn&#x27;t actually propose anything. If you actually start trying to build your Lisp machine, I believe you will run into dozens of reasons why it&#x27;s not a good idea.

Some of this needs checking -- you could not run Unix on Symbolics hardware. LMI did have machines that ran both OSes -- but Unix was running on a separate 68000 processor; see, e.g. <a href="http:&#x2F;&#x2F;www.bitsavers.org&#x2F;pdf&#x2F;lmi&#x2F;LMI_lambdaOverview_1982.pdf" rel="nofollow">http:&#x2F;&#x2F;www.bitsavers.org&#x2F;pdf&#x2F;lmi&#x2F;LMI_lambdaOverview_1982.pdf</a><p>(3600-series Symbolics machines also had a 68k &quot;front end processor&quot;, but no Unix port was provided for it; they also ultimately had a C compiler that could generate code for the &quot;Lisp processor&quot;, but the code it generated was intended to run in the Lisp environment.)<p>It&#x27;s also worth noting that systems-level code for Symbolics machines (and, I presume, LMI as well) made frequent use of &quot;unsafe subprimitives&quot;, misuse of which could easily crash the machine. And, unfortunately, if you needed to, say, get anything close to hardware bandwidth out of the disk drives, some of this became well-nigh unavoidable, due to poor performance of the OS-level file system (LMFS).

This post would benefit from further expanding some of these statements.<p>&gt; UNIX isn’t good enough anymore and it’s getting worse<p>Why exactly?<p>&gt; A new operating system means we can explore new ideas in new ways.<p>LISP machines were not only OSes but also hardware. Is the author also proposing running this OS on optimized hardware or simply using our x86-64&#x2F;AMD&#x2F;M1 CPUs?<p>&gt; With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers.<p>Sure, but it also requires rewriting a lot of these things, introducing and fixing new bugs... It feels like the good ol&#x27; &quot;let&#x27;s rewrite this program&quot; that quite frequently doesn&#x27;t live up to the expectations [1].<p>[1] <a href="https:&#x2F;&#x2F;vibratingmelon.com&#x2F;2011&#x2F;06&#x2F;10&#x2F;why-you-should-almost-never-rewrite-code-a-graphical-guide&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vibratingmelon.com&#x2F;2011&#x2F;06&#x2F;10&#x2F;why-you-should-almost-...</a>

What ramblings.<p>Optane is the best performing SSD but the worst performing RAM you ever had. It is too expensive at any speed, even if Intel is losing money on it. HP memristors are vaporware.<p>LISP machines, Java machines, and similar architectures specialized for complex language runtimes are a notorious dead end. They just can’t keep up with performance-optimized RISC, pipelined, superscalar, SIMD, etc. architectures paired with compilers and runtimes that implement efficient abstractions (e.g. garbage collection, hotspot compilers) on top of those very fast primitives.

&gt; You could open up system functions in the editor, modify and compile them while the machine was running.<p>Why would you want to do that other than hot patching a system that can&#x27;t go down? Testing new changes requires more time than rebooting. If you just want to test simple changes, most debuggers can do that.<p>&gt; Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of.<p>And with a single address space you have win9x security.<p>&gt; A modern UNIX system isn’t self-contained. I have 4 UNIX systems on my desk (Desktop, laptop, iPhone, iPad) I’m contentiously using the cloud (iCloud for photos, GitHub for text files, Dropbox for everything else) to sync files between these machines. The cloud is just a workaround for UNIX’s self-contained nature<p>This is just your use habbits. Nothing is stopping you from using NFS or SSHS. Someone who feels the need to use iCloud for whatever trivial convenience it provides is unlikely to benefit from a Lisp machine&#x27;s ability to edit code on the live system.<p>&gt; Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems. We need a replacement, something that can be built for the modern world using technologies that are clean, secure, and extendable<p>The same thing will happen with any OS given enough time. Lisp is also not secure. It&#x27;s prone to side channel and eval bugs.<p>&gt; eliminate memory leaks and questions of type safety,<p>Lisp is not type safe.

I don’t really agree. I had a Xerox 1108 Lisp Machine in the 1980s and loved it, but special purpose Lisp hardware seems like a waste of effort. I set up an emulator for the 1108 last weekend, and yes, I really did enjoy the memories, and things ran an order of magnitude faster than on the 1108 in the 1980s.<p>Then, I appreciated my M1 MacBook Pro running SBCL, LispWorks, Haskell, Clojure, and various Scheme languages - all with nice Emacs based dev setups. Life is really good on modern hardware.

I think that, while the idea is solid (Unix is poorly-designed and we should have better) some of the specific ideas mentioned are lacking:<p>&gt; Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of.<p>No! Bad! We have enough problems securing software on <i>separate VMs running on the same metal</i>, single address spaces are completely out of the question until someone manages to build a feasible trusted compiler system.<p>&gt; Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems.<p>A lot of these problems could happen with a Lisp machine - you could have a billion different Lisps, for instance (although, to be fair, with better (i.e. non-Unix) OS design you wouldn&#x27;t need containers).<p>&gt; With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers.<p>This is partially true, but a <i>lot</i> of the complexity in modern software doesn&#x27;t come from Unix, but just...bad design decisions. Webtech doesn&#x27;t really care whether it&#x27;s running on Windows or Unix, after all.<p>Also, high-level CPUs are a bad idea: <a href="http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;the-high-level-cpu-challenge.html" rel="nofollow">http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;the-high-level-cpu-challenge.html</a><p>I think the good in this post is along the lines of: text bad, typed IPC good, runtime-aware OS good, standardized VMs good, interactive systems (Lispy stuff, Jupyter) &gt; batch-processing systems (Unix, C).

I&#x27;ve started using Mathematica recently. I quite like it: I&#x27;ve used Sympy before, which was good, but nowhere near as &quot;good&quot; as Mathematica. How does it compare to the Lisp Machine operating systems? There&#x27;s some vague resemblance to Lisp in treating symbols as a basic type of object. In the Mathematica use-case, these symbolic values are used to stand for algebraic variables or unknowns. Undeclared variables by default have symbolic type, with their own names being their values. (I know that other CASes do similar things here). Also, algebraic manipulations produce expressions which double as Mathematica code, which resembles the meta-programming features of Lisp. There&#x27;s even glimpses of reactive programming in the way you construct interactive plots.<p>I know this is &quot;uncouth&quot; because it&#x27;s commercial software, but Mathematica is one of the most interesting programs I&#x27;ve ever used. [edit] Might something like this be the future?

&gt; <i>With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers.</i><p>Oh man, wat?<p>I love lisp as much as the next guy.<p>But you <i>absolutely</i> can have library mess, memory leaks, and millions of lines of code using a Lisp. You arguably can have a &quot;multi-language&quot; mess, too, because Lisp gives you wonderful tools to create DSLs; I&#x27;d say creating a language that fits your needs, and then using it, is <i>the</i> right way to use Lisp.<p>I use Emacs daily, and see how an all-Lisp environment can make for a good, productive interactive experience. More efforts in this area would be quite welcome, but this is a shell, not a kernel.<p>I still suppose that systems software, and especially the key parts of an OS, need a language more like Rust than like Lisp, with a good affinity to raw hardware, and a ton of static guarantees.

The main problem with Unix right now is security &#x2F; permission control. Unix was built from the perspective that users potentially don&#x27;t trust each other, but users all magically trust the applications that are run. In the age of the internet, this doesn&#x27;t hold anymore, and we need strong permission control.

Who cares if Lisp is popular?<p>The &quot;lisp epiphany&quot; is real. Either you &quot;get it&quot; or &quot;you don&#x27;t&quot;.<p>I&#x27;ve been writing lisp programs for 50 years. I&#x27;ve been paid to program in 60 different languages but nothing compares with lisp.<p>There is an intellectual &quot;distance&quot; between a problem and its machine solution. I call this the &quot;impedence problem&quot;. Lisp lets you think at the most abstract and write to the most specific.<p>Writing changed the world. But if you give most people a blank piece of paper they don&#x27;t know what to do with such freedom. Lisp is the &quot;blank piece of paper&quot; of programming languages. Everything, literally everything, comes from you.<p>I loved my Symbolics machine. It was the closest expression of a &quot;thinking platform&quot; I&#x27;ve ever used. IDEs are horrible for thinking, ever interrupting at every keystroke.<p>Lisp isn&#x27;t &quot;popular&quot; because it provides a &quot;thinking platform&quot; you can shape to your thoughts.<p>Lisp will never be popular. The reason should be obvious.

For a somewhat complete history of LISP machines, I recommend reading &quot;Hackers: Heroes of the Computer Revolution&quot; [1].<p>[1] <a href="https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;8260364-hackers" rel="nofollow">https:&#x2F;&#x2F;www.goodreads.com&#x2F;book&#x2F;show&#x2F;8260364-hackers</a>

The problem with language wars is the people whom cannot be trusted with pointers, also cannot be trusted with lambdas or recursion.<p>The name of the game has always been to avoid directly insulting the bad programmers by making fun of the languages they use. Bad programmers have clustered in several languages over the course of my long career. Mostly they are the easiest most expressive languages, which would superficially seem to be an advantage, however they make it easy to express amazingly bad ideas. The harder to express languages require more work to express a bad idea thus somewhat filtering them out of that language&#x27;s pool.<p>People whom don&#x27;t understand the game think the game will be won if the bad programmers would have access to better languages for the first time in history. Despite the idea being decades old its always presented as a new idea.<p>There&#x27;s an authoritarian streak where if only we could remove access to the inferior languages then they&#x27;d have to use the better languages and we&#x27;d have better code. However you can&#x27;t force people to not use inferior tools and you can&#x27;t force them to learn to use better tools.<p>The graph of easy to write and code goodness is interesting and nonlinear. You can express very complicated ideas in lisp easier than in vb6 or perl or interpreted basic or spaghetti fortran. However, you can express very bad ideas easier in a &quot;bad&quot; language, so it accumulates interesting authors. There is always a crossover point where an intermediate complexity idea is equally hard to express in a simple language or a complex language. Frankly most of IT needs are and always will be below that point. So its counterproductive to demand difficult language for simple tasks, everyone laughs at &quot;Enterprise Java Hello World&quot; that is 100K lines of enterprise patterns.<p>Expressing ideas in computer languages is much like expressing ideas in everyday language. Some esoteric philosophy texts require a VERY large precise complicated hard to use and hard to learn vocabulary. Road signs do not. For in between jobs, trying to use a minimum number of language vocabulary words and lexical complexity would be wise. It would be a fools errand to try to cut half the vocab words from street signs to &quot;make driving safer&quot;, or an equally bad idea to force all road signs to be expressed as Shakespearean sonnets. The real world counterpart of &quot;Enterprise Java Hello World&quot; would be forcing the &quot;No U Turn&quot; street sign to be in the form of a Shakespearean sonnet.<p>The difficulty of tasks is usually under a power law, so its nice that we have lisp, but usually a bad idea to use lisp.

Part of the hype and hope of the &quot;OLPC&quot; laptops was that it would generate a &quot;Python machine&quot; userland, if not entire OS.

When the author talks about too many languages and libraries, I personally think he means the proliferation of Unix DSLs (some of which are Posix and some are not) like Make, Awk, Sed, BC, DC, shell-script dialects, Gnuplot (I know it&#x27;s not Posix but it was widely used once), xargs, Vimscript, ELisp. Each of these has its own quirks and random limitations. Each of these makes Unix unnecessarily complicated and difficult to learn, and they don&#x27;t even accomplish much that&#x27;s impressive. I also think they make the editing experience worse, because they prevent the use of IDEs or highly featured REPLs like the ones general-purpose languages have.<p>I imagine that a lot of this can be replaced with libraries for a general-purpose language like Python. In the case of Awk, BC and DC, Python&#x27;s standard library does everything these do without their strange quirks. Gnuplot can be replaced with umpteen plotting libraries like Matplotlib. Shell-scripting can be done in a Python dialect like Xonsh. I don&#x27;t know of a Python alternative to Make, but Make is a fairly perverse and ad-hoc language that looks ripe for being replaced by a library.<p>I don&#x27;t think a new operating system (however you define that) is necessary. I think you just swap out a lot of the crazy DSLs with one consistent general-purpose language. People will switch over when they want to accomplish things more easily (like me!). This is especially likely if you&#x27;re not a SWE but you want to do file system automation anyway. The DSL-heavy approach is too Byzantine for such people (like me!). And it&#x27;s mostly possible today.

If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp.<p>While the Plan9 mouse chording is cool (and could be kept), I would have everything also accessible via keyboard commands. 3 button mouse chording on a laptop trackpad is not fun.

Hardware LISP machines didnt survive the 1980s because you could emulate LISP on a general purpose CPU faster than a special machine. That is because faster new general purpose CPUs cane out every year or so, while it took 3-5 years for the next special purpose CPU.

The Lisp machine of today is MirageOS: <a href="https:&#x2F;&#x2F;mirage.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mirage.io&#x2F;</a><p>A unikernel that throws out the legacy of Unix and starts fresh to build a library operating system, it&#x27;s exactly what OP describes:<p>&gt; With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers.<p>Even better, Mirage is programmed in OCaml, which is basically a statically-typed facade over Lisp (or Scheme). That&#x27;s the modern Lisp machine of today. It even takes care of security nightmares like this:<p>&gt; Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of.<p>Because in the Mirage model is program is a separate OS image and they can communicate only over defined service interfaces.

Leaving the specific idea of the Lisp Machine aside, today there we have a tremendous advantage over the past when it comes to creating the kind of full, self-consistent systems Lisp Machines -- and systems like Smalltalk or Oberon, etc -- represent. Today we have widely accepted communications and data format standards. This is something that really isolated system diversity in the past, where you were &quot;stuck&quot; in some given computing system and had little ways of interacting with other types of computing systems. We have figured all of that out.<p>We should hope to see a flourishing of new and diverse systems again, since now all one need to do to interact with everyone else is merely (and I know it&#x27;s a slog) implement tried and true standards.

If I&#x27;d like to try the emulated Lisp Machine linked to (<a href="https:&#x2F;&#x2F;tumbleweed.nu&#x2F;lm-3&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tumbleweed.nu&#x2F;lm-3&#x2F;</a>), is there a straightforward getting-started doc? The page lists multiple links for each of the simulator, the bootstrap, the documentation, and umbrella projects (&quot;to make it easier setting up&quot;, though for this one it&#x27;s only a binary choice). This is not counting the multiple system sources, since only one is recommended right now.<p>This suggests it&#x27;s too much work for now if you&#x27;re just curious, but it&#x27;d be great to be wrong.

I agree that we need more operating systems, but...<p>&gt; These machines used specialized hardware and microcode to optimize for the lisp environments (Because of microcode you could run UNIX and the Lisp OS at the same time).<p>This is a dead end in the history of CPU design.<p>Processors are all vaguely similar these days. Your CPU is built around ALUs which typically take one or two inputs, produce one output. Around that, you build some logic for shuttling these inputs and outputs to and from registers, or in some cases, to and from memory.<p>The core here, the ALUs, have gotten more and more sophisticated over the years, but the wiring on the outside has remained fairly modest relative to its excesses back in the day. I&#x27;d say that the lesson here is simple: rather than add complicated operations to make your high-level language faster, do the complicated stuff in software... which gives you a lot more flexibility, and the combined hardware-software stack ends up being faster and cheaper anyway.<p>&gt; With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers.<p>I can understand where this notion is coming from... but practically speaking, switching to Lisp doesn&#x27;t eliminate memory leaks or questions of type safety or binary exploits. Even with an idealized version of Lisp, I don&#x27;t think these problems could possibly go away. Neither garbage collection nor systems like Rust really &quot;solve&quot; memory leaks, they just provide strategies to make memory leaks less common.<p>The same thing applies to type safety. You&#x27;d have to define &quot;type safety&quot; very narrowly to say that Lisp solves all type safety problems. Again, I can understand where the author comes from--it&#x27;s kind of an intuitive notion of type safety, that you don&#x27;t end up operating on an incorrectly typed pointer, or something like that. But the notion of type safety is much more broad than that these days.<p>And the C&#x2F;Unix strategy is actually pretty good, too, when it works--contain memory leaks within a process, then terminate the process.

Just run Emacs as your Lisp Virtual Machine. All it really needs is a good editor, but evil-mode is kinda serviceable.

&gt; They were programmed in lisp the whole way down and could be run code interpreted for convenience or compiled to microcode for efficiency. You could open up system functions in the editor, modify and compile them while the machine was running. Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of.<p>So this is basically expanding Emacs to <i>actually</i> be the operating system. There&#x27;s definitely some allure to it. Awhile back, I was hacking on the Lem editor for Common Lisp, using the Lem editor itself. It was great until I made a mistake in some code that restricted my ability to edit the code, sort of like performing brain surgery on my self and snipping a nerve that controlled my arms. It was amazing to have that immediate feedback loop, but in a world that is striving to find new ways to minimize human error, I&#x27;m just not sure it&#x27;d hold up.

&gt; With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack<p>This seems like the kind of goal that&#x27;s only palatable to a very few people nowadays. Specifically, the people who want to use that language, toolchain, and libraries, <i>and nothing else.</i><p>These days, I don&#x27;t think that that&#x27;s ever going to allow for enough of a community to support more than a relatively self-contained hobbyist scene. Which there&#x27;s absolutely nothing wrong with that; personally I wish there were more compelling tinkering-oriented platforms; I&#x27;m a little meh on Unix too. But the article seems to be advocating rather loftier ambitions.

I have had the same thoughts before and come to a similar conclusion. I believe it&#x27;s not about the language. It&#x27;s about the features: runtime code editing, single address space, program interoperability. Lisp could be replaced with C or anything else. Unfortunately this is the hard part. No one is about to design completely new hardware or architecture for this, as it makes no economic sense. So we just get a shiny new language every few years, and nothing really changes.

IMO the biggest difference is that that there is no longer a difference between binaries and libraries. Everything is a library. In UNIX there are a bunch of utilities which you just can&#x27;t use from C. Also the idea of just passing data structures around instead of using a pipe passing streams of characters around is an improvement since there is no longer the need to serialize &#x2F; deserialive it.

The future is already here, but unfortunately it&#x27;s programmed in elisp and still lacks a decent editor.

So it&#x27;s interesting to note modern hardware is only 60x faster than Lisp machines when it should be 1000x. Weirdness of Lisp, turns out hardware isn&#x27;t some random thing. And harder to compromise than modern stuff, by a huge amount, real actual security improvement.

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.<p>Here&#x27;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. - <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=o4-YnLpLgtk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=o4-YnLpLgtk</a><p>Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible.<p>The same was true of the Canon Cat, Hypercard, Ted Nelson&#x27;s Xanadu project, Smalltalk, and a number of other early computing systems.<p>The main feature common to all of these systems is that they all <i>preserve context</i>. 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&#x27;t allow the broken links (and lost context) that now plague the web.<p>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&#x27;s reasonable that you could import a routine in a language you aren&#x27;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.<p>There&#x27;s nothing stopping an open source project from taking elements of these existing systems and moving forward from that basis. It might be profitable to include ideas such as Coloring of the Source text to label intent, such as in ColorForth.<p>Also, consider &quot;Literate Programming&quot; - Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code.<p>You could also add the ability to store graphics and other data along with the source code.<p>Of course, if you are required to run code you didn&#x27;t write and don&#x27;t trust, your operating system <i>must provide</i> means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model.<p>Sorry it was a bit of a ramble, but this seemed to be a call for ideas, so I ran with it.<p>PS: In the past, getting your vision of Computing required building a machine, and then getting it manufactured. Now it just requires that you make it work in a VM, Raspberry Pi, or web browser window.<p>It is MUCH easier to try out and&#x2F;or create alterative systems now that it has ever been in the past.

Reposting this from the 2014 HN discussion of &quot;Ergonomics of the Symbolics Lisp Machine&quot;:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7878679" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7878679</a><p><a href="http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-lisp-machine-ergonomics" rel="nofollow">http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-lisp-machine-ergonomics</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7879364" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7879364</a><p>eudox on June 11, 2014<p>Related: A huge collections of images showing Symbolics UI and the software written for it: <a href="http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-ui-examples&#x2F;symbolics-ui-examples" rel="nofollow">http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-ui-examples&#x2F;symbolics-ui-examples</a>....<p>agumonkey on June 11, 2014<p>Nice, but I wouldn&#x27;t confuse static images with the underlying semantic graph of live objects that&#x27;s not visible in pictures.<p>DonHopkins on June 14, 2014<p>Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye.<p>I&#x27;ll attempt to explain the deep implications of what the article said about &quot;Everything on the screen is an object, mouse-sensitive and reusable&quot;:<p>There&#x27;s a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can&#x27;t remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system.<p>It dumped him into a &quot;cold load stream&quot; where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc).<p>He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the &quot;Please proceed, Governor&quot; button, and was immediately back up and running where he left off before the crash, like nothing had ever happened!<p>Here&#x27;s another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community:<p>ftp:&#x2F;&#x2F;ftp.ai.sri.com&#x2F;pub&#x2F;mailing-lists&#x2F;slug&#x2F;900531&#x2F;msg00339.html<p>Also eudox posted this link:<p>Related: A huge collections of images showing Symbolics UI and the software written for it:<p><a href="http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-ui-examples&#x2F;symbolics-ui-examples.html" rel="nofollow">http:&#x2F;&#x2F;lispm.de&#x2F;symbolics-ui-examples&#x2F;symbolics-ui-examples....</a>

The trend seems to be toward statically-typed languages, with the exception of the adoption of Python being used for data. I also prefer having more problems being found before deploying and running on production data.<p>Dynamic typing is great for prototyping, early development, and for small teams. If your definition of success is greater than that I would choose differently, or port at a good time early on.<p>And if someone were to ask me to join a company using lisp, I would hope that it&#x27;s Clojure, though arguably not a Lisp, is better it that it will vary less between usages. This gives it a better chance of a growing ecosystem.

You could do some powerful things with LISP machines but I think the underlying assumption is that everything is written in LISP, or compiles to LISP (or its underlying bytecode). That places restrictions on what you can do. For example, does it do high-performance multithreading and SIMD right?<p>Also not sure LISP machines solved security as well as modern-day Linux does. I think it was just less of a concern back then, because you knew most of the people who were on the network.

&gt; genera<p>eh, if it&#x27;s gui is anything like clim which was based off of it, no thank you big time

The JVM is my lisp machine.

UNIX is fine. UNIX philosophy is an issue, along with C, and the fact that everything now is mobile and web based and the tools aren&#x27;t well suited to offline&#x2F;nonSaaS stuff yet.<p>Linux is slowly becoming a standardized, integrated platform. I don&#x27;t see why it can&#x27;t be evolved to have all the main advantages of a LISP machine.<p>I also don&#x27;t see how that solves dependency management. No matter what, if you build against something and it changes, stuff breaks. That&#x27;s the main issue with Linux.<p>It also doesn&#x27;t solve microservices being kinda hard and needing manual configuration specifically for the setup, rather than the one size fits all style of monolithic desktop software. That&#x27;s an application architecture challenge.<p>Nor does it solve cross-platform.<p>Linux does have problems and could learn from LISP machines(Although I&#x27;d rather we have TypeScript machines or Python or something, LISP is pretty far from what I want a language to be, and is meant for creativity and expressiveness rather than Ada-like safety and boring hacker-repelling Java-like standardization).<p>But a lot of issues go away if you pretend everything other than Debian and Red Hat don&#x27;t exist.