Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

Post reply on HN
Print view View original

71–80 of 220 posts

Re: Why we need Lisp machines

#71

Post by 20after4 »

traverseda wrote: post #16
zozbot234 wrote: post #15

Earlier quoted context omitted.

You can actually start a Wayland compositor/session in a X window. That plus existing solutions for Wayland network transparency should be enough.

That's what I'm doing now, but it's a pretty bad user experience and definitely isn't seamless. Also completely breaks any integration with my app menu meaning I have to rewrite all the desktop files to launch the app in cage. I imagine someone will eventually make a seamless wayland compositor for x though. >That plus existing solutions for Wayland network transparency should be enough. If you're saying it will fix…

Wow and here I was hopeful that Wayland would actually make this kind of thing easier. I'm a big fan of synergy and all it's descendant. Apple just released a similar feature for iOS and OSX. Really surprised this is getting more difficult on Linux instead of easier.

Re: Why we need Lisp machines

#72

Post by bitwize »

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

You are aware that Lisp machines understood several different flavors of Lisp? The Symbolics ones understood Zetalisp and Common Lisp at least. Were they on the market today they could be convinced to run Clojure and Scheme as well. There are a few old-timers developing Common Lisp applications to run on modern hardware, using Symbolics hardware.

In fact, Symbolics shipped compilers for other non-Lisp programming languages, including C and Ada. These interoperated smoothly with Lisp code, much more so than they do under Unix. In this demo, Kalman Reti compiles a JPEG decoder written in C, and replaces the Lisp JPEG decoder that came with the system with it, yielding a performance boost:

https://www.youtube.com/watch?v=o4-YnLpLgtk

Re: Why we need Lisp machines

#73

Post by taeric »

agumonkey wrote: post #61
taeric wrote: post #43

Earlier quoted context omitted.

This feels like an odd critique. I would expect that more programs should devote more code to the parts that interact with a user. That is, the size alone isn't much of a signal. Is it?

The formatting is redundant and should be able externalized. The argparse also deals with the output formatting, hence redundant. Only file spec selection is core to LS.

Redundancy isn't, by itself, a problem. In the case of core utilities, it affords them a level of stability that is just not even attempted in many areas.

Re: Why we need Lisp machines

#74

Post by zozbot234 »

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

Already in the 80s the Lisp Machine OS had > 1 MLOC code lines with support for programming in the large. The development environment was networked from the start. A server keeps the definition of things on the network: machines, users, file systems, networks, gateways, printers, databases, mailers, ... The source code and documentation is usually shared in the team and versioned via a common file server. Nowadays, t…

"Designed for complex programs in the 1980s" is not really up to current standards. Moore's law means that complexity of overall systems can grow by multiple orders of magnitude in the 01980 -to- 02022 timeframe.

Re: Why we need Lisp machines

#75

Post by fferen »

I have had the same thoughts before and come to a similar conclusion. I believe it's not about the language. It'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.

Re: Why we need Lisp machines

#76

Post by lispm »

zozbot234 wrote: post #74
lispm wrote: post #65

Earlier quoted context omitted.

Already in the 80s the Lisp Machine OS had > 1 MLOC code lines with support for programming in the large. The development environment was networked from the start. A server keeps the definition of things on the network: machines, users, file systems, networks, gateways, printers, databases, mailers, ... The source code and documentation is usually shared in the team and versioned via a common file server. Nowadays, t…

"Designed for complex programs in the 1980s" is not really up to current standards. Moore's law means that complexity of overall systems can grow by multiple orders of magnitude in the 01980 -to- 02022 timeframe.

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.

Re: Why we need Lisp machines

#77

Post by sseagull »

tacitusarc wrote: post #53
sseagull wrote: post #19

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

I work in scientific software. I tend to view really hard problems as problems where you don't know the solution, and don't even have a blueprint for how could be solved.

Writing a package manager is hard in some sense, but you have an idea of what it needs to do, what features it should have, and what success ultimately looks like.

But there are problems, large and small, which require new thinking and leaps of faith. There are people working on these, of course, but sometimes I feel they are being neglected.

(and people working on those problems probably make 10-25% of what many FANG developers make...)

Re: Why we need Lisp machines

#78

Post by nanochad »

> 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 of today couldn’t dream of.

And with a single address space you have win9x security.

> 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

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's ability to edit code on the live system.

> 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

The same thing will happen with any OS given enough time. Lisp is also not secure. It's prone to side channel and eval bugs.

> eliminate memory leaks and questions of type safety,

Lisp is not type safe.

Re: Why we need Lisp machines

#79

Post by zozbot234 »

lispm wrote: post #76
zozbot234 wrote: post #74

Earlier quoted context omitted.

"Designed for complex programs in the 1980s" is not really up to current standards. Moore's law means that complexity of overall systems can grow by multiple orders of magnitude in the 01980 -to- 02022 timeframe.

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 the way of this, and that's essentially what Lisp is too.

Re: Why we need Lisp machines

#80

Post by reikonomusha »

nanochad wrote: post #78

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

Post reply on HN