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

The lost cause of the Lisp machines

tfeb.org

Post reply on HN
Print view View original

141–150 of 176 posts

Re: The lost cause of the Lisp machines

#141

Post by iLemming »

ErroneousBosh wrote: post #140
iLemming wrote: post #118

Earlier quoted context omitted.

> you're not very good at computers. Yup, I guess I am not. Been coding for over 20 years, went through over a dozen different PLs and only Python - the best fucking friend who doesn't sugar coat it, tells you without stuttering - "you suck at this, buddy" # PEP 9001: Constructive Computing Feedback ## Abstract This PEP proposes a standardized error message for situations where Python interpreters shall inform the us…

[flagged]

It's not hard. It's just annoying to deal with this shit on constant basis. Like just the other day, the tests wouldn't pass locally, while they're passing on CI. I was scratching my head for sometime, turns out there was breaking change in csv.QUOTE_STRINGS or something, between 3.12 and 3.13 of Python. How the fuck did they manage to fix/improve fucking csv logic introducing a breaking change?

Re: The lost cause of the Lisp machines

#142

Post by bigfishrunning »

ndiddy wrote: post #126
eschaton wrote: post #3

Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…

Xerox/Venue tried porting Interlisp (the Lisp machine environment developed at Xerox PARC) to both Unix workstations and commodity PC hardware, but it doesn't seem like that was a commercial success. Venue remained a tiny company providing support to existing Interlisp customers until its head developer died in the late 2000s and they wrapped up operations. The Unix/PC ports seem to have mostly been used as a way to…

I don't really understand why lisp was so intrinsically tied to expert systems and AI. It seems to me that Scheme (and, to an extent, common lisp or other lisps) are pretty good platforms for experimenting with software ideas; long before Jupiter notebooks existed.

Re: The lost cause of the Lisp machines

#143

Post by ted_dunning »

dist-epoch wrote: post #31

> I’d be saying that in a few years there are going to be a lot of huge farms of GPUs going very cheap if you can afford the power. People could be looking at whether those can be used for anything more interesting than the huge neural networks they were designed for. Author falls into the same trap he talks about in the article. AI is not going away, we are not going back to the pre-AI world.

I don't read it that way.

The author is saying that those special purpose machines will age out quickly when the task of advanced computing shifts (again).

You seem to be making the assumption that "the huge neural networks they were designed for" are the only way to build AI. Things could shift under our feet again.

The author (and I) have seen too many people say that only to be proved very wrong shortly thereafter. This means that it doesn't quite have the logical force that one might think to assert that this time we have the approach right (ignore the previous 7 times somebody else said just the same thing).

Re: The lost cause of the Lisp machines

#144

Post by bigfishrunning »

mghackerlady wrote: post #6
karlgkk wrote: post #4

“ I am just really bored by Lisp Machine romantics at this point: they should go away. I expect they never will.” What? They’re awesome. They present a vision of the future that never happened. And I don’t think anyone serious expects lisp machines to come back btw.

I'm honestly surprised nobody tried to capitalize on the early 2000s Java hype by making some kind of Java box (there were a few things labeled as a Java OS or a Java workstation but none of these were really a "Java Machine")

There were a lot of efforts to accelerate the JVM in hardware, the one i remember is the ARM "Jazelle" extension https://en.wikipedia.org/wiki/Jazelle

Re: The lost cause of the Lisp machines

#145

Post by lucas_membrane »

dreamcompiler wrote: post #97
raverbashing wrote: post #74

Earlier quoted context omitted.

Yes I agree, pure functions are good building blocks (for the most part), but I don't think the current abstractions and ways of bridging the FP and Procedural world are good enough Also have you managed to eliminate the side effect of your IP register changing when your program is running? ;)

I love FP but at the end of the day registers are global variables. Half of modern compiler theory consists of workarounds for this sad truth.

A functional program is an a self-contained expression -- an isolated system following its own rules. The foremost example we have of such a thing is the universe itself, but the universe is not a good example in this discussion, because we have plenty of reasons to think that the universe contains pure (not pseudo-) randomness. Beyond that, isolation , when it matters, is not an easily proven proposition, and is a deplorable fantasy when assumed in many of the other science and engineering disciplines.

Re: The lost cause of the Lisp machines

#146

Post by seanhunter »

A few years ago I was learning lisp and I mentioned it to my uncle who had been an inspiration to me getting into programming. It turns out he wrote a tcp/ip stack for the symbolics lisp machine when he worked at Xerox. They had some sort of government contract that had to be done in lisp on the symbolics and deep in a very long contract it said that the interface had to be tcp/ip which the symbolics didn’t support out of the box. He said to me his boss came to him one day and the conversation went something like this:

Boss: Hey there, you like learning new things right?

