Why we need Lisp machines • Hacker News Board

Re: Why we need Lisp machines

#171

Post by PaulHoule » Sun, Mar 27, 2022, 2:57 AM UTC

bigbillheck wrote: post #55

imglorp wrote: post #8

Earlier quoted context omitted.

Speed is relevant for some use cases, sure, but not at all for a ton of others. Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? It's time for some different abstractions than file -> process -> file. The vast productivity gains of Smalltalk and Lisp were because they discarded those abstractions and programmers were free for others. Presumably OP posted this after…

> Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? Elsewhere on this very site you'll find no ends of complaints about, say, Electron apps.

For general purpose computing applications expand to fill the performance available (that includes real value and bloat!)

I dabble in microcontrollers for fun and there it's different. I am an AVR-8 fanatic and sometimes I think "this is so fast" and "2K of RAM is plenty" and "I can fit CRC-32 tables in 32k of flash because that's what counts as an 'operating system' for me"

Then there are the applications where it just doesn't have the power and I am so glad to have a box of RP2040's because in 2022 the most important attribute of a microcontroller is that it is available.

Re: Why we need Lisp machines

#172

Post by skissane » Sun, Mar 27, 2022, 3:12 AM UTC

jodrellblank wrote: post #117

mikewarot wrote: post #42

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. - https://www.youtube.com/watch?v=o4-YnL…

Why would you reach down into the system and edit the code of the system currently in operation? Because it doesn't already do what you want. Isn't it a bit pathalogical to start by building a system which doesn't do what you want , then building in the tools to let you fix it, so you can use those make it do what you want? Why not skip all the middlemen and make what you want in the first place? If you arrive at "we…

> Why would you reach down into the system and edit the code of the system currently in operation? Because it doesn't already do what you want. Isn't it a bit pathalogical to start by building a system which doesn't do what you want, then building in the tools to let you fix it, so you can use those make it do what you want? Why not skip all the middlemen and make what you want in the first place?

Because what you want is not set in stone for all time. Needs and desires change, and often what you think you want is different from what you actually want, but discovering that can take time.

I spend so much time trying to work out things like "when I click this button in the UI, what does that actually end up doing in the backend?" I wish I could right-click on a UI element and it would take me directly to the backend code which actually implements it. And a system like that should be much quicker to change – it should be much quicker for a new developer to get up to speed with it and start implementing things, rather than spending days (even weeks) trying to understand how it all fits together.

Re: Why we need Lisp machines

#173

Post by skissane » Sun, Mar 27, 2022, 3:38 AM UTC

lispm wrote: post #39

