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

41–50 of 176 posts

Re: The lost cause of the Lisp machines

#41

Post by whstl »

rmunn wrote: post #39
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.

AI will not go away, I agree. But many of the companies now betting the farm on AI are going to lose, and there will be server farms going for sale cheap. I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop. When that happens and investors lose confidence, suddenly companies who need the next round of financing to pay off their current debts won't get it,…

Most will fail, but I don't say this because I'm a pessimist: it's just that for every AI business idea, there's always at least 10 different competitors.

Re: The lost cause of the Lisp machines

#42

Post by cess11 »

I'm sure the Lisp machines were very impressive compared to a DOS or Unix prompt, but today I can run like ten Amber or Newspeak environments on a constantly networked many-core system I carry around in my pocket. I'm not sure whether the CL folks have created similar web interfaces to the running image but I wouldn't be surprised if they have.

I feel it would be cool to sometime run code on a radiation hardened Forth chip, or some obscure Lisp hardware, but would it be life changing? I doubt it.

Re: The lost cause of the Lisp machines

#43

Post by raverbashing »

whstl wrote: post #38
raverbashing wrote: post #32

Earlier quoted context omitted.

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…

You are correct unfortunately

Re: The lost cause of the Lisp machines

#44

Post by pjmlp »

f1shy wrote: post #13
_zagj wrote: post #8

Earlier quoted context omitted.

For those unaware, Symbolics eventually "pivoted" to DEC Alpha, a supposedly "open" architecture, which is how Genera became Open Genera, like OpenVMS. (And still, like OpenVMS, heavily proprietary.)

Wasn’t the “open” at the time meaning “open system” as a system that is open for external connections (aka networking) and not so much open as in “open source”?

No, it meant industry standards, instead of proprietary ones, that is why POSIX, Motif, and others are under The Open Group.

Re: The lost cause of the Lisp machines

#45

Post by raverbashing »

rmunn wrote: post #40
raverbashing wrote: post #32

Earlier quoted context omitted.

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

Not the ones I've used. Haskell compiles to executables, F# compiles to the same bytecode that C# does and can be shipped the same way (including compiling to executables if you need to deploy to environments where you don't expect the .NET runtime to be already set up), Clojure compiles to .jar files and deploys just like other Java code, and so on. I'll grant that there are plenty of languages that seemed designed…

True but some still wants me to understand what a monofunctor is or something that sounds like a disease to do things like print to screen or get a random number

I feel that is the biggest barrier to their adoption nowadays (and also silly things like requiring ;; at the end of the line)

Pure functions are a good theoretical exercise but they can't exist in practice.

Re: The lost cause of the Lisp machines

#47

Post by jacquesm »

whstl wrote: post #38
raverbashing wrote: post #32

Earlier quoted context omitted.

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…

Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infantilized programming but then required you to become an expert at resolving package manager conflicts.

For a while Conda seemed to have cracked this, but there too I now get unresolvable conflicts. It is really boggling the mind how you could get this so incredibly wrong and still have the kind of adoption that python has.

Re: The lost cause of the Lisp machines

#49

Post by jacquesm »

raverbashing wrote: post #45
rmunn wrote: post #40

Earlier quoted context omitted.

Not the ones I've used. Haskell compiles to executables, F# compiles to the same bytecode that C# does and can be shipped the same way (including compiling to executables if you need to deploy to environments where you don't expect the .NET runtime to be already set up), Clojure compiles to .jar files and deploys just like other Java code, and so on. I'll grant that there are plenty of languages that seemed designed…

True but some still wants me to understand what a monofunctor is or something that sounds like a disease to do things like print to screen or get a random number I feel that is the biggest barrier to their adoption nowadays (and also silly things like requiring ;; at the end of the line) Pure functions are a good theoretical exercise but they can't exist in practice.

> Pure functions are a good theoretical exercise but they can't exist in practice.

Well, they can. But not all the way up to the top level of your program. But the longer you can hold off from your functions having side effects the more predictable and stable your codebase will be, with as an added benefit fewer bugs and less chance of runtime issues.

Re: The lost cause of the Lisp machines

#50

Post by logicprog »

whstl wrote: post #38
raverbashing wrote: post #32

Earlier quoted context omitted.

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…

Yeah, anytime I see a useful tool, and then find out it's written in Python, I want to kms — ofc, unless it happens to work with UV, but they don't always
Post reply on HN