Him (sensing a trap): Errr, yes.

Boss: But you don’t program in lisp do you?

Him (relieved, thinking he’s getting out of something): No.

Boss: Good thing they sent these (gesturing at a literal bookshelf full of manuals that came with the symbolics).

So he had to write a tcp stack. He said it was really cool because it had time travel debugging, the ability hit a breakpoint, walk the execution backwards, change variables and resume etc. This is in the 1980s. Way ahead of its time.

Re: The lost cause of the Lisp machines

#147

Post by matheusmoreira »

logicprog wrote: post #77
matheusmoreira wrote: post #64

Earlier quoted context omitted.

> emacs that extends down through and out across more of userspace Making something like that has turned into a lifetime project for me. Implemented a freestanding lisp on top of Linux's stable system call interface. It's gotten to the point it has delimited continuations.

Oh my god, that's so cool? Could I see by any chance? (Edit: found links on your profile, will read more)

I call it the lone programming language.

https://github.com/lone-lang/lone/

It's a lisp interpreter with zero dependencies targeting Linux exclusively.

I've written about a few of its development milestones:

https://www.matheusmoreira.com/articles/self-contained-lone-...

https://www.matheusmoreira.com/articles/delimited-continuati...

I'm particularly proud of my ELF hack to allow the interpreter to introspect into a lisp code section at runtime without any /proc/self/exe shenanigans. Wish other languages would adopt it.

Top comment and its replies talk about linking the lisp code into a self-contained, easily distributable application:

https://news.ycombinator.com/item?id=45989721

I think I addressed that problem adequately. I can create applications by copying the interpreter and patching in some special ELF segments containing lisp modules. The mold linker even added features to make it easy and optimal.

Since there is no libc nonsense, Linux compatibility depends only on the system calls used. Theoretically, applications could target kernels from the 90s.

My Linux system call philosophy:

https://www.matheusmoreira.com/articles/linux-system-calls

At some point I even tried adding a linux_system_call builtin to GCC itself but unfortunately that effort didn't pan out.

Re: The lost cause of the Lisp machines

#148

Post by e40 »

Animats wrote: post #139
e40 wrote: post #115

Earlier quoted context omitted.

I worked on Franz Lisp at UCB. A couple of points: The ".obj" file was a binary file that contain machine instructions and data. It was "fast loaded" and the file format was called "fasl" and it worked well. The issue of building an application wasn't an issue because we had "dumplisp" which took the image in memory and wrote it to disk. The resulting image could be executed to create a new instance of the program, a…

I was doing this in 1980-1983. Here's some code.[1] It's been partly converted to Common LISP, but I was unable to get some of the macros to work. This is the original Oppen-Nelson simplifier, the first SAT solver. It was modified by them under contract for the Pascal-F Verifier, a very early program verifier. We kept all the code under SCCS and built with make, because the LISP part was only part of the whole system…

Do you remember who you discussed it with? It had to be either Sklower or Foderaro, unless you talked with Fateman.

Were the macros originally from another dialect of Lisp?

Re: The lost cause of the Lisp machines

#149

Post by Animats »

e40 wrote: post #148
Animats wrote: post #139

Earlier quoted context omitted.

I was doing this in 1980-1983. Here's some code.[1] It's been partly converted to Common LISP, but I was unable to get some of the macros to work. This is the original Oppen-Nelson simplifier, the first SAT solver. It was modified by them under contract for the Pascal-F Verifier, a very early program verifier. We kept all the code under SCCS and built with make, because the LISP part was only part of the whole system…

Do you remember who you discussed it with? It had to be either Sklower or Foderaro, unless you talked with Fateman. Were the macros originally from another dialect of Lisp?

Franz LISP had, I think, MacLISP macros, while Common LISP has a different system.

I talked to Fateman at some point. Too long ago to remember about what.

Re: The lost cause of the Lisp machines

#150

Post by bitwize »

dreamcompiler wrote: post #99
teunispeters wrote: post #94

Lisp - historically - did not work well with others. Did not share spaces, did not coexist with other systems particularly well. Or if it did, it would wrap them very carefully in "unsafe" and keep as much to the boundaries as possible. It's not like it's the only system that suffers this, but "working well with others" is a big key to success in almost every field. I'm absolutely fascinated by what worked and was po…

These days Lisp works pretty well with C because C has a defined ABI. That was historically not the case for C++, so to call C++ functions you needed to first wrap them in C. C++ might be easier now; I don't know.

I do a lot of work in Gambit, which integrates very well with C, C++, and Objective-C. But that's because it transpiles to C source. Gambit does a lot of other stuff these days, including x86 and even JavaScript compilation, but its roots as a scheme-to-C compiler are still in evidence.
Post reply on HN