Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

61–70 of 220 posts

Re: Why we need Lisp machines

#61
post #43

Earlier quoted context omitted.

From a semi shallow position, what annoys me with linux is the lack of genericity above the "file" abstraction (which is not even real enough). I remember seeing GNU ls code, 30% argparse, 30% formatting.., all of this seems brittle and redundant. Bazaar is fine to allow freeform innovative evolution but it's also too messy.

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.

Re: Why we need Lisp machines

#62

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…

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.

Clojure is like that. I love it.

Re: Why we need Lisp machines

#63

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…

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 sky development equivalent to the original Internet, the Mother of All Demos, and the desktop computing model - and associated projects - created at PARC in the 70s and early 80s.

It's all very "mature", incremental, slow, and me-too.

And so expensive, both financially and in terms of developer time.

I'd love to see a renewed interest in attacking this from both ends - a movement to really push the imaginative limits of what's possible, while also being implacably humane and user-oriented and indifferent to ad tech, tinker tech, and pre-commercialised cloud tech.

Re: Why we need Lisp machines

#64

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…

The greatness of Lisp -at least when it comes to end-user empowerment- and (I think) the only differentiating factor that most other languages have still not caught up to, is the cybernetic philosophy with its roots in Licklider (man-computer symbiosis) and Engelbart.

Building an environment that strongly and uncompromisingly expresses this philosophy at its core is a serious undertaking in terms of time investment. Emacs has been in continuous development for 37 years and while it is still not as good as Genera, it's certainly "good enough" for lots of people and definitely captures the spark of this philosophy.

In the Common Lisp world, we've had plenty of tries (MCL, Hemlock, McCLIM) but they've all failed to get people to coalesce and generate progresss.

Maybe the fact that Emacs exists is a curse in that people realize the barrier they'll have to clear to make something substantially better and decide to devote their energies into more easily realizable efforts.

Re: Why we need Lisp machines

#65

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 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, there are large applications written by groups/teams, which are worked on for three or more decades. For example the ACL2 theorem prover has its roots in the 70s and is used/maintained until today for users in the chip industry.

Common Lisp was especially designed for the development and production use of complex programs. The military at that time wanted to have a single Lisp dialect for those - often applications came with their own Lisp, which made deployment difficult. A standard language for projects was then required.

These were usually developed by teams in the range of 5 - 100 people. Larger teams are rare.

Re: Why we need Lisp machines

#66
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…

An unappreciated means of code reuse under *nix is the static and dynamic library. This seems to be the go-to whenever you need something more involved than simply reusing a full binary via pipes.

Re: Why we need Lisp machines

#67

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 boundari…

I think many people have conjectures, such as this one, but I don't think it's a tech problem, or a "Lisp is too powerful for its own good" problem. It's a "people aren't writing software" problem. History has demonstrated umpteen times that developing large, sophisticated, maintained, and maintainable projects in Lisp is entirely and demonstrably possible. Modern Common Lisp coding practices gravitate toward modular, reusable libraries through proper modules via ASDF packages ("systems") and Common Lisp namespaces ("packages").

Re: Why we need Lisp machines

#68

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 boundari…

[deleted]

Re: Why we need Lisp machines

#69
post #59

Earlier quoted context omitted.

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

Wow! Really?! So the M1 really is faster in a non-gimmicky way? I could cut out this X86-64 assembly bullshit, at 800x I could be happy just with Lisp. Assembly all based on C by this point anyway...

Re: Why we need Lisp machines

#70

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…

"New business ideas" are really easy. VC-style hypergrowth towards unicorn status is what's hard, but make no mistake it's always been very hard. Unicorns are rare, by definition.
Post reply on HN