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…
The lost cause of the Lisp machines
51–60 of 176 posts
Re: The lost cause of the Lisp machines
#52As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed with the LISP machine. The performance wasn't all that great. Initially garbage collection took 45 minutes, as it tried to garbage-collect paged-out code. Eventually that was fixed. The hardware was not very good. Too much wire wrap and slow, arrogant maintenanc…
> "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
Re: The lost cause of the Lisp machines
#53Earlier 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 often exist in practice and are useful for preventing many bugs. Sure, they may not be suitable for some situations but they can prevent a lot of foot guns.
Here's a Haskell example with all of the above:
import System.Random (randomRIO)
main :: IO ()
main = do
num Int
pureFunction x = x * x + 2 * x + 1Re: The lost cause of the Lisp machines
#54Earlier quoted context omitted.
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 infan…
Re: The lost cause of the Lisp machines
#55Earlier quoted context omitted.
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 infan…
[flagged]
Thank you for making my day.
Re: The lost cause of the Lisp machines
#56“ 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.
See also: Amiga romantics. 8-bit romantics. PDP-10 romantics. Let them stay. Let them romantizice.
Re: The lost cause of the Lisp machines
#57Re: The lost cause of the Lisp machines
#58Earlier quoted context omitted.
This is such a hilarious comment. Thank you for making my day.
Hey Gen Z, as long as I have you on the line, could you please explain 67 to me? I've heard of "68 and I'll owe you one", so is 67 about owing you two?
Incidentally, when will you (multiple) come and visit?
It's been too long.
Re: The lost cause of the Lisp machines
#59You can go read about the real differences on sites like Chips and Cheese, but those aren't pop-sciencey and fun! It's mostly boring engineering details like the size of reorder buffers and the TSMC process node and it takes more than 5 minutes to learn. You can't just pick it up one day like a children's story with a clear conclusion and moral of the story. Just stop. If I can acquire all of your CPU microarchitecture knowledge from a Linus Tech tips video, you shouldn't have an opinion on it.
If you look at the finished product and you prefer the M series, that's great. But that doesn't mean you understand why it's different from the Zen series.
Re: The lost cause of the Lisp machines
#60“ 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")