Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

51–60 of 220 posts

Re: Why we need Lisp machines

#51
post #18

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 "stuck" in so…

One can implement these standards. Problem: it's work.

They supported things like TCP/IP, UDP, SMTP, X11, RPC, NFS, DNS, HTTP, ... The machines had C compilers, too.

Re: Why we need Lisp machines

#52
post #48

Meh the problem is "Which Lisp?" There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc). In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-sty…

The canonical Lisps still widely used today are Common Lisp, Scheme and Emacs Lisp. They all belong in the same family, and syntax / semantics are close. Porting code from Scheme to Common Lisp can be a lot easier than going from Python 2 to Python 3.

Clojure is something else entirely which is why a lot of people don't consider it a Lisp.

> Honest question: how do you communicate between two Lisp processes on two different machines?

If you want to use built-in object serialization, there is print and read.

Re: Why we need Lisp machines

#53

Earlier quoted context omitted.

>> UNIX isn’t good enough anymore and it’s getting worse >Why exactly? Personally? We're in a bit of a transition point, and a lot of the technologies aren't working together like they used to. An example, on my laptop I want to run android apps. The way to do this that actually works well (waydroid) only supports wayland. Unfortunately I use x2x to control another display remotely, and x2x doesn't work properly unde…

I am finding that everything is just becoming more and more fragmented. Programming languages, ecosystems, frameworks, blah. I have had ideas for some applications, but can’t do them because the libraries I need are written in different languages, which don’t interoperate well (and one I am not familiar in). Every post here looking for recommendations has many responses with different packages/ecosystems doing the sa…

I’m curious what you would classify as a hard problem. Personally, I think writing a good, easy to use Python package manager that both gains adoption and addresses the myriad of corner cases is a hard problem.

Re: Why we need Lisp machines

#54

Earlier quoted context omitted.

I am finding that everything is just becoming more and more fragmented. Programming languages, ecosystems, frameworks, blah. I have had ideas for some applications, but can’t do them because the libraries I need are written in different languages, which don’t interoperate well (and one I am not familiar in). Every post here looking for recommendations has many responses with different packages/ecosystems doing the sa…

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…

This is why I like Golang. I think it’s the first time in my professional experience where if I see a package that hasn’t been updated in 3 years, that doesn’t mean it’s abandoned, it means it’s stable.

Re: Why we need Lisp machines

#55
post #8

What ramblings. 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. 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. architectur…

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.

Re: Why we need Lisp machines

#56
post #23

If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp. 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.

Executable-images-and-bytestreams (Research Unix, Plan 9) and everything-is-in-$LANGUAGE (Lisp machines, Emacs, Smalltalk, Oberon, Forth) environments seem largely contradictory to me, because much of the flexibility in Unix seems to come from the freedom to ignore as much structure in the data as you want to, while programming-language environments seem to derive their advantages from expressing the structure in as…

"Expressing structure" is just a higher layer on simple bytestreams. Some historical operating systems only supported special-cased "file types" with hard-coded structure, but the *IX folks found out that the simple bytestream is enough.

Re: Why we need Lisp machines

#57

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

I have had this thought. Jokes about needing a good editor aside, I wondered about making a unikernal that bootstraps enough to start emacs.

The issue I see with the idea of lisp-all-the-way-down is that most people don’t want to write filesystems and device drivers. I know I don’t. I mean I find them fascinating, but I usually have a specific app I want to write. I don’t want to write device drivers on my way there.

Re: Why we need Lisp machines

#58
post #48

Meh the problem is "Which Lisp?" There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc). In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-sty…

> 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't heard of the solutions for other Lisps.

Probably TCP or UDP based protocols like essentially every cross-network communication in every language today.

EDIT: Also, it should be noted that JSON does not, itself, allow you to communicate across a network. It's just a serialization format. You still have to select some protocol for actually doing the communication. If your answer to the question "How do you communicate between two JavaScript processes on two different machines?" is "JSON", you've failed at actually answering the question.

Re: Why we need Lisp machines

#59
post #33

Earlier quoted context omitted.

Not saying you're wrong, but do you have a source for the 60/1000x number? Curious to read more.

Yeah, where did I read it, I think John McCarthy checked it out along with...who could it have been...definitely him.

Today one Lisp Machine CPU emulator written in assembler is 80 times faster than the original Lisp hardware. This could be made faster by a JIT compiler. Native code Lisp compilers for x86-64 or Apple's M1 are roughly 800 times faster than the original Lisp hardware (the third generation Ivory processor).

Re: Why we need Lisp machines

#60

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…

> 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 boundaries in code and "programming in the large". So everything ends up being a bespoke solo-programmer project, there is no real shared development. You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall. This might explain much of their ongoing success.

Post reply on HN