[s1gnp0st]

We will carry this beautiful artifact forward with us until all its lessons have been learned.

There was composability and fine control in these systems that is still not present in modern systems. That's not needed for everyday consumers, but boy is it lovely when you're a programmer.

[pjmlp]

I feel that during the last two decades only Java and .NET ecosystems have come close to the experience, including Android and Powershell/Windows/.NET into the mix, naturally with caveats and plenty of "yes but" counter arguments.

I consider a lost opportunity not to have turned ChromeOS into a kind of Smalltalk like experience with a mix of Flutter/Dart.

Naturally one can argue Common Lisp experience with Franz and Lisp Works, Raket, or Smalltalk, are the closest to the Lisp Machine ideas, but their mainstream opportunity is now lost.

[wk_end]

Both the Java and .NET ecosystems are monumental (in every sense of the word) engineering accomplishments, but they don't strike me as very similar to the ultra-dynamic, introspective Lisp Machine experience. Can you elaborate on that a little bit?

FWIW, the browser (though still far off) feels closer to me, with the ability to instantly pop open a DevTools console and inspect the state of everything, as does Apple's Cocoa-based stuff from my limited exposure to it, maybe not surprising given its Smalltalk heritage.

[pjmlp]

You have to think about the whole ecosystem and not only the VM.

Dynamic nature of the runtime, being able to plug agents, changing code dynamically, the IDE experience inherited from Smalltalk vendors that jumped into Java, VisualVM and JFR, ETW, runtime APIs to the JITs, self hosted implementations, nowadays out of fashion, sending bytecodes for RPCs and network agents (RMI, .NET Remoting, Jini), are some of the reasons.

[brabel]

Exactly... the JVM is incredibly dynamic. It's gone totally out of fashion because of security and complexity, but I used to enjoy using OSGi to load just about any Java library into the runtime by typing its Maven coordinates, then immediately start using the library from a shell... and then just remove that lib if I didn't "like it" and it would be gone as if it never existed... I don't think a lot of people realize you can quite easily do that kind of thing on the JVM.

[whartung]

The feature and bug of the OSGI experience is its rather coarse granularity. It’s finer grained than, say, a WAR, but obviously much different than something akin to the Smalltalk or, to a lesser extent, Common Lisp.

That said, make no mistake, an OSGI module can easily fall into that sweet spot of compiling and reloading fast enough to fall within the cognitive loop of effectively being “instant”.

And if you organize your code well, other parts of the overall app are (mostly) unaware something has changed. Java can be quite dynamic but has not formalized things like dynamic class change lifecycle. OSGI does expose that, and lets the rest of the code tap into that so it can handle change more robustly.

[pjmlp]

Another alternative is to use JVM plugins like JRebel.

[pjmlp]

Yeah, it is no accident that a JIT designed originally for Strongtalk ended up becoming the first JIT for Java.

And .NET by being "Java 2.0" after the J++ lawsuit, inherited most of the same dynamism, alongside the ability to support VB capabilities, which by VB 6 were also quite nice.

[zozbot234]

Part of the idea of WASM components is to support these same tricks with a more modern, better performing standard platform.

[pjmlp]

That is the sales pitch, the reality is that 10 years later it is still catching up with features offered by other bytecode formats explored since UNCOL came to be in 1958.

[GTP]

I'm too young to have ever touched a lisp machine, but I heard many opinions about them. If you used one, could you please briefly share your experience?

[EdwardCoffin]

I think the best description of the kind of thing the lisp machines (the Symbolics ones, at least) supported is described in this thread mostly carried by Kent Pitman [1]. I'd at least read all of the comments he wrote as well as whatever else you need for the context he is posting in.

Edit: this thread too [2]

[1] https://groups.google.com/g/comp.lang.lisp/c/QzKZCbf-S6g/m/K...

[2] https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/X...

[nickpsecurity]

Well, it's a combination of the hardware, OS, IDE, and language. Modern languages and VM's have caught up to many features of the Lisp machine. I've read lots of people's comments about them along with its documentation. Let me highlight a few things you might still like.

The language is highly dynamic, supports types for better speed, macros let it rewire itself to better express concepts, it is interpreted for instant development, still compiled with good performance, safer by default than many compiled languages, and you can edit the code and save state of running programs. I've just named off advantages of all kinds of programming languages all mixed into one. The flexibility was so strong that, as new paradigms were added (eg OOP, aspects), they could just bring in a library to make the language itself do that.