rst wrote: post #5

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. http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf (3600-series Symbolics machines also had a 68k "front end processor", but no Unix port was provided for it; they also ultimately had a C compiler that could generate code for t…

What one could do was running hardware Lisp Machines from Symbolics on VME boards inside a SUN: the UX400 and UX1200. Later Open Genera was sold as a Virtual Lisp Machine running on a DEC Alpha / UNIX system.

Apparently Open Genera now even runs under macOS on Apple M1s: https://twitter.com/gmpalter/status/1359360886415233029

I think the big problem with Genera is the licensing. Although it comes with source code, it is proprietary software, and buying a license is expensive. I think the owners of the Symbolics IP have prioritised squeezing the maximum revenue out of a declining user base over trying to grow that user base.

I'm surprised "Open Source LispOS" projects have largely failed to gain traction. Writing your own OS is (at least in some ways) easier than it used to be (especially if you target virtualisation rather than bare metal). There seem to be a lot more people saying "LispOS is what we need!" than actually writing one or contributing to an existing effort to write one.

Re: Why we need Lisp machines

#174

Post by mvc » Sun, Mar 27, 2022, 4:40 AM UTC

zozbot234 wrote: post #79

lispm wrote: 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…

Never heard of Javascript?

Re: Why we need Lisp machines

#175

Post by mvc » Sun, Mar 27, 2022, 4:42 AM UTC

olah_1 wrote: post #149

Gollapalli wrote: post #122

Earlier quoted context omitted.

And it's 4x more expensive than it was supposed to be to buy a planet. Ethereum was a mistake.

Since they moved to Layer 2 it has been amazing. No eth fees anymore. They should just move to their own chain entirely. Maybe this is a baby step towards that. Each Galaxy/Star is already basically a staker in a Proof of Stake network.

Always be griftin

Re: Why we need Lisp machines

#176

Post by nine_k » Sun, Mar 27, 2022, 5:06 AM UTC

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

Oh man, wat?

I love lisp as much as the next guy.

But you absolutely can have library mess, memory leaks, and millions of lines of code using a Lisp. You arguably can have a "multi-language" mess, too, because Lisp gives you wonderful tools to create DSLs; I'd say creating a language that fits your needs, and then using it, is the right way to use Lisp.

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.

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.

Re: Why we need Lisp machines

#177

Post by reikonomusha » Sun, Mar 27, 2022, 5:09 AM UTC

jodrellblank wrote: post #161

reikonomusha wrote: post #138

Earlier quoted context omitted.

I don't know how to respond to the whole "Lisp programmer identity" stuff; it doesn't seem relevant to anything I said. I also didn't suggest anybody rewrite anything in it. The success of Lisp doesn't depend on the existence of fancy machines, it depends on people choosing to write software in it. That's basically all I meant to say. As for Kandria, did you play the demo, or did you just look at screenshots and syst…

It's relevant in the sense of being a reply to "we need software written in Lisp" and how, if you substitute Java and say "we need software written in Java", people would just shrug and ask "why do we?". People are saying "we need sofware written in Rust" and other people are asking "why?" and one answer is "to avoid the memory and race condition problems we have from C and C++ code". Maybe correct or not, maybe comp…

I think we are talking past each other, and I think it's because you're fixated on and aggravated by a premise I did not stipulate, which is that Lisp is superior to other languages, and as such, you're interpreting "superlative" as "the best software ever written", instead of how you're supposed to interpret it, which is "the best software written in Lisp in the past 10 years", which is precisely what I referred to.

In isolation and without context: We do not need software written in Lisp. Nothing compels us to choose Lisp as a language to express programs that solve problems.

If we want a non-UNIX, non-C ecosystem, then what we need is software, not hardware. Lisp is one type of previously proven ecosystem that works. So it is reasonable to discuss that as a potential option, which is partly the topic of the article we both are posting comments to. I argue that if we want a Lisp ecosystem, we need better and more comprehensive software written in Lisp.

If we don't want a non-UNIX, non-C ecosystem, then we needn't discuss writing software in Lisp (or Smalltalk or ...) as a possible solution to that (non-)problem.

In any case, I simply argue that old hardware or even obsolete operating systems aren't really a productive thing to talk about in this context, except on a case-by-case basis.

Again, regarding "superlative", the word is in reference to last-decade Lisp software alone, which I contend describes Kandria. I don't even attempt to compare software written in Lisp to the entire universe and history of software, which it seems you're doing, but doesn't seem pertinent to the discussion. (Though, to be clear, even when comparing to all of that, I still think you're wrong. But we can argue to no end about our own subjective opinions.)

Re: Why we need Lisp machines

#178

Post by db48x » Sun, Mar 27, 2022, 5:10 AM UTC

johnny22 wrote: post #128

throw10920 wrote: post #105

Earlier quoted context omitted.

> The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large" I don't see any mention of "modular" or "boundaries" in the post you linked, so I'm assuming that it doesn't add extra context to your point. You say "very limited tools for enforcing modularity boundaries", which I'm going to assume means that you believe that…

What do you think it is?

Marketing. Too focused on AI, followed by more than a decade of breathless hype for C++ and Java.

Re: Why we need Lisp machines

#179

Post by yawaramin » Sun, Mar 27, 2022, 5:14 AM UTC

The Lisp machine of today is MirageOS: https://mirage.io/

A unikernel that throws out the legacy of Unix and starts fresh to build a library operating system, it's exactly what OP describes:

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

Even better, Mirage is programmed in OCaml, which is basically a statically-typed facade over Lisp (or Scheme). That's the modern Lisp machine of today. It even takes care of security nightmares like this:

> Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of.

Because in the Mirage model is program is a separate OS image and they can communicate only over defined service interfaces.

Re: Why we need Lisp machines

#180

Post by wvenable » Sun, Mar 27, 2022, 5:34 AM UTC

throw10920 wrote: post #105

zozbot234 wrote: post #60

Earlier quoted context omitted.

> We don't "need" Lisp machines. We "need" Lisp software. What made a Lisp machines extraordinary wasn't the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, willpower, and/or money. Discussed here https://news.ycombinator.com/item?id=30800520 The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundari…

> The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large" I don't see any mention of "modular" or "boundaries" in the post you linked, so I'm assuming that it doesn't add extra context to your point. You say "very limited tools for enforcing modularity boundaries", which I'm going to assume means that you believe that…

Lisp is clever and also a but inhumane. It only ever appeals to the small subset of the population that likes that. Lisp has some niceties that are fundamentally inherent to its design but it's just not enough to overcome how awful it is for people.

But this is not a technical deficiency of Lisp, it's more of a technical deficiency of humans.