Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

81–90 of 220 posts

Re: Why we need Lisp machines

#81
> With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack

This seems like the kind of goal that's only palatable to a very few people nowadays. Specifically, the people who want to use that language, toolchain, and libraries, and nothing else.

These days, I don't think that that's ever going to allow for enough of a community to support more than a relatively self-contained hobbyist scene. Which there's absolutely nothing wrong with that; personally I wish there were more compelling tinkering-oriented platforms; I'm a little meh on Unix too. But the article seems to be advocating rather loftier ambitions.

Re: Why we need Lisp machines

#82

> You could open up system functions in the editor, modify and compile them while the machine was running. Why would you want to do that other than hot patching a system that can't go down? Testing new changes requires more time than rebooting. If you just want to test simple changes, most debuggers can do that. > Everything worked in a single address space, programs could talk to each other in ways operating systems…

> And with a single address space you have win9x security.

Address space != protection boundaries. These are nearly orthogonal concerns. Where single address spaces might become less useful today is in dealing with Spectre vulnerabilities, though formalizing more explicit requirements about information domains (as in multilevel security, which is a well-established field of OS research) might help address those.

Re: Why we need Lisp machines

#83

I'm as big of a Lisp fan as can be. I'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. 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…

Personally, I think the problem is that CommonLisp is just another programming language, whereas Lisp really shines when it provides a full-fledged programming environment. Nowadays, it would seem best to create such an environment on top of commodity hardware as a "virtual machine" that abstracts away from the hardware in a general, portable way. However, a good environment (1) needs a purpose, and (2) somebody needs to write it. Lisp currently fails on both points. The purpose used to be symbolic AI and NLP among other things. Nowadays it could be the same, or a web framework with integrated distributed computing and database, or scientific computing, or a server for certain business services, etc. There are many application domains for which a virtual "Lisp machine" would be beneficial but it needs to be developed for one of those real world applications, not just as a toy like existing attempts of building Lisp machines. And in my opinion the problem really is (2), developer power / size of the community. If you exclude super-expensive legacy Lisps, the current Lisp community doesn't even have a fully supported Lisp-native editor (portable Hemlock is not good enough) and also doesn't have good enough object persistence / native Lisp-based databases. Both are the foundations of any integrated Lisp machine.

People sometimes claim CL+Emacs+Slime provides the full interactive experience. I just can't agree with that at all. I have tried, and the experience was not substantially different from Go development and development in any other fast-compiling language with Emacs. In some respects, it's even worse than with various modern languages, even though most of those languages are strictly inferior to CL from a pure language perspective. If editing files in Emacs is all there is to the allegedly great Lisp experience, and developers at the same time have to deal with all those idiosyncrasies of CL such as CL's filesystem path handling, ASDF, and tons of poorly documented libraries, then I can't really see the advantages of CL. The language is powerful, don't get me wrong, but a truly interactive experience is totally different. Smalltalk managed to keep this experience but for some reason the Lisp community seems too have lost this vision. I guess the developer community is just not large enough.

Anyway, before someone tries to build another "close to metal" Lisp machine or tries to revive any old Lisp machine, I'd rather wish the community would focus on creating truly integrated development environments that abstract away from the host system and are fully hackable and editable from the ground up while maintaining security and multi-user access. A "virtual Lisp" machine with virtual OS, so to say. If that's developed for a certain purpose like building and deploying extremely portable web applications, I believe it can have a great future.

Sorry for the long rant. This is just my impression after having programmed in various Lisp dialects for the past three decades.

Re: Why we need Lisp machines

#84
post #76

Earlier quoted context omitted.

That was not the point. Lisp applications were already a team sport back then. That all or even most Lisp software is written by single person teams is just wrong.

Modern agile development is far more complex than even that: you need entire loosely-coupled teams of developers to be able to seamlessly cooperate with one another, so there are multiple scales of cooperation. Tightening the semantics of interface boundaries is a necessary support for that kind of development and is what's largely meant today by programming "in the large". Highly dynamic "scripting" languages get in…

Lisp isn't essentially a scripting language. Common Lisp was designed as an application language, in rare case it's also a systems language. On a Lisp Machine, for example the whole networking stack was written in it.

Re: Why we need Lisp machines

#85

> You could open up system functions in the editor, modify and compile them while the machine was running. Why would you want to do that other than hot patching a system that can't go down? Testing new changes requires more time than rebooting. If you just want to test simple changes, most debuggers can do that. > Everything worked in a single address space, programs could talk to each other in ways operating systems…

> Lisp is not type safe. It is type safe. While Lisp is not statically typed, its typing discipline is strong: operations performed on incompatible types signal recoverable errors.

[deleted]

Re: Why we need Lisp machines

#86
post #7

This post would benefit from further expanding some of these statements. > UNIX isn’t good enough anymore and it’s getting worse Why exactly? > A new operating system means we can explore new ideas in new ways. 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/AMD/M1 CPUs? > With lisp machines, we can cut out the complicat…

>> UNIX isn’t good enough anymore and it’s getting worse

> Why exactly?

Beside the defects well stated in the Unix Hater's Handbook, unix violate it's own principles since many years. Original unix idea was: desktops like Xerox SmallTalk workstations are too expensive and complex for most needs, so instead of a real revolution of an extraordinary outcome we decide to limit ourselves to most common needs in exchange of far less costs. No GUIs, no touchscreen, no videoconferencing and screen sharing [1] just a good enough CLI with a "user language" (shell scripts) for small potatoes automation and a bit of IPCs for more... Well... For more there is a "system language" (C) that's easy enough for most really complex task.

That was a success because no one really like revolutions and long terms goals especially if they demand big money while many like quick & done improvements at little price.

However in few years unix start to feel the need of something more than a CLI and some GUIs start to appear, unfortunately differently than original Xerox&co desktops those UIs were not "part of the system, fully integrated in it" but just hackish additions with so interoperability, just single apps who have at maximum cut&paste ability.

> Sure, but it also requires rewriting a lot of these things, introducing and fixing new bugs... It feels like the good ol' "let's rewrite this program" that quite frequently doesn't live up to the expectations

We need desktops again, witch means not just "endpoints" or "modern dumb terminals of modern mainframes named cloud", but desktop computing, since desktop development is essentially abandoned since many years and even back then was in a bad shape we need to restart from the classic desktops. LispM was ancient, hackish, but are still the best desktop we have had in human history so a good starting point. We have some kind of LispM OS/OE here: Emacs, still alive and kicking so there is something to work with, that's is. Emacs is already a WM (EXWM) have countless features and it's already "plugged" in modern bootloader OSes to have hw, driver and services. It just need to evolve.

[1] yes, you are reading correctly and no, I'm not wrong, I'm talking about the famous NLS "Mother of all the Demos" from 1968 https://youtu.be/yJDv-zdhzMY

Re: Why we need Lisp machines

#87
post #83

I'm as big of a Lisp fan as can be. I'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. 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…

Personally, I think the problem is that CommonLisp is just another programming language, whereas Lisp really shines when it provides a full-fledged programming environment. Nowadays, it would seem best to create such an environment on top of commodity hardware as a "virtual machine" that abstracts away from the hardware in a general, portable way. However, a good environment (1) needs a purpose, and (2) somebody need…

Common Lisp on Emacs via SLIME is not competitive with Smalltalk, re: "interactive experience" since Emacs is not the native substrate of CL, but essentially an out-of-process experience. If you want to experience CL at its best, you need to run Symbolics Genera.

Emacs with Emacs Lisp on the other hand offers a great interactive experience that also manages to easily surpass every modern Smalltalk incarnation in practicality and size of development community. So if running Genera isn't easily doable, this will give you a taste of what Lisp interactivity is all about.

Re: Why we need Lisp machines

#88
post #47

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. Then, I appreciated my M1 MacBook Pro running SBCL, LispWorks, Haskell, Clojure, and various Scheme languages…

The 1108 wasn't really special purpose Lisp hardware. One could run other operating systems on it. What made it special purpose was the loaded microcode for the CPU. > Life is really good on modern hardware. Agreed: On modern CPUs. More support for the additional hardware features like GPUs, media processing engines and the neural network engines (see the M1 Pro/Max/Ultra) would be welcome.

The best bet for getting GPU deep learning support, I use Anaconda/conda, using the Apple M1 channel. That said, I usually use my Linux GPU rig or Colab for deep learning.

Re: Why we need Lisp machines

#89

Earlier quoted context omitted.

I think they are too invested im hard problems, but not invested enough in tedious problems. I don't want a new language, or a new preprocesser, or a new way of thinking about programs... I just want a one click way to take a folder of HTML that looks like a static site, and package it up into cross platform apps with all the proper API access. I don't care about cryptocurrency and global decentralized databases, I j…

There's a gap between developer culture and the giant corporate bureaucracies. The former is focussed on tinkering, nostalgia, tool-building, wheel reinventions, and half-finished build-and-forget spare time projects. The latter has successfully applied high-friction chokeholds around startup culture which makes the cost of entry for new business ideas far higher than it really needs to be. There is almost no blue sk…

The giant bureaucracies are doing some pretty amazing innovation. Look at Google's web platform features, Bluetooth LE, etc.

There's just certain things they can't do because their incentive is stuff you constantly pay for all the time.

I'd love to be part of something like old 90s revolutionary software.

But I've noticed close to zero interest from the dev community in anything like that.

Everyone mostly just wants to play with sorting algorithms or write their own small language, unless they're getting paid a whole lot. It's become a sport more than an engineering discipline.

It's hard to imagine Excel or BitTorrent being written now.

Heck, it's hard to even imagine web browsers with JavaScript being written now.

What kind of projects would you like to see/work on?

Re: Why we need Lisp machines

#90
post #29

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't well suited to offline/nonSaaS stuff yet. Linux is slowly becoming a standardized, integrated platform. I don't see why it can't be evolved to have all the main advantages of a LISP machine. I also don't see how that solves dependency management. No matter what, if you build against s…

UNIX and UNIX philosophy are one and the same, there is no way around it with some kind of word games. C was created to make UNIX, originally written in straight Assembly, portable. A process finalized by UNIX V6 release. UNIX philosophy grew out of Bell Labs into all universities and business that took those source tapes, and took it from there. Hardly possible to be selective of what UNIX is all about.

Modern Linux is so far from old school UNIX though. They are even talking about using Rust!

It's evolved so much, and the remaining unixy bits get more and more supressed and hidden.

BSD still has more of it, but Linux seems to be moving on and is very far from the days of everyone piecing together software from small parts.

Post reply on HN