Aside from live debugging, my favorite feature when trying Lisp was per-function, incremental compilation.: make a change within a function, press a button, that individual function was compiled (sub-1-second), and that got loaded into the system for live interactions. I could iterate about as fast as I could think or type with the code still being fairly quick. It was mind blowing.

Today's machines have OS's in one language, supporting libraries might be in another, there's often a runtime with its own style, the app language itself for the logic, and usually one for the web browser. The mismatches between these languages can cause all kinds of headaches. Debugging them takes different tools. In a Lisp Machine, everything from the OS to the IDE to your apps were written in Lisp. IIRC they came with source. Any failure in any layer loads up in the same IDE with code in same language.

The IDE was also fully-featured for its time. Today, we have a lot of good IDE's. I don't think most of them share a language, source, and libraries with your apps, though. I'd like to see a comparison between top IDE's today and the Lisp Machine to see where today's tooling is stronger or weaker.

Those are a few things that come to mind. I assure you that my experience trying to code in native languages was way different in both development speed and debugging. Learning Python now, it's good for rapid development but not as flexible or compiled. Lisp would give me all that.

Many more ecosystems are using Python, though. By using Python, I get to use every library they build, guide they write, and maybe get paid for my code. Odds of all of that go down when using Lisp. Such social factors, along with high cost of Lisp Machines, are a huge part of why they disappeared. Less-powerful languages are going strong. If using a Lisp (eg Clojure), it's often tied to platforms written in non-Lisp languages.

[linguae]

To add, I believe the biggest factor in the death of the Lisp machine market wasn’t the software, but market shifts in the 1980s. For one, Lisp had a strong association with symbolic artificial intelligence, and during the AI boom of the 1980s, Lisp machine vendors such as Symbolics and Xerox were successful selling Lisp machines to companies and institutions that did AI. The Reagan-era military was a major customer of Symbolics Lisp machines, if I recall correctly. However, this AI boom was followed by a long AI winter that started in the late 1980s and didn’t end until the machine learning/big data boom of the 2000s. By then Lisp was no longer the language of choice for AI practitioners; it’s now largely Python (and sometimes R) backed by numeric computing code written in C, C++, and even Fortran.

In addition to the AI winter, Lisp machines were facing performance and cost challenges from RISC workstations. Suddenly not only did Lisp programs run faster on Unix workstations, but they were cheaper, too. Due to the combination of the AI winter and competition from the Unix RISC workstation market, many Lisp machine vendors exited the market, pivoted, or shut down in the late 1980s and early 1990s. Symbolics Open Genera was part of this pivot; it is essentially a Symbolics Lisp Machine VM originally running on top of a DEC Alpha processor running a proprietary Unix from DEC.

It’s just unfortunate that Symbolics and Xerox didn’t make Open Genera and Interlisp-D (which was similarly ported) more available, which could have been a strong contender to Java in the 1990s (the Common Lisp Object System blows the socks off C++ and Java) and to Python and Ruby in the 2000s, and could’ve introduced many of the benefits of having such a flexible development environment to a much wider range of developers at an earlier point in history…who knows what tooling we’d have today if we picked up where Lisp machines left off in the 1990s. The closest we’ve gotten to these Lisp environments are GNU Emacs, Racket, Squeak/Pharo, and Apple’s work in the 1990s on Dylan and SK8 (this would’ve been particularly revolutionary if it weren’t for Apple’s precarious state in the mid-1990s).

But, alas, the industry took a different direction…but at least Interlisp-D is finally open source, and thanks to Hacker News and other sites more people like me who never used a Lisp machine (I was born in 1989) get to learn about them.

[pjmlp]

Which is why I love systems programming in automatic resource management languages so much, it is something one needs to actually live through, like those systems.

Most of these systems have failed for monetary and bad management reasons, not technical ones.

Unfortunately in technology it seems ideas have to be recycled multiple times until they finally catch on, the hard part is if one is still around when they do catch on.

[kazinator]

> Lisp machines were facing performance and cost challenges from RISC workstations

Which were themselves hideously expensive and out of reach of the consumer, facing cost challenges from personal computers. Initially not performance challenges, but that came around in the early 90s.

[lispm]

> supports types for better speed

AFAIK, Symbolics Genera mostly ignored all static type declarations at compile-time. Thus there was no speed effect from static type declarations.