16 ms·
The lost cause of the Lisp machines
- N_Lens 11mo ago"Old man yells at Lisp Machines (And their enthusiasts)"
- kazinator 11mo agoi.e., at other old men.
- pfdietz 11mo agoSome of us are older than others (I'm 66.)
- DonHopkins 11mo agoI yell at clouds professionally, as do a lot of people these days, young and old. It's called "YellOps".
- eschaton 11mo agoSymbolics’ 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 architecture.
- _zagj 11mo agoFor 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.)
- f1shy 11mo agoWasn’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”?
- _zagj 11mo agoI was both Alpha being quasi-open itself, like OpenPOWER today, and like earlier PDP minis had been, whereas VAX had been pretty locked down, and OpenVMS getting POSIX compatibility (admittedly probably more the latter than the former, but DEC was big on branding things "open" at the time, partly because they were losing ground): https://www.digiater.nl/openvms/decus/vmslt05a/vu/alpha_history.html https://www.digiater.nl/openvms/decus/vmslt05a/vu/alpha_hist... > Although Alpha was declared an "open architecture" right from the start, there was no consortium to develop it. All R&D actions were handled by DEC itself, and sometimes in cooperation with Mitsubishi. In fact, though the architecture was free de jure, most important hardware designs of it were pretty much closed de facto, and had to be paid-licensed (if possible at all). So, it wasn't that thing helping to promote the architecture. To mention, soon after introduction of EV4, DEC's high management offered to license manufacturing rights to Intel, Motorola, NEC, and Texas Instruments. But all these companies were involved in different projects and were of very little to no interest in EV4, so they refused. Perhaps, the conditions could be also unacceptable, or something else. Mistake #5.
- inejge 11mo ago> 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”? Networking was the initial impetus, but the phrase came to include programming interfaces, which is why POSIX was considered such a big deal. The idea was to promote interoperability and portability, as oposed to manufacturer-specific islands like those from IBM and DEC.
- pjmlp 11mo agoNo, it meant industry standards, instead of proprietary ones, that is why POSIX, Motif, and others are under The Open Group.
- jacquesm 11mo agoTo be fair to Symbolics: a lot of companies back then thought their CPU was the secret sauce. Some still do...
- musicale 11mo agoI think Apple knows that it's the whole widget (including software and hardware) that matters.
- ndiddy 11mo agoXerox/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 run legacy Interlisp software on newer hardware rather than attracting anyone new to the Lisp machine world. I don't see why Symbolics doing the same thing as Xerox would have produced any different results. The real problem was that investment in expert systems/Lisp dried up as a whole. I don't know whether any of the Lisp vendors could have done anything to combat those market forces.
- bigfishrunning 11mo agoI 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.
- eschaton 11mo agoThe environment lasted a long time as the basis for other Xerox products, such as their office automation system and as a front end for their printing systems. However, it wasn’t so much ported as the virtual machine was. (Just like Symbolics did with OpenGenera on Alpha.) What I’m suggesting is that they could have done a full port to the hardware; OpenGenera is still an Ivory CPU emulator. In 1986-7 you could get an AT-compatible 80386 system running at 16-25MHz that supported 8-32MB of RAM for 10-20% the price of a Symbolics workstation, and while it might not run Lisp quite as fast as a 3600 series system, it would still be fast enough for both deployment and development—and the next generation would run Lisp at comparable performance.
- rjsw 11mo agoI think it would have been easier to port the MIT/LMI/TI environment to standard hardware as it was still 32-bit.
- eschaton 10mo agoThere’s not a huge amount of _explicit_ dependency on the bit width of the system in either the 3600 or Ivory. Of course there’s still plenty of _implicit_ dependency in terms of hardware interaction, object layout in memory, collector implementation, etc. but that’s all stuff that had to be dealt with anyway to port from CADR to 3600 in the first place, and then again to port from 3600-series to Ivory.
- rjsw 10mo agoI was thinking that someone could have rewritten the CADR microcode to run on a 68020+Custom MMU system with no other OS, there isn't all that much of it. This would be tied to the bit width of the system.
- karlgkk 11mo ago“ 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.
- mghackerlady 11mo agoI'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")
- lukego 11mo agoSun JavaStation: https://en.wikipedia.org/wiki/JavaStation https://en.wikipedia.org/wiki/JavaStation
- mghackerlady 11mo agoI was aware of these, it's kinda what I meant by "None of these were really Java Machines". They were just shitty sparc machines that had Java OS in flash. It didn't have some kind of Java co-processor and still relied on a JVM. Java OS was pretty neat but I wouldn't really consider it a "Java OS" since it was basically just a microkernel that bootstrapped a JVM from what I've read. An actual Java machine IMO would have to at least have some kind of Java co-processor and not rely on a software based JVM
- colinstrickland 11mo agoSun also tried, and failed, to bring to market, a microprocessor architecture for running Java on metal - https://en.wikipedia.org/wiki/MAJC https://en.wikipedia.org/wiki/MAJC
- calgoo 11mo agoIn theory you could say that simcards were / (are?) Tiny java on a chip machines.
- rmunn 11mo agoTime to dig up a classic story about Tom Knight, who designed the first prototype of the Lisp Machine at MIT in the mid-70's. It's in the form of a classic Zen koan. This copy comes from https://jargondb.org/some_ai_koans https://jargondb.org/some_ai_koans but I've seen plenty of variations floating around. A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.” Knight turned the machine off and on. The machine worked.
- f1shy 11mo agoEverybody knows, you have to wait at least 5 tau.
- kragen 11mo agoThis puts the koan in a completely different light. Thank you.
- deleted 11mo ago[deleted]
- DonHopkins 11mo agoThat's one of the funniest and most enlightening classic AI Koans, originally from the ITS file "AI:HUMOR;AI KOANS". Here's another Moon story from the humor directory: https://github.com/PDP-10/its/blob/master/doc/humor/moon's.ghost https://github.com/PDP-10/its/blob/master/doc/humor/moon's.g... Moon's I.T.S. CRASH PROCEDURE document from his home directory, which goes into much more detail than just turning it off and on: https://github.com/PDP-10/its/blob/master/doc/moon/klproc.11 https://github.com/PDP-10/its/blob/master/doc/moon/klproc.11 And some cool Emacs lore: https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore Reposting this from the 2014 HN discussion of "Ergonomics of the Symbolics Lisp Machine": https://news.ycombinator.com/item?id=7878679 https://news.ycombinator.com/item?id=7878679 http://lispm.de/symbolics-lisp-machine-ergonomics http://lispm.de/symbolics-lisp-machine-ergonomics https://news.ycombinator.com/item?id=7879364 https://news.ycombinator.com/item?id=7879364 eudox on June 11, 2014 Related: A huge collections of images showing Symbolics UI and the software written for it: http://lispm.de/symbolics-ui-examples/symbolics-ui-examples http://lispm.de/symbolics-ui-examples/symbolics-ui-examples agumonkey on June 11, 2014 Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures. DonHopkins on June 14, 2014 Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye. I'll attempt to explain the deep implications of what the article said about "Everything on the screen is an object, mouse-sensitive and reusable": There's a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can't remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system. It dumped him into a "cold load stream" where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc). He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the "Please proceed, Governor" button, and was immediately back up and running where he left off before the crash, like nothing had ever happened! Here's another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community: ftp://ftp.ai.sri.com/pub/mailing-lists/slug/900531/msg00339.html Also eudox posted this link: Related: A huge collections of images showing Symbolics UI and the software written for it: http://lispm.de/symbolics-ui-examples/symbolics-ui-examples.html http://lispm.de/symbolics-ui-examples/symbolics-ui-examples....
- pjmlp 11mo agoThe Lisp environments are definitely around, in LispWorks and Allegro Common Lisp.
- f1shy 11mo agoAnd portacle.
- rausr 11mo agoAlthough Portacle isn't being maintained any more (at least as far as the main developer was concerned last time I looked a few months ago).
- cess11 11mo agoMore information here: https://github.com/portacle/portacle/issues/182 https://github.com/portacle/portacle/issues/182 In 2020 they went full-time on developing the game Kandria. They're still active: https://shinmera.com/projects.html https://shinmera.com/projects.html https://shinmera.com/bio.html https://shinmera.com/bio.html
- michaelanckaert 11mo agoAnd Emacs. Sure Elisp isn't the best lisp around (Personally I would give that title to Common Lisp), Emacs is a good Lisp environment.
- quotemstr 11mo agoI'd say elisp is a competitive lisp in its own right, at least at the language level. There's even a promising gradual typing system: https://github.com/emacs-elsa/Elsa https://github.com/emacs-elsa/Elsa
- _rpxpx 11mo agoAlso Maxima.
- vindarel 11mo ago
- xkriva11 11mo agoYou may try CADR (precursor to Genera) on-line: https://lispcafe.org/cadr/usim.html https://lispcafe.org/cadr/usim.html
- dharmatech 11mo agoThank you for sharing this!
- Animats 11mo agoAs 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 maintenance. I once had a discussion with the developers of Franz LISP. The way it worked was that it compiled LISP source files and produced .obj files. But instead of linking them into an executable, you had to load them into a run-time environment. So I asked, "could you put the run time environment in another .obj file, so you just link the entire program and get a standalone executable"? "Why would you want to do that?" "So we could ship a product." This was an alien concept to them. So was managing LISP files with source control, like everything else. LISP gurus were supposed to hack. And, in the end, 1980s "AI" technology didn't do enough to justify that hardware.
- varjag 11mo agoLisp Machines had versioning file systems IIRC. Kinda like on VMS. Was SCCS really that far ahead?
- johnisgood 11mo agoYou are correct, see: https://en.wikipedia.org/wiki/Versioning_file_system#LMFS https://en.wikipedia.org/wiki/Versioning_file_system#LMFS. Also: https://hanshuebner.github.io/lmman/pathnm.xml https://hanshuebner.github.io/lmman/pathnm.xml It is worth mentioning that while it is not versioning per se, APFS and ZFS support instantaneous snapshots and clones as well. Btrfs supports snapshots, too. HAMMER2 in DragonFlyBSD has the ability to store revisions in the filesystem.
- rst 11mo agoUmmmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two. (SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)
- GalaxyNova 11mo agoLisp is alive as ever in Emacs and Common Lisp, and Clojure and Racket
- Joker_vD 11mo agoAnd Tcl lives on in GDB, sure, just as M4 is forever alive with ubiquitous use of autotools.
- GalaxyNova 11mo agoNot quite the same thing. All the software I mentioned above have communities that constantly push to improve the ecosystem.
- Tor3 11mo agoA lot of this could be said about specialized machines in general. I remember visiting the local university last century where a guy was demonstrating a US-made Word Processor machine they had bought, and around the same time a local company was developing something similar. And they looked very cool indeed. But in both cases I thought.. "eh, won't that be total overkill now when we can see standard word processing software on standard computers already arriving? Even if a normal PC doesn't look that cool?" And, as predicted (and I most certainly couldn't be the only one predicting that), the US company as well as the local one folded. At least the company I worked for got to hire some good people from there when the inevitable happened. It's hard to find where to draw the line when it comes to specialized hardware, and the line moves forth and back all the time. From personal experience it went from something like "multiple input boards, but handle the real time Very Fast interrupts on the minicomputer". And spend six months shaving off half a millisecond so that it worked (we're in the eighties here). Next step - shift those boards into a dedicated box, let it handle the interrupts and DMA and all that, and just do the data demuxing on the computer. Next step (and I wasn't involved in that): Do all the demuxing in the box, let the computer sit back and just shove all of that to disk. And that's the step which went too far, the box got slow. Next step: Make the box simpler again, do all of the heavy demuxing and assembling on the computer, computers are fast after all.. And so on and so forth.
- throwaway81523 11mo agoIvan Sutherland observed the same cycle in graphics processors and called it "the great wheel of karma".
- Peteragain 11mo agoOkay they're dead, but I think the interesting thing here is the relationship between hardware and the way mathematicians (potentially) think about problem solving. The established practices massively constrain the solutions we find, but I do wonder what a Turing Machine would look like if FPGAs had been around in 1930. FPGAs keep getting used to implement processors, but using one to make a c interpreter and then using it to run a vision library is probably not the best way to use FPGAs to recognise tanks with a drone. Which is, presumably, what a Zala Lancet is doing with it's FPGA.
- mietek 11mo agoSome things have been tried; some things continue to be tried. - Naylor and Runciman (2007) ”The Reduceron: Widening the von Neumann Bottleneck for Graph Reduction using an FPGA”: https://mn416.github.io/reduceron-project/reduceron.pdf https://mn416.github.io/reduceron-project/reduceron.pdf - Burrows (2009) “A combinator processor”: https://q4.github.io/dissertations/eb379.pdf https://q4.github.io/dissertations/eb379.pdf - Ramsay and Stewart (2023) “Heron: Modern Hardware Graph Reduction”: https://dl.acm.org/doi/10.1145/3652561.3652564 https://dl.acm.org/doi/10.1145/3652561.3652564 - Nicklisch-Franken and Feizerakhmanov (2024) “Massimult: A Novel Parallel CPU Architecture Based on Combinator Reduction”: https://arxiv.org/abs/2412.02765v1 https://arxiv.org/abs/2412.02765v1 - Xie, Ramsay, Stewart, and Loidl (2025) “From Haskell to a New Structured Combinator Processor” (KappaMutor): https://link.springer.com/chapter/10.1007/978-3-031-99751-8_7 https://link.springer.com/chapter/10.1007/978-3-031-99751-8_... More: https://haflang.github.io/history.html https://haflang.github.io/history.html
- Peteragain 11mo agoWow! Thanks! It was a half a thought but that interaction is right up there with "the big red button" and makes the last 20 years of enshitification all worth while!
- skeezyjefferson 11mo ago> Okay they're dead jesus christ dont say that around here, youll be swamped by fanatical emacs users describing various bits of lisp theyve written over the years and what they each do. it will send you insane
- dist-epoch 11mo ago> 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.
- rmunn 11mo agoAI 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, and will go under. I can't predict when the shakeout will be, but I can predict that not every AI company is going to survive when it happens. The ones that do survive will be the ones that found a viable niche people are willing to pay for, just as the dot-com bubble bursting didn't kill Paypal, eBay, and so on. But there are definitely going to be some companies going bankrupt, that's pretty clear even at this point.
- whstl 11mo agoMost 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.
- ErroneousBosh 11mo ago> I'm hearing more and more people outside the tech world talk about the AI bubble, and predicting it's going to pop I'm juuust about old enough to remember the end of the Lisp Machine bubble (we had one or two at uni in the early 90s, and they were archaic by then). But obviously Lisp machines were the wrong way to go, even if they were a necessary step - obviously, hardware-mediated permanent object storage is the way forwards! POP! Ah, maybe not. Okay but can't you see we need to run all this on a massive transputer plane? POP! Oh. Okay how about this, we actually treat the microcode as the machine language, so the user-facing opcodes are like 256 bits long, and then we translate other instruction sets into that on the fly, like this - the Transmeta Crusoe! It's going to revolutionise everything! POP! Ah, what? Okay well how about... And we're only up to the early 2000s. It's bubbles, all the way back. Many of these things were indeed necessary steps - if only so We Learned Not To Do That Again - but ultimately are a footnote in history. In 30 years' time people will have blog posts about how in the mid-2020s people had this thing where they used huge sheds full of graphics cards to run not-working-properly Boolean algebra to generate page after page after page of pictures of wonky-looking dogs and Santa Clauses, and we'll look at that with the same bemused nostalgia as we do with the line printer Snoopy calendars today.
- cess11 11mo agoI'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.
- logicprog 11mo agoI'm a lisp machine romantic, but only for the software side. The hardware was neat, but nowadays I just want a more stable, graphically capable emacs that extends down through and out across more of userspace.
- matheusmoreira 11mo ago> 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.
- logicprog 11mo agoOh my god, that's so cool? Could I see by any chance? (Edit: found links on your profile, will read more)
- matheusmoreira 11mo agoI call it the lone programming language. https://github.com/lone-lang/lone/ 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-lisp-applications https://www.matheusmoreira.com/articles/self-contained-lone-... https://www.matheusmoreira.com/articles/delimited-continuations-in-lone-lisp 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 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 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.
- Validark 11mo agoI liked the article, but I found the random remark about RISC vs CISC to be very similar to what the author is complaining about. The difference between the Apple M series and AMD's Zen series is NOT a RISC vs CISC issue. In fact, many would argue it's fair to say that ARM is not RISC and x86-64 is not CISC. These terms were used to refer to machines vastly different from what we have today, and the RISC vs CISC debate, like the LISP machine debate, really only lasted like 5 years. The fact is, we are all using out-of-order superscalar hardware where the decoder(s) of the CPU is not even close to the main thing consuming power and area on these chips. Under the hood they are all doing pretty much the same thing. But because it has a name and a marketable "war" and that people can easily understand the difference between fixed-width vs variable-width encodings, people overestimate the significance of the one part they understand compared to the internal engineering choices and process node choices that actually matter that people don't know about or understand. Unfortunately a lot of people hear the RISC vs CISC bedtime story and think there's no microcode on their M series chips. You 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.
- ErroneousBosh 11mo ago> In fact, many would argue it's fair to say that ARM is not RISC It isn't now... ;-) It's interesting to look at how close old ARM2/ARM3 code was to 6502 machine code. It's not totally unfair to think of the original ARM chip as a 32-bit 6502 with scads of registers. And, for fairly obvious reasons!
- Joker_vD 11mo agoBut even ARM1 had some concessions to pragmatics, like push/pop many registers (with a pretty clever microcoded implementation!), shifted rigsters/rotated immediates as operands, and auto-incrementing/decrementing address registers for loads/stores. Stephen Furber has extended discussion of the trade-offs involved in those decisions in his "VLSI RISC Architecture and Organization" (and also pretty much admits that having PC as a GPR is a bad idea: hardware is noticeably complicated for rather small gains on the software side).
- ErroneousBosh 11mo agoI'm not so sure it's down to the hardware. With something like 180-bit wide microcode store - a very very horizontal microarchitecture - the hardware sure was specialised, but I think it's fundamentally down to Lisp itself. I don't know a lot of Lisp. I did some at school as a teenager, on BBC Micros, and it was interesting, but I never did anything really serious with it. I do know about Forth though, so perhaps people with a sense of how both work can correct me here. Sadly, Forth, much as I love it and have done since I got my hands on a Jupiter Ace when I was about 9 or 10 years old, has not been a success, and probably for the same reasons as Lisp. It just looks plain weird. It does. I mean I love how elegant Forth is, you can implement a basic inner interpreter and a few primitives in a couple of hundred lines of assembler and then the rest is just written in Forth in terms of those primitives (okay pages and pages of dw ADDRESS_OF_PRIMITIVE instructions rather Forth proper). I'm told that you can do the same trick with Lisp, and maybe I'll look into that soon. But the code itself looks weird. Every language that's currently successful looks like ALGOL. At uni, I learned Turbo Pascal. That have way to Modula-2 in "real" programming but by then I'd gotten my hands on an account on the Sun boxes and was writing stuff in C. C looked kind of like Pascal once you got round the idea that curly brackets weren't comments any more, so it wasn't a hard transition. I wrote lots of C, masses and masses, and eventually shifted to writing stuff in Python for doing webby stuff and C for DSP. Python... looks kind of like ALGOL, actually, you don't use "begin" and "end", you just indent properly, which you should be doing. Then Go, much later, which looks kind of like Pascal to me, which in turn looks kind of like ALGOL. And so on. You write line after line after line of "this thing does this to that", and it works. It's like writing out a recipe, even more so if you declare your ingredients^W variables at the top. I love Forth, I really want to love Lisp but I don't know enough about it, but everyone uses languages that look like ALGOL. In the late 1960s Citroën developed a car where the steering and speed were controlled by a single joystick mounted roughly where the steering wheel would be. No throttle, no clutch, no gears, just a joystick with force feedback to increase the amount of force needed to steer as the car sped up. Very comfortable, very natural, even more so when the joystick was mounted in the centre console like in some aircraft. Buuuuut, everyone uses steering wheels and pedals. It was too weird for people.
- brabel 11mo ago
- EdwardCoffin 11mo ago>> ‘It was the development environment’ > No, it wasn’t. I kind of think it was. The best argument I think is embodied in Kent Pitman's comments in this usenet thread [1] where he argues that for the Lisp Machine romantics (at least the subset that include him) what they are really referring to is the total integration of the software, and he gives some pretty good examples of the benefits they bring. He freely admits there's not any reason why the experience could not be reproduced on other systems, it's that it hasn't been that is the problem. I found his two specific examples particularly interesting. Search for * Tags Multiple Query Replace From Buffer and * Source Compare which are how he introduced them. He also describes "One of the most common ways to get a foothold in Genera for debugging" which I find pretty appealing, and still not available in any modern systems. [1] https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/Xz4Mww0ZwLIJ https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/X...
- anthk 11mo agoYou would like this dump too then: https://www.yarchive.net/comp/lisp_support.html https://www.yarchive.net/comp/lisp_support.html
- lgrapenthin 11mo agoTo me, it was never about the hardware. It was not even about LISP. It is about "clean design" and what a great computing environment was capable of, and still would be, had its potential not been shredded by the advent of cheap addicting hardware combined with an "operating system" so "simple and elegant" that even today, a program simply segfaults leaving you with nothing (instead of showing at least an inspectable stacktrace). So "simple and elegant" that the only two data formats end users are dealing with are "copy & paste text", "files", and "screenshots". An operating system so "pure" that every program lives in its own uninteroperable walled garden, that understands nothing about the environment and data loaded around it. We lost a whole computing world and it might still take ages getting that back.
- dieortin 11mo agoIf you ship debug symbols with your binary, you do get a core dump with an inspectable stacktrace…
- emchammer 11mo agoI don’t want an Open Genera machine in a portable case with a battery, though. I want Apple’s software to match the quality of their hardware.
- bitwize 11mo agoFun fact: NeXT's Interface Builder was originally built in Lisp. So Apple software was really good at one point, in part because someone wanted to bring the Lisp machine to the NeXT environment.
- teunispeters 11mo agoLisp - 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 possible in that venue, just like I find rust code fascinating. These days lisp is much more workable, as they slowly get over the "must coexist with other software". There are still things that are really hard to put in other computer languages.
- dreamcompiler 11mo agoThese 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.
- teunispeters 11mo ago"sort of". C++ is a lot more stable ABI these days, but linking still means looking into name mangling and data types. At least it no longer seems to be changing between compiler patches, as with - say - earlier GCC. (gcc 2 through 4 were not fun for this) From a look a little, it seems rust has this pretty reliably - probably helped by sharing link environments with LLVM. (I've only explored this a little from time to time). Mostly my work is all C and a bit of C++.
- bitwize 11mo agoI 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.
- iLemming 11mo ago> slowly get over the "must coexist with other software" I dunno, as a Lisper I don't even have to think very hard - virtually any platform available to me, I can write almost anything in Lisp - for JVM and .Net - with Clojure; for Lua with Fennel; for Flutter with ClojureDart; Python - libpython-clj; C/C++ - Jade, CL, Carp and Jank; BEAM - Clojerl and LFE; Shell-scripting - babashka; For targeting js there are multiple options - clojurescript, nbb, squint. Knowing some Lisp today is as practical as it gets. I really feel like a true polyglot coder - switching between different Lisps, even for drastically dissimilar platforms incurs virtually zero overhead while jumping even between JS and TS is always a headache.
- znort_ 11mo agofunny no mention about the texas instruments explorer: https://en.wikipedia.org/wiki/Texas_Instruments_Explorer https://en.wikipedia.org/wiki/Texas_Instruments_Explorer i barely got to play with one for a few hours during an "ai" course, so i didn't really figure much of it out but ... oh yeah, it was "cool"! also way-way-way over my budget. i then kept an eye for a while on the atari transputer workstation but no luck, it never really took off. anyway, i find this article quite out of place. what hordes of romantically spoiled lisp machine nostalgia fanatics harassed this poor guy to the extreme that he had to go on this (pretty pointless) disparaging spree?
- rjsw 11mo agoThe author has owned Lisp Machines himself, maybe still does.
- Arubis 11mo agoIn many ways, [GRiSP](https://www.grisp.org/ https://www.grisp.org/) feels like Lisp machines’ spiritual successor.
- rurban 11mo agoNo, smalltalk was
- PaulHoule 11mo agoThis document https://userpages.umbc.edu/%7Evijay/mashey.on.risc.html https://userpages.umbc.edu/%7Evijay/mashey.on.risc.html explains a lot of "what happened in the 1980s?" particularly why VAX and 68k were abandoned by their manufacturers. The last table shows how processors that had really baroque addressing modes, particularly involving indirection, did not survive. The old 360 architecture was by no means RISC but it had simple addressing modes and that helped it survive. A Lisp-optimized processor would be likely to have indirection and generally complex ways how instructions can fail which gets in the way of efficient pipelined implementations. People like to talk about "separation of specification and implementation" but Common Lisp was designed with one eye on the problem of running it efficiently on the "32-bit" architectures of the 1980s and did OK on the 68k which was big then and also with the various RISC architectures and x86 which is simple enough that it is practical to rewrite the instruction stream into microinstructions which can be easily executed.
- gwbas1c 11mo agoThis just reminds me of the people who whine about Betamax (or CCS) being better. FWIW: Technology Connections did a teardown of why Betamax wasn't better than VHS: https://www.youtube.com/watch?v=_oJs8-I9WtA&list=PLv0jwu7G_DFUrcyMYAkUPODENwP4gYCmf&index=3 https://www.youtube.com/watch?v=_oJs8-I9WtA&list=PLv0jwu7G_D... And the whole series if you actually enjoy watching these things: https://www.youtube.com/playlist?list=PLv0jwu7G_DFUrcyMYAkUPODENwP4gYCmf https://www.youtube.com/playlist?list=PLv0jwu7G_DFUrcyMYAkUP...
- waffletower 11mo agoI liked betamax better, sorry. The tapes were more compact and used less storage space. Can't argue with that. I also liked that you could use betamax with a Sony PCM F1 processor to record digital audio before the advent of the DAT format (digital audio tape). Can't argue with that. But when was the last time I even thought about betamax? Much more front of mind are the vagaries of blu-ray formats; and I rarely think about them either.
- gwbas1c 11mo agoAre you joking? (Or otherwise trying to prove my point?) > The tapes were more compact and used less storage space. That generally is considered the "death nail" of the format. People generally chose VHS because they could record 6-9 hours on a single tape, (while on vacation,) but the smaller size of the Betamax cassette limited it to shorter recordings. It also impacted quality of feature length movies: They used the fastest tape speed on VHS, but had to be a slower tape speed on Betamax, negating the supposed quality improvement on Betamax. > I also liked that you could use betamax with a Sony PCM F1 processor to record digital audio before the advent of the DAT format (digital audio tape) Most people (consumers) never used their VCRs to record and play back digital audio, they used CDs and cassettes. The PCM F1 was a professional / prosumer device, not a consumer device like a CD player. I assume that people who were using it were going to have a separate VCR for studio use than their living room (VHS), and weren't going to decide between VHS vs Betamax for pairing with their PCM F1.
- kragen 11mo agoIIRC the Open Genera folks said the Alpha RISC code to interpret the Symbolics instruction set, which fit in the Alpha's cache, ran about as fast as you'd expect microcode to run. So in a sense we're all writing microcode now? It's probably worth reading this Alan Kay comment, which I excerpted from https://www.quora.com/Papers-about-the-Smalltalk-history-refer-to-the-importance-of-the-Xerox-Altos-design-as-a-meta-computer-in-which-many-unanticipated-needs-could-be-emulated-in-microcode-Why-modern-computer-architectures-are-not https://www.quora.com/Papers-about-the-Smalltalk-history-ref... on Quora before it started always blocking me as a robot: > The idea of microcode was invented by Maurice Wilkes, a great pioneer who arguably made the earliest programmable computer — the EDSAC (pace Manchester Baby). The idea depends partly on the existence of a “large enough” memory that is much faster (3–10 times) than the 1st level RAM of the computer. > A milestone happened when the fast memory for microcoding was made reloadable. s Now programmable functions that worked as quickly as wired functions could be supplied to make a “parametric” meta-machine. This technique was used in all of the Parc computers, both mainframes and personal computers. > Typical ratios of speed of microcode memory to RAM were about 5x or more, and e.g the first Altos had 4kbytes (1k microinstructions) that could be loaded on the fly. The Alto also had 16 program counters into the microcode and a shared set of registers for doing work. While running, conditions on the Alto — like a disk sector passing, or horizontal retrace pulse on the CRT — were tied to the program counters and these were concurrently scanned to determine the program counter that would be used for the next microinstruction. (We didn’t like or use “interrupts” … ) > This provided “zero-overhead tasking” at the lowest level of the machine, and allowed the Alto to emulate almost everything that used to be the province of wired hardware. > This made the machine affordable enough that we were able to build almost 2000 of them, and fast enough to do the functionality of 10–15 years in the future. > Key uses of the microcode were in making suitable “language machines” for the VHLLs we invented and used at Parc (including Smalltalk, Mesa, etc.), doing real time high quality graphical and auditory “animations/synthesis”, and to provide important systems functions (e.g. certain kinds of memory management) as they were invented. > It’s worth looking at what could have been done with the early 16 bit VLSI CPUs such as the Intel 8086 or the Motorola 68K. These were CISC architectures and were fast enough internally to allow a kind of microcoding to support higher level language processing. This is particularly important to separate what is a kind of interpreter from having its code fetched from the same RAM it is trying to emulate in. > The 68K in fact, used a kind of “nano-coding”, which could have been directed to reloadability and language processing. > The big problem back then was that neither Intel nor Motorola knew anything about software, and they didn’t want to learn (and they didn’t). > The nature of microcode is that architectures which can do it resemble (and anticipated) the RISC architectures. And some of the early supercomputers — like the CDC 6600 — were essentially RISC architectures as well. So there was quite a bit of experience with this way of thinking. > In the 80s, the ratio between RAM and CPU cycles was closing, and Moore’s Law was starting to allow more transistors per chip. Accessing a faster memory off CPU chip started to pay off less (because going off chip costs in various ways, including speed). > Meanwhile, it was well known that caching could help most kinds of architectures (a landmark study by Gordon Bell helped this understanding greatly), and that — if you are going to cache — you should have separate caches for instructions and for data. > Up to a point, an instruction cache can act like a microcode memory for emulating VHLLs. The keys are for it (a) to be large enough to hold the inner loops of the interpreter, (b) to not be flushed spuriously, and (c) for the machine instructions to execute quickly compared to the cache memory cycle. > Just to point the finger at Intel again, they did a terrible job with their cached architectures, in part because they didn’t understand what could be gained with VHLLs. > A really interesting design was the first ARM — which was a pretty clean RISC and tidy in size. It could have been used as an emulator by wrapping it with fast instruction memory, but wasn’t. I think this was a “point of view” disconnect. It was a very good design for the purpose of its designers, and there wasn’t enough of a VHLL culture to see how it could be used at levels much higher than C. > If we cut to today, and look at the systems that could be much better done, we find that the general architectures are still much too much single level ones, that ultimately think that it is good to have the lowest levels in a kind of old style machine code programmed in a language like C. > A very different way to look at it might be to say: well, we really want zillions of concurrent and safe processes with very fast intermessaging programmed at the highest levels — what kind of architecture would facilitate that? We certainly don’t want either “interrupts” or long latency process switching (that seems crazy to “old Parc people”. We probably want to have “data” and “processing” be really close to each other rather than separated in the early von Neumann ways. > And so forth. We won’t be able to be perfect in our hardware designs or to anticipate every future need, so we must have ways to restructure the lowest levels when required. One way to do this these days is with FPGAs. And given what it costs to go off chips, microcoding is far from dead as another way to help make the systems that we desire. > The simple sum up here is that “hardware is just software crystallized early”, and a good systems designer should be able to design at all levels needed, and have the chops to make any of the levels if they can’t be purchased …
- seanhunter 11mo agoA 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.
- tempodox 11mo agoAn interesting article. And the HPC footnote puts some perspective on today’s fad: “AI”. The specialized hardware of today will be close-to-commodity tomorrow and today’s data monsters will be nothing but energy-wasting curiosities tomorrow. Maybe some will be preserved in a museum.