23 ms·

Why we need Lisp machines

221 points by otacust 5y ago

shaunxcode 5y ago
The JVM is my lisp machine.
PaulHoule 5y ago
What ramblings. Optane is the best performing SSD but the worst performing RAM you ever had. It is too expensive at any speed, even if Intel is losing money on it. HP memristors are vaporware. LISP machines, Java machines, and similar architectures specialized for complex language runtimes are a notorious dead end. They just can’t keep up with performance-optimized RISC, pipelined, superscalar, SIMD, etc. architectures paired with compilers and runtimes that implement efficient abstractions (e.g. garbage collection, hotspot compilers) on top of those very fast primitives.
- imglorp 5y ago
  Speed is relevant for some use cases, sure, but not at all for a ton of others. Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? It's time for some different abstractions than file -> process -> file. The vast productivity gains of Smalltalk and Lisp were because they discarded those abstractions and programmers were free for others. Presumably OP posted this after noticing Phantom came up a few days ago. https://news.ycombinator.com/item?id=30807668 https://news.ycombinator.com/item?id=30807668
  - deleted 5y ago
    [deleted]
  - bigbillheck 5y ago
    > Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? Elsewhere on this very site you'll find no ends of complaints about, say, Electron apps.
    - PaulHoule 5y ago
      For general purpose computing applications expand to fill the performance available (that includes real value and bloat!) I dabble in microcontrollers for fun and there it's different. I am an AVR-8 fanatic and sometimes I think "this is so fast" and "2K of RAM is plenty" and "I can fit CRC-32 tables in 32k of flash because that's what counts as an 'operating system' for me" Then there are the applications where it just doesn't have the power and I am so glad to have a box of RP2040's because in 2022 the most important attribute of a microcontroller is that it is available.
- zozbot234 5y ago
  The RISC-V folks are working on additions for special support of "complex language runtimes". Pipelined, SIMD and superscalar are all well and good, but what kills pure software-side support is always heavy branching and dispatching. These operations are genuinely much faster and more power-efficient when implemented in hardware.
- lispm 5y ago
  Before Lisp Machines were killed in the market it was clear that new architectures were needed and a few were under development, even RISC like CPUs. They weren't released. But Lisp at that time was already fast enough on standard RISC chips (MIPS, SPARC, ALPHA, POWER, ...). Later the 64bit RISC chips also provided enough memory space. SPARC also had some tricks for Lisp implementors. Currently the assembler coded Ivory emulator is 80 times faster on Apple's M1 than the last Ivory hardware (the Ivory Microprocessor from Symbolics was released end 80s).
- DonHopkins 5y ago
  How is the ARM not a "JavaScript Machine"? https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... >Why do ARM chips have an instruction with Javascript in the name (FJCVTZS)? https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/arm-community-blogs/b/architecture...
  - PaulHoule 5y ago
    That instruction is a very small hack that uses just a few transistors to speed up a bit of data conversion that JS runtimes do frequently. That’s a far cry from a specialized chip.
snek_case 5y ago
You could do some powerful things with LISP machines but I think the underlying assumption is that everything is written in LISP, or compiles to LISP (or its underlying bytecode). That places restrictions on what you can do. For example, does it do high-performance multithreading and SIMD right? Also not sure LISP machines solved security as well as modern-day Linux does. I think it was just less of a concern back then, because you knew most of the people who were on the network.
- pjmlp 5y ago
  The answer for that question lies with Connection Machine and Star-Lisp. https://en.m.wikipedia.org/wiki/Connection_Machine https://en.m.wikipedia.org/wiki/Connection_Machine
  - mark_l_watson 5y ago
    I used to start writing Star-Lisp code for my company’s Connection Machine (version 1, the SIMD one) by using Coral Common Lisp on my little Macintosh. Then I would get on an airplane and fly to the city where out CM was installed.
h2odragon 5y ago
Part of the hype and hope of the "OLPC" laptops was that it would generate a "Python machine" userland, if not entire OS.
rst 5y ago
Some of this needs checking -- you could not run Unix on Symbolics hardware. LMI did have machines that ran both OSes -- but Unix was running on a separate 68000 processor; see, e.g. http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf (3600-series Symbolics machines also had a 68k "front end processor", but no Unix port was provided for it; they also ultimately had a C compiler that could generate code for the "Lisp processor", but the code it generated was intended to run in the Lisp environment.) It's also worth noting that systems-level code for Symbolics machines (and, I presume, LMI as well) made frequent use of "unsafe subprimitives", misuse of which could easily crash the machine. And, unfortunately, if you needed to, say, get anything close to hardware bandwidth out of the disk drives, some of this became well-nigh unavoidable, due to poor performance of the OS-level file system (LMFS).
- lispm 5y ago
  What one could do was running hardware Lisp Machines from Symbolics on VME boards inside a SUN: the UX400 and UX1200. Later Open Genera was sold as a Virtual Lisp Machine running on a DEC Alpha / UNIX system.
  - skissane 5y ago
    Apparently Open Genera now even runs under macOS on Apple M1s: https://twitter.com/gmpalter/status/1359360886415233029 https://twitter.com/gmpalter/status/1359360886415233029 I think the big problem with Genera is the licensing. Although it comes with source code, it is proprietary software, and buying a license is expensive. I think the owners of the Symbolics IP have prioritised squeezing the maximum revenue out of a declining user base over trying to grow that user base. I'm surprised "Open Source LispOS" projects have largely failed to gain traction. Writing your own OS is (at least in some ways) easier than it used to be (especially if you target virtualisation rather than bare metal). There seem to be a lot more people saying "LispOS is what we need!" than actually writing one or contributing to an existing effort to write one.
mportela 5y ago
For a somewhat complete history of LISP machines, I recommend reading "Hackers: Heroes of the Computer Revolution" [1]. [1] https://www.goodreads.com/book/show/8260364-hackers https://www.goodreads.com/book/show/8260364-hackers
- scruple 5y ago
  Thanks for the recommendation. I've been learning/using CL, on the side, for about a year, in fits and starts, and I'm also picking up a lot of it's history and evolution along the way. I find the history of the thing is as fascinating as the language/tools. There's so much written on this but it's hard to aggregate and put together. Links lead to other links that lead to other links and oftentimes a lot of them are dead. So I'm glad that there are books like this that can preserve some pieces of the story.
mportela 5y ago
This post would benefit from further expanding some of these statements. > UNIX isn’t good enough anymore and it’s getting worse Why exactly? > A new operating system means we can explore new ideas in new ways. LISP machines were not only OSes but also hardware. Is the author also proposing running this OS on optimized hardware or simply using our x86-64/AMD/M1 CPUs? > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Sure, but it also requires rewriting a lot of these things, introducing and fixing new bugs... It feels like the good ol' "let's rewrite this program" that quite frequently doesn't live up to the expectations [1]. [1] https://vibratingmelon.com/2011/06/10/why-you-should-almost-never-rewrite-code-a-graphical-guide/ https://vibratingmelon.com/2011/06/10/why-you-should-almost-...
- pjmlp 5y ago
  Xerox PARC workstations could run Interlisp-D, Smalltalk, Mesa/XDE, Mesa/Cedar, thanks to this little thing RISC failed to kill, microcoded CPUs.
- traverseda 5y ago
  >> UNIX isn’t good enough anymore and it’s getting worse >Why exactly? Personally? We're in a bit of a transition point, and a lot of the technologies aren't working together like they used to. An example, on my laptop I want to run android apps. The way to do this that actually works well (waydroid) only supports wayland. Unfortunately I use x2x to control another display remotely, and x2x doesn't work properly under wayland, and never will due to wayland's security choices. So like, what am I supposed to do here? Not run android apps? Not use tools like barrier/synergy/x2x? This is one of many many frustrations I've had from this new generation of wayland/systemd/etc. Hopefully it gets better eventually but it does feel a lot like the rug is constantly being pulled out from under me for no good reason... Now I don't think a lisp machine is going to fix that mind you, but it is a concern.
  - zozbot234 5y ago
    You can actually start a Wayland compositor/session in a X window. That plus existing solutions for Wayland network transparency should be enough.
zozbot234 5y ago
Just run Emacs as your Lisp Virtual Machine. All it really needs is a good editor, but evil-mode is kinda serviceable.
- FPGAhacker 5y ago
  I have had this thought. Jokes about needing a good editor aside, I wondered about making a unikernal that bootstraps enough to start emacs. The issue I see with the idea of lisp-all-the-way-down is that most people don’t want to write filesystems and device drivers. I know I don’t. I mean I find them fascinating, but I usually have a specific app I want to write. I don’t want to write device drivers on my way there.
  - convolvatron 5y ago
    you could do this with nanos...but i dont know how that would benefit you
daniel-cussen 5y ago
So it's interesting to note modern hardware is only 60x faster than Lisp machines when it should be 1000x. Weirdness of Lisp, turns out hardware isn't some random thing. And harder to compromise than modern stuff, by a huge amount, real actual security improvement.
- glmdev 5y ago
  Not saying you're wrong, but do you have a source for the 60/1000x number? Curious to read more.
  - daniel-cussen 5y ago
    Yeah, where did I read it, I think John McCarthy checked it out along with...who could it have been...definitely him.
    - lispm 5y ago
      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).
      - daniel-cussen 5y ago
        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...
scroot 5y ago
Leaving the specific idea of the Lisp Machine aside, today there we have a tremendous advantage over the past when it comes to creating the kind of full, self-consistent systems Lisp Machines -- and systems like Smalltalk or Oberon, etc -- represent. Today we have widely accepted communications and data format standards. This is something that really isolated system diversity in the past, where you were "stuck" in some given computing system and had little ways of interacting with other types of computing systems. We have figured all of that out. We should hope to see a flourishing of new and diverse systems again, since now all one need to do to interact with everyone else is merely (and I know it's a slog) implement tried and true standards.
- lispm 5y ago
  One can implement these standards. Problem: it's work. They supported things like TCP/IP, UDP, SMTP, X11, RPC, NFS, DNS, HTTP, ... The machines had C compilers, too.
  - scroot 5y ago
    Some of these new systems should definitely be lisp machines of a kind, though not direct clones of Genera. We need something more "of the times." In reality, there are only a few things people expect of their computing systems, but those things are huge: decent graphics and components for the UI, and a web browser. So, yeah, standards and protocols are there. And it would take a s*t-ton of work to implement them in a bespoke environment. But they are not "difficult" in the classic sense. If we had a completely different type of economy it might even be possible!
mark_l_watson 5y ago
I don’t really agree. I had a Xerox 1108 Lisp Machine in the 1980s and loved it, but special purpose Lisp hardware seems like a waste of effort. I set up an emulator for the 1108 last weekend, and yes, I really did enjoy the memories, and things ran an order of magnitude faster than on the 1108 in the 1980s. Then, I appreciated my M1 MacBook Pro running SBCL, LispWorks, Haskell, Clojure, and various Scheme languages - all with nice Emacs based dev setups. Life is really good on modern hardware.
- lispm 5y ago
  The 1108 wasn't really special purpose Lisp hardware. One could run other operating systems on it. What made it special purpose was the loaded microcode for the CPU. > Life is really good on modern hardware. Agreed: On modern CPUs. More support for the additional hardware features like GPUs, media processing engines and the neural network engines (see the M1 Pro/Max/Ultra) would be welcome.
  - mark_l_watson 5y ago
    The best bet for getting GPU deep learning support, I use Anaconda/conda, using the Apple M1 channel. That said, I usually use my Linux GPU rig or Colab for deep learning.
- mst 5y ago
  I feel like a lot of posts like this are pining for the complete lisp machine -user environment- and overestimating how necessary/important the hardware architecture would be to getting back to that today. I can manage to context switch between different lisps fine but I do sometimes wonder in e.g. a slime+SBCL setup how much that context switching is costing me.
pbohun 5y ago
If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp. While the Plan9 mouse chording is cool (and could be kept), I would have everything also accessible via keyboard commands. 3 button mouse chording on a laptop trackpad is not fun.
- mananaysiempre 5y ago
  Executable-images-and-bytestreams (Research Unix, Plan 9) and everything-is-in-$LANGUAGE (Lisp machines, Emacs, Smalltalk, Oberon, Forth) environments seem largely contradictory to me, because much of the flexibility in Unix seems to come from the freedom to ignore as much structure in the data as you want to, while programming-language environments seem to derive their advantages from expressing the structure in as detailed a way as possible. (In particular, they really want to invent their own storage formats for everything.) I don’t have much of an idea about Inferno, but my superficial impression is it also mostly ends up as a single-language island. Which is annoying, because both of these approaches produce some really attractive results, so I’d very much like to learn about any attempts to reconcile them.
  - zozbot234 5y ago
    "Expressing structure" is just a higher layer on simple bytestreams. Some historical operating systems only supported special-cased "file types" with hard-coded structure, but the *IX folks found out that the simple bytestream is enough.
- pjmlp 5y ago
  It used Limbo and was called Inferno.
ogogmad 5y ago
When the author talks about too many languages and libraries, I personally think he means the proliferation of Unix DSLs (some of which are Posix and some are not) like Make, Awk, Sed, BC, DC, shell-script dialects, Gnuplot (I know it's not Posix but it was widely used once), xargs, Vimscript, ELisp. Each of these has its own quirks and random limitations. Each of these makes Unix unnecessarily complicated and difficult to learn, and they don't even accomplish much that's impressive. I also think they make the editing experience worse, because they prevent the use of IDEs or highly featured REPLs like the ones general-purpose languages have. I imagine that a lot of this can be replaced with libraries for a general-purpose language like Python. In the case of Awk, BC and DC, Python's standard library does everything these do without their strange quirks. Gnuplot can be replaced with umpteen plotting libraries like Matplotlib. Shell-scripting can be done in a Python dialect like Xonsh. I don't know of a Python alternative to Make, but Make is a fairly perverse and ad-hoc language that looks ripe for being replaced by a library. I don't think a new operating system (however you define that) is necessary. I think you just swap out a lot of the crazy DSLs with one consistent general-purpose language. People will switch over when they want to accomplish things more easily (like me!). This is especially likely if you're not a SWE but you want to do file system automation anyway. The DSL-heavy approach is too Byzantine for such people (like me!). And it's mostly possible today.
- eternityforest 5y ago
  I wouldn't even say any of those make UNIX difficult to learn. 99% of people can be users and developers just fine without learning awk or sed or even make, if they don't do low level work. It can all be incrementally replaced over time, without starting over, just like how systemd and pipewire didn't need to totally start over. Make will probably need something more than just a library though, because it's gotta stay declarative. But the fact that make exists at all is kind of an issue. I think build and package management should be done in the language itself like non-C languages do. The other use of make is almost as a pseudo UI, just a standard place to put a list of actions you can do. Something like Ansible could replace that, in theory, or we could have some new "project control center" file with menus and inputs and settings.
  - deleted 5y ago
eternityforest 5y ago
UNIX is fine. UNIX philosophy is an issue, along with C, and the fact that everything now is mobile and web based and the tools aren't well suited to offline/nonSaaS stuff yet. Linux is slowly becoming a standardized, integrated platform. I don't see why it can't be evolved to have all the main advantages of a LISP machine. I also don't see how that solves dependency management. No matter what, if you build against something and it changes, stuff breaks. That's the main issue with Linux. It also doesn't solve microservices being kinda hard and needing manual configuration specifically for the setup, rather than the one size fits all style of monolithic desktop software. That's an application architecture challenge. Nor does it solve cross-platform. Linux does have problems and could learn from LISP machines(Although I'd rather we have TypeScript machines or Python or something, LISP is pretty far from what I want a language to be, and is meant for creativity and expressiveness rather than Ada-like safety and boring hacker-repelling Java-like standardization). But a lot of issues go away if you pretend everything other than Debian and Red Hat don't exist.
- agumonkey 5y ago
  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.
  - taeric 5y ago
    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?
    - agumonkey 5y ago
      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.
codr7 5y ago
The future is already here, but unfortunately it's programmed in elisp and still lacks a decent editor.
- codr7 5y ago
  Oh, come on; I love Emacs, and I admire RMS a lot. And I mean it, Emacs is as close to a Lisp Machine as you get in today's world.
- ByteJockey 5y ago
  Emacs has a great editor... The evil package.
DonHopkins 5y ago
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....
mikewarot 5y ago
The key thing about those type of systems was the ability to reach down into the system and edit the code of the system currently in operation. Here's a demonstration of Symbolics Open Genera (TM) 2.0, demonstrated running in a virtual machine. It is noted by the author of the video in the first minute or so that even in emulation, it is much faster than the original machines. - https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible. The same was true of the Canon Cat, Hypercard, Ted Nelson's Xanadu project, Smalltalk, and a number of other early computing systems. The main feature common to all of these systems is that they all preserve context. In Genera, Oberon, Canon Cat, Hypercard, and SmallTalk the source was always available. (as far as I know). In Xanadu, the main functionality of the web was present, but it wouldn't allow the broken links (and lost context) that now plague the web. I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments. There's nothing stopping an open source project from taking elements of these existing systems and moving forward from that basis. It might be profitable to include ideas such as Coloring of the Source text to label intent, such as in ColorForth. Also, consider "Literate Programming" - Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code. You could also add the ability to store graphics and other data along with the source code. Of course, if you are required to run code you didn't write and don't trust, your operating system must provide means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model. Sorry it was a bit of a ramble, but this seemed to be a call for ideas, so I ran with it. PS: In the past, getting your vision of Computing required building a machine, and then getting it manufactured. Now it just requires that you make it work in a VM, Raspberry Pi, or web browser window. It is MUCH easier to try out and/or create alterative systems now that it has ever been in the past.
- 5y ago
reikonomusha 5y ago
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 remained one of the most powerful programming languages (I think it's true, but don't read into it too much). Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough. 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, interest, willpower, and/or money. Don't get me wrong, there are some Lisp programmers today developing superlative libraries and applications [1], but the Lisp population is thin on them. I'd guess that the number of publicly known, interesting (by some metric), and maintained applications or libraries that have sprung up in the past decade probably fits on one side of a 3"x5" index card. [2] Though I won't accuse the article's author of such, sometimes, I find, in a strange way, that pining for the Lisp machines of yore is actually a sort of mental gymnastic to absolve one for not having written anything interesting in Lisp, and to excuse one from ever being able to do so. [1] Just to cherry-pick a recent example, Kandria is a neat platformer developed entirely in Common Lisp by an indie game studio, with a demo shipping on Steam: https://store.steampowered.com/app/1261430/Kandria/ https://store.steampowered.com/app/1261430/Kandria/ [2] This doesn't mean there aren't enough foundational libraries, or "batteries", in Lisp. Though imperfect, this is by and large not an issue in 2022.
- zozbot234 5y ago
  > 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 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 boundaries in code and "programming in the large". So everything ends up being a bespoke solo-programmer project, there is no real shared development. You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall. This might explain much of their ongoing success.
chubot 5y ago
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-style coarse-grained composition. (Not just pipes -- think about a web server running behind nginx, or git reusing SSH and HTTP as transports.) You can also use link time composition. It takes some work but it's better than rewriting your Common Lisp code from scratch in Clojure. ----- Honest question: how do you communicate between two Lisp processes on two different machines? I know Clojure has EDN (which is sort of like JSON : JavaScript), but I haven't heard of the solutions for other Lisps. I wrote about this problem here: A Sketch of the Biggest Idea in Software Architecture http://www.oilshell.org/blog/2022/03/backlog-arch.html http://www.oilshell.org/blog/2022/03/backlog-arch.html > The lowest common denominator between a Common Lisp, Clojure, and Racket program is a Bourne shell script (and eventually an Oil script). I'll definitely update it if there's something I'm missing. I would say the design of Unix is "rotting", but the answer is to IMPROVE Unix. Not dream of clean slate designs that will never be deployed. Plus this post doesn't actually propose anything. If you actually start trying to build your Lisp machine, I believe you will run into dozens of reasons why it's not a good idea.
- armitron 5y ago
  The canonical Lisps still widely used today are Common Lisp, Scheme and Emacs Lisp. They all belong in the same family, and syntax / semantics are close. Porting code from Scheme to Common Lisp can be a lot easier than going from Python 2 to Python 3. Clojure is something else entirely which is why a lot of people don't consider it a Lisp. > Honest question: how do you communicate between two Lisp processes on two different machines? If you want to use built-in object serialization, there is print and read.
  - iak8god 5y ago
    > Common Lisp, Scheme and Emacs Lisp... all belong in the same family Could you say more about what you mean by this? Is there another family of Lisps that excludes these three? I've met people who make a big deal about lisp-1 vs lisp-2 (https://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2 https://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2), and which is the right way to be a Lisp, but I think maybe those people just enjoy being pedantic.
fferen 5y ago
I have had the same thoughts before and come to a similar conclusion. I believe it's not about the language. It's about the features: runtime code editing, single address space, program interoperability. Lisp could be replaced with C or anything else. Unfortunately this is the hard part. No one is about to design completely new hardware or architecture for this, as it makes no economic sense. So we just get a shiny new language every few years, and nothing really changes.
nanochad 5y ago
> You could open up system functions in the editor, modify and compile them while the machine was running. Why would you want to do that other than hot patching a system that can't go down? Testing new changes requires more time than rebooting. If you just want to test simple changes, most debuggers can do that. > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. And with a single address space you have win9x security. > A modern UNIX system isn’t self-contained. I have 4 UNIX systems on my desk (Desktop, laptop, iPhone, iPad) I’m contentiously using the cloud (iCloud for photos, GitHub for text files, Dropbox for everything else) to sync files between these machines. The cloud is just a workaround for UNIX’s self-contained nature This is just your use habbits. Nothing is stopping you from using NFS or SSHS. Someone who feels the need to use iCloud for whatever trivial convenience it provides is unlikely to benefit from a Lisp machine's ability to edit code on the live system. > Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems. We need a replacement, something that can be built for the modern world using technologies that are clean, secure, and extendable The same thing will happen with any OS given enough time. Lisp is also not secure. It's prone to side channel and eval bugs. > eliminate memory leaks and questions of type safety, Lisp is not type safe.
- reikonomusha 5y ago
  > Lisp is not type safe. It is type safe. While Lisp is not statically typed, its typing discipline is strong: operations performed on incompatible types signal recoverable errors.
  - deleted 5y ago
    [deleted]
  - Too 5y ago
    Crashing at runtime, recoverable or not, is usually not what people mean when they say type safe. Spare me the static vs strong academia. Type safe when spoken, in practical every day terms, normally means enforced at compile time with IDE autocompletion support, usually implying static typing.
mumblemumble 5y ago
> With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack This seems like the kind of goal that's only palatable to a very few people nowadays. Specifically, the people who want to use that language, toolchain, and libraries, and nothing else. These days, I don't think that that's ever going to allow for enough of a community to support more than a relatively self-contained hobbyist scene. Which there's absolutely nothing wrong with that; personally I wish there were more compelling tinkering-oriented platforms; I'm a little meh on Unix too. But the article seems to be advocating rather loftier ambitions.
throw10920 5y ago
I think that, while the idea is solid (Unix is poorly-designed and we should have better) some of the specific ideas mentioned are lacking: > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. No! Bad! We have enough problems securing software on separate VMs running on the same metal, single address spaces are completely out of the question until someone manages to build a feasible trusted compiler system. > Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems. A lot of these problems could happen with a Lisp machine - you could have a billion different Lisps, for instance (although, to be fair, with better (i.e. non-Unix) OS design you wouldn't need containers). > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. This is partially true, but a lot of the complexity in modern software doesn't come from Unix, but just...bad design decisions. Webtech doesn't really care whether it's running on Windows or Unix, after all. Also, high-level CPUs are a bad idea: http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html I think the good in this post is along the lines of: text bad, typed IPC good, runtime-aware OS good, standardized VMs good, interactive systems (Lispy stuff, Jupyter) > batch-processing systems (Unix, C).
amelius 5y ago
The main problem with Unix right now is security / permission control. Unix was built from the perspective that users potentially don't trust each other, but users all magically trust the applications that are run. In the age of the internet, this doesn't hold anymore, and we need strong permission control.
klodolph 5y ago
I agree that we need more operating systems, but... > These machines used specialized hardware and microcode to optimize for the lisp environments (Because of microcode you could run UNIX and the Lisp OS at the same time). This is a dead end in the history of CPU design. Processors are all vaguely similar these days. Your CPU is built around ALUs which typically take one or two inputs, produce one output. Around that, you build some logic for shuttling these inputs and outputs to and from registers, or in some cases, to and from memory. The core here, the ALUs, have gotten more and more sophisticated over the years, but the wiring on the outside has remained fairly modest relative to its excesses back in the day. I'd say that the lesson here is simple: rather than add complicated operations to make your high-level language faster, do the complicated stuff in software... which gives you a lot more flexibility, and the combined hardware-software stack ends up being faster and cheaper anyway. > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. I can understand where this notion is coming from... but practically speaking, switching to Lisp doesn't eliminate memory leaks or questions of type safety or binary exploits. Even with an idealized version of Lisp, I don't think these problems could possibly go away. Neither garbage collection nor systems like Rust really "solve" memory leaks, they just provide strategies to make memory leaks less common. The same thing applies to type safety. You'd have to define "type safety" very narrowly to say that Lisp solves all type safety problems. Again, I can understand where the author comes from--it's kind of an intuitive notion of type safety, that you don't end up operating on an incorrectly typed pointer, or something like that. But the notion of type safety is much more broad than that these days. And the C/Unix strategy is actually pretty good, too, when it works--contain memory leaks within a process, then terminate the process.
VLM 5y ago
The problem with language wars is the people whom cannot be trusted with pointers, also cannot be trusted with lambdas or recursion. The name of the game has always been to avoid directly insulting the bad programmers by making fun of the languages they use. Bad programmers have clustered in several languages over the course of my long career. Mostly they are the easiest most expressive languages, which would superficially seem to be an advantage, however they make it easy to express amazingly bad ideas. The harder to express languages require more work to express a bad idea thus somewhat filtering them out of that language's pool. People whom don't understand the game think the game will be won if the bad programmers would have access to better languages for the first time in history. Despite the idea being decades old its always presented as a new idea. There's an authoritarian streak where if only we could remove access to the inferior languages then they'd have to use the better languages and we'd have better code. However you can't force people to not use inferior tools and you can't force them to learn to use better tools. The graph of easy to write and code goodness is interesting and nonlinear. You can express very complicated ideas in lisp easier than in vb6 or perl or interpreted basic or spaghetti fortran. However, you can express very bad ideas easier in a "bad" language, so it accumulates interesting authors. There is always a crossover point where an intermediate complexity idea is equally hard to express in a simple language or a complex language. Frankly most of IT needs are and always will be below that point. So its counterproductive to demand difficult language for simple tasks, everyone laughs at "Enterprise Java Hello World" that is 100K lines of enterprise patterns. Expressing ideas in computer languages is much like expressing ideas in everyday language. Some esoteric philosophy texts require a VERY large precise complicated hard to use and hard to learn vocabulary. Road signs do not. For in between jobs, trying to use a minimum number of language vocabulary words and lexical complexity would be wise. It would be a fools errand to try to cut half the vocab words from street signs to "make driving safer", or an equally bad idea to force all road signs to be expressed as Shakespearean sonnets. The real world counterpart of "Enterprise Java Hello World" would be forcing the "No U Turn" street sign to be in the form of a Shakespearean sonnet. The difficulty of tasks is usually under a power law, so its nice that we have lisp, but usually a bad idea to use lisp.
peter303 5y ago
Hardware LISP machines didnt survive the 1980s because you could emulate LISP on a general purpose CPU faster than a special machine. That is because faster new general purpose CPUs cane out every year or so, while it took 3-5 years for the next special purpose CPU.
maydup-nem 5y ago
> genera eh, if it's gui is anything like clim which was based off of it, no thank you big time
karmakaze 5y ago
The trend seems to be toward statically-typed languages, with the exception of the adoption of Python being used for data. I also prefer having more problems being found before deploying and running on production data. Dynamic typing is great for prototyping, early development, and for small teams. If your definition of success is greater than that I would choose differently, or port at a good time early on. And if someone were to ask me to join a company using lisp, I would hope that it's Clojure, though arguably not a Lisp, is better it that it will vary less between usages. This gives it a better chance of a growing ecosystem.
xedrac 5y ago
> They were programmed in lisp the whole way down and could be run code interpreted for convenience or compiled to microcode for efficiency. You could open up system functions in the editor, modify and compile them while the machine was running. Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. So this is basically expanding Emacs to actually be the operating system. There's definitely some allure to it. Awhile back, I was hacking on the Lem editor for Common Lisp, using the Lem editor itself. It was great until I made a mistake in some code that restricted my ability to edit the code, sort of like performing brain surgery on my self and snipping a nerve that controlled my arms. It was amazing to have that immediate feedback loop, but in a world that is striving to find new ways to minimize human error, I'm just not sure it'd hold up.
- mst 5y ago
  Pervasive rollback in a sufficiently compartmentalised bit of the UI that it's really hard to break would seem like the ideal theoretical solution but practically really quite tricky to introduce to an environment retroactively. (I've been pondering this problem recently for something I'm working on an introducing it from the ground up is bending my brain hard enough, others may be better at it though ;)
ogogmad 5y ago
I've started using Mathematica recently. I quite like it: I've used Sympy before, which was good, but nowhere near as "good" as Mathematica. How does it compare to the Lisp Machine operating systems? There's some vague resemblance to Lisp in treating symbols as a basic type of object. In the Mathematica use-case, these symbolic values are used to stand for algebraic variables or unknowns. Undeclared variables by default have symbolic type, with their own names being their values. (I know that other CASes do similar things here). Also, algebraic manipulations produce expressions which double as Mathematica code, which resembles the meta-programming features of Lisp. There's even glimpses of reactive programming in the way you construct interactive plots. I know this is "uncouth" because it's commercial software, but Mathematica is one of the most interesting programs I've ever used. [edit] Might something like this be the future?
abecedarius 5y ago
If I'd like to try the emulated Lisp Machine linked to (https://tumbleweed.nu/lm-3/ https://tumbleweed.nu/lm-3/), is there a straightforward getting-started doc? The page lists multiple links for each of the simulator, the bootstrap, the documentation, and umbrella projects ("to make it easier setting up", though for this one it's only a binary choice). This is not counting the multiple system sources, since only one is recommended right now. This suggests it's too much work for now if you're just curious, but it'd be great to be wrong.
charcircuit 5y ago
IMO the biggest difference is that that there is no longer a difference between binaries and libraries. Everything is a library. In UNIX there are a bunch of utilities which you just can't use from C. Also the idea of just passing data structures around instead of using a pipe passing streams of characters around is an improvement since there is no longer the need to serialize / deserialive it.
daly 5y ago
Who cares if Lisp is popular? The "lisp epiphany" is real. Either you "get it" or "you don't". I've been writing lisp programs for 50 years. I've been paid to program in 60 different languages but nothing compares with lisp. There is an intellectual "distance" between a problem and its machine solution. I call this the "impedence problem". Lisp lets you think at the most abstract and write to the most specific. Writing changed the world. But if you give most people a blank piece of paper they don't know what to do with such freedom. Lisp is the "blank piece of paper" of programming languages. Everything, literally everything, comes from you. I loved my Symbolics machine. It was the closest expression of a "thinking platform" I've ever used. IDEs are horrible for thinking, ever interrupting at every keystroke. Lisp isn't "popular" because it provides a "thinking platform" you can shape to your thoughts. Lisp will never be popular. The reason should be obvious.
- mbrodersen 5y ago
  A number of Lisp fans seems to care. That’s why we regularly see articles on HN trying to convince other developers to use Lisp. It has been going on for years. Article after article written by frustrated Lisp fans, not understanding why the language they love is not mainstream. Often making bizarre claims about non-Lisp developers not being smart enough to “get” Lisp or whatever. Not having a clue that most developers care about a lot more than just the programming language. The best way to show the “power” of Lisp is to develop commercially successful software using it. That will do way more to convince smart developers to try out Lisp than writing yet another Lisp article trying to “sell” Lisp.
  - daly 5y ago
    For the record, I made (and make) no claims about "non-Lisp developers not being smart enough". My claim is that Lisp is perfect for thinking about a new idea or a new approach. For example, I implemented a program that merged Expert Systems and Knowledge Representation into a single system (KROPS) that allowed a domain expert to express their knowledge as rules or as facts. Anything the system learned by either method could be expressed in either representation. Thus, the two representations were "unified". Another effort involved Human-Robot Cooperation to change a car tire (TIRES). The system could interact with the human through pseudo-natural language, learn rules dynamically, and expand its knowledge base of the current situation in real time. So the system self-modifies and learns through human interaction on the task. Both of these systems required self-modifying code which is rather more difficult to do in other languages. In Lisp this is trivial. As for commercial sales witness: Axiom, a 1.2 million line Computer Algebra program written in Common Lisp, was sold commercially by the Numerical Algorithms Group. YESOPS, an IBM Expert System program implemented in Common Lisp, was sold commercially.
nine_k 5y ago
> With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Oh man, wat? I love lisp as much as the next guy. But you absolutely can have library mess, memory leaks, and millions of lines of code using a Lisp. You arguably can have a "multi-language" mess, too, because Lisp gives you wonderful tools to create DSLs; I'd say creating a language that fits your needs, and then using it, is the right way to use Lisp. I use Emacs daily, and see how an all-Lisp environment can make for a good, productive interactive experience. More efforts in this area would be quite welcome, but this is a shell, not a kernel. I still suppose that systems software, and especially the key parts of an OS, need a language more like Rust than like Lisp, with a good affinity to raw hardware, and a ton of static guarantees.
yawaramin 5y ago
The Lisp machine of today is MirageOS: https://mirage.io/ https://mirage.io/ A unikernel that throws out the legacy of Unix and starts fresh to build a library operating system, it's exactly what OP describes: > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Even better, Mirage is programmed in OCaml, which is basically a statically-typed facade over Lisp (or Scheme). That's the modern Lisp machine of today. It even takes care of security nightmares like this: > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. Because in the Mirage model is program is a separate OS image and they can communicate only over defined service interfaces.

221 points by otacust 5y ago

The JVM is my lisp machine.

What ramblings. Optane is the best performing SSD but the worst performing RAM you ever had. It is too expensive at any speed, even if Intel is losing money on it. HP memristors are vaporware. LISP machines, Java machines, and similar architectures specialized for complex language runtimes are a notorious dead end. They just can’t keep up with performance-optimized RISC, pipelined, superscalar, SIMD, etc. architectures paired with compilers and runtimes that implement efficient abstractions (e.g. garbage collection, hotspot compilers) on top of those very fast primitives.

imglorp 5y ago
Speed is relevant for some use cases, sure, but not at all for a ton of others. Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? It's time for some different abstractions than file -> process -> file. The vast productivity gains of Smalltalk and Lisp were because they discarded those abstractions and programmers were free for others. Presumably OP posted this after noticing Phantom came up a few days ago. https://news.ycombinator.com/item?id=30807668 https://news.ycombinator.com/item?id=30807668
- deleted 5y ago
  [deleted]
- bigbillheck 5y ago
  > Memory, disk and CPU are almost free in this new world, so why are we computing like it's 1990 still? Elsewhere on this very site you'll find no ends of complaints about, say, Electron apps.
  - PaulHoule 5y ago
    For general purpose computing applications expand to fill the performance available (that includes real value and bloat!) I dabble in microcontrollers for fun and there it's different. I am an AVR-8 fanatic and sometimes I think "this is so fast" and "2K of RAM is plenty" and "I can fit CRC-32 tables in 32k of flash because that's what counts as an 'operating system' for me" Then there are the applications where it just doesn't have the power and I am so glad to have a box of RP2040's because in 2022 the most important attribute of a microcontroller is that it is available.
zozbot234 5y ago
The RISC-V folks are working on additions for special support of "complex language runtimes". Pipelined, SIMD and superscalar are all well and good, but what kills pure software-side support is always heavy branching and dispatching. These operations are genuinely much faster and more power-efficient when implemented in hardware.
lispm 5y ago
Before Lisp Machines were killed in the market it was clear that new architectures were needed and a few were under development, even RISC like CPUs. They weren't released. But Lisp at that time was already fast enough on standard RISC chips (MIPS, SPARC, ALPHA, POWER, ...). Later the 64bit RISC chips also provided enough memory space. SPARC also had some tricks for Lisp implementors. Currently the assembler coded Ivory emulator is 80 times faster on Apple's M1 than the last Ivory hardware (the Ivory Microprocessor from Symbolics was released end 80s).
DonHopkins 5y ago
How is the ARM not a "JavaScript Machine"? https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... >Why do ARM chips have an instruction with Javascript in the name (FJCVTZS)? https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/arm-community-blogs/b/architecture...
- PaulHoule 5y ago
  That instruction is a very small hack that uses just a few transistors to speed up a bit of data conversion that JS runtimes do frequently. That’s a far cry from a specialized chip.

snek_case 5y ago

You could do some powerful things with LISP machines but I think the underlying assumption is that everything is written in LISP, or compiles to LISP (or its underlying bytecode). That places restrictions on what you can do. For example, does it do high-performance multithreading and SIMD right? Also not sure LISP machines solved security as well as modern-day Linux does. I think it was just less of a concern back then, because you knew most of the people who were on the network.

pjmlp 5y ago
The answer for that question lies with Connection Machine and Star-Lisp. https://en.m.wikipedia.org/wiki/Connection_Machine https://en.m.wikipedia.org/wiki/Connection_Machine
- mark_l_watson 5y ago
  I used to start writing Star-Lisp code for my company’s Connection Machine (version 1, the SIMD one) by using Coral Common Lisp on my little Macintosh. Then I would get on an airplane and fly to the city where out CM was installed.

h2odragon 5y ago

Part of the hype and hope of the "OLPC" laptops was that it would generate a "Python machine" userland, if not entire OS.

rst 5y ago

Some of this needs checking -- you could not run Unix on Symbolics hardware. LMI did have machines that ran both OSes -- but Unix was running on a separate 68000 processor; see, e.g. http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf http://www.bitsavers.org/pdf/lmi/LMI_lambdaOverview_1982.pdf (3600-series Symbolics machines also had a 68k "front end processor", but no Unix port was provided for it; they also ultimately had a C compiler that could generate code for the "Lisp processor", but the code it generated was intended to run in the Lisp environment.) It's also worth noting that systems-level code for Symbolics machines (and, I presume, LMI as well) made frequent use of "unsafe subprimitives", misuse of which could easily crash the machine. And, unfortunately, if you needed to, say, get anything close to hardware bandwidth out of the disk drives, some of this became well-nigh unavoidable, due to poor performance of the OS-level file system (LMFS).

lispm 5y ago
What one could do was running hardware Lisp Machines from Symbolics on VME boards inside a SUN: the UX400 and UX1200. Later Open Genera was sold as a Virtual Lisp Machine running on a DEC Alpha / UNIX system.
- skissane 5y ago
  Apparently Open Genera now even runs under macOS on Apple M1s: https://twitter.com/gmpalter/status/1359360886415233029 https://twitter.com/gmpalter/status/1359360886415233029 I think the big problem with Genera is the licensing. Although it comes with source code, it is proprietary software, and buying a license is expensive. I think the owners of the Symbolics IP have prioritised squeezing the maximum revenue out of a declining user base over trying to grow that user base. I'm surprised "Open Source LispOS" projects have largely failed to gain traction. Writing your own OS is (at least in some ways) easier than it used to be (especially if you target virtualisation rather than bare metal). There seem to be a lot more people saying "LispOS is what we need!" than actually writing one or contributing to an existing effort to write one.

mportela 5y ago

For a somewhat complete history of LISP machines, I recommend reading "Hackers: Heroes of the Computer Revolution" [1]. [1] https://www.goodreads.com/book/show/8260364-hackers https://www.goodreads.com/book/show/8260364-hackers

scruple 5y ago
Thanks for the recommendation. I've been learning/using CL, on the side, for about a year, in fits and starts, and I'm also picking up a lot of it's history and evolution along the way. I find the history of the thing is as fascinating as the language/tools. There's so much written on this but it's hard to aggregate and put together. Links lead to other links that lead to other links and oftentimes a lot of them are dead. So I'm glad that there are books like this that can preserve some pieces of the story.

mportela 5y ago

This post would benefit from further expanding some of these statements. > UNIX isn’t good enough anymore and it’s getting worse Why exactly? > A new operating system means we can explore new ideas in new ways. LISP machines were not only OSes but also hardware. Is the author also proposing running this OS on optimized hardware or simply using our x86-64/AMD/M1 CPUs? > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Sure, but it also requires rewriting a lot of these things, introducing and fixing new bugs... It feels like the good ol' "let's rewrite this program" that quite frequently doesn't live up to the expectations [1]. [1] https://vibratingmelon.com/2011/06/10/why-you-should-almost-never-rewrite-code-a-graphical-guide/ https://vibratingmelon.com/2011/06/10/why-you-should-almost-...

pjmlp 5y ago
Xerox PARC workstations could run Interlisp-D, Smalltalk, Mesa/XDE, Mesa/Cedar, thanks to this little thing RISC failed to kill, microcoded CPUs.
traverseda 5y ago
>> UNIX isn’t good enough anymore and it’s getting worse >Why exactly? Personally? We're in a bit of a transition point, and a lot of the technologies aren't working together like they used to. An example, on my laptop I want to run android apps. The way to do this that actually works well (waydroid) only supports wayland. Unfortunately I use x2x to control another display remotely, and x2x doesn't work properly under wayland, and never will due to wayland's security choices. So like, what am I supposed to do here? Not run android apps? Not use tools like barrier/synergy/x2x? This is one of many many frustrations I've had from this new generation of wayland/systemd/etc. Hopefully it gets better eventually but it does feel a lot like the rug is constantly being pulled out from under me for no good reason... Now I don't think a lisp machine is going to fix that mind you, but it is a concern.
- zozbot234 5y ago
  You can actually start a Wayland compositor/session in a X window. That plus existing solutions for Wayland network transparency should be enough.

zozbot234 5y ago

Just run Emacs as your Lisp Virtual Machine. All it really needs is a good editor, but evil-mode is kinda serviceable.

FPGAhacker 5y ago
I have had this thought. Jokes about needing a good editor aside, I wondered about making a unikernal that bootstraps enough to start emacs. The issue I see with the idea of lisp-all-the-way-down is that most people don’t want to write filesystems and device drivers. I know I don’t. I mean I find them fascinating, but I usually have a specific app I want to write. I don’t want to write device drivers on my way there.
- convolvatron 5y ago
  you could do this with nanos...but i dont know how that would benefit you

daniel-cussen 5y ago

So it's interesting to note modern hardware is only 60x faster than Lisp machines when it should be 1000x. Weirdness of Lisp, turns out hardware isn't some random thing. And harder to compromise than modern stuff, by a huge amount, real actual security improvement.

glmdev 5y ago
Not saying you're wrong, but do you have a source for the 60/1000x number? Curious to read more.
- daniel-cussen 5y ago
  Yeah, where did I read it, I think John McCarthy checked it out along with...who could it have been...definitely him.
  - lispm 5y ago
    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).
    - daniel-cussen 5y ago
      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...

scroot 5y ago

Leaving the specific idea of the Lisp Machine aside, today there we have a tremendous advantage over the past when it comes to creating the kind of full, self-consistent systems Lisp Machines -- and systems like Smalltalk or Oberon, etc -- represent. Today we have widely accepted communications and data format standards. This is something that really isolated system diversity in the past, where you were "stuck" in some given computing system and had little ways of interacting with other types of computing systems. We have figured all of that out. We should hope to see a flourishing of new and diverse systems again, since now all one need to do to interact with everyone else is merely (and I know it's a slog) implement tried and true standards.

lispm 5y ago
One can implement these standards. Problem: it's work. They supported things like TCP/IP, UDP, SMTP, X11, RPC, NFS, DNS, HTTP, ... The machines had C compilers, too.
- scroot 5y ago
  Some of these new systems should definitely be lisp machines of a kind, though not direct clones of Genera. We need something more "of the times." In reality, there are only a few things people expect of their computing systems, but those things are huge: decent graphics and components for the UI, and a web browser. So, yeah, standards and protocols are there. And it would take a s*t-ton of work to implement them in a bespoke environment. But they are not "difficult" in the classic sense. If we had a completely different type of economy it might even be possible!

mark_l_watson 5y ago

I don’t really agree. I had a Xerox 1108 Lisp Machine in the 1980s and loved it, but special purpose Lisp hardware seems like a waste of effort. I set up an emulator for the 1108 last weekend, and yes, I really did enjoy the memories, and things ran an order of magnitude faster than on the 1108 in the 1980s. Then, I appreciated my M1 MacBook Pro running SBCL, LispWorks, Haskell, Clojure, and various Scheme languages - all with nice Emacs based dev setups. Life is really good on modern hardware.

lispm 5y ago
The 1108 wasn't really special purpose Lisp hardware. One could run other operating systems on it. What made it special purpose was the loaded microcode for the CPU. > Life is really good on modern hardware. Agreed: On modern CPUs. More support for the additional hardware features like GPUs, media processing engines and the neural network engines (see the M1 Pro/Max/Ultra) would be welcome.
- mark_l_watson 5y ago
  The best bet for getting GPU deep learning support, I use Anaconda/conda, using the Apple M1 channel. That said, I usually use my Linux GPU rig or Colab for deep learning.
mst 5y ago
I feel like a lot of posts like this are pining for the complete lisp machine -user environment- and overestimating how necessary/important the hardware architecture would be to getting back to that today. I can manage to context switch between different lisps fine but I do sometimes wonder in e.g. a slime+SBCL setup how much that context switching is costing me.

pbohun 5y ago

If were talking about wild dreams, I would like to see a modern Plan9-like operating system written in lisp. While the Plan9 mouse chording is cool (and could be kept), I would have everything also accessible via keyboard commands. 3 button mouse chording on a laptop trackpad is not fun.

mananaysiempre 5y ago
Executable-images-and-bytestreams (Research Unix, Plan 9) and everything-is-in-$LANGUAGE (Lisp machines, Emacs, Smalltalk, Oberon, Forth) environments seem largely contradictory to me, because much of the flexibility in Unix seems to come from the freedom to ignore as much structure in the data as you want to, while programming-language environments seem to derive their advantages from expressing the structure in as detailed a way as possible. (In particular, they really want to invent their own storage formats for everything.) I don’t have much of an idea about Inferno, but my superficial impression is it also mostly ends up as a single-language island. Which is annoying, because both of these approaches produce some really attractive results, so I’d very much like to learn about any attempts to reconcile them.
- zozbot234 5y ago
  "Expressing structure" is just a higher layer on simple bytestreams. Some historical operating systems only supported special-cased "file types" with hard-coded structure, but the *IX folks found out that the simple bytestream is enough.
pjmlp 5y ago
It used Limbo and was called Inferno.

ogogmad 5y ago

When the author talks about too many languages and libraries, I personally think he means the proliferation of Unix DSLs (some of which are Posix and some are not) like Make, Awk, Sed, BC, DC, shell-script dialects, Gnuplot (I know it's not Posix but it was widely used once), xargs, Vimscript, ELisp. Each of these has its own quirks and random limitations. Each of these makes Unix unnecessarily complicated and difficult to learn, and they don't even accomplish much that's impressive. I also think they make the editing experience worse, because they prevent the use of IDEs or highly featured REPLs like the ones general-purpose languages have. I imagine that a lot of this can be replaced with libraries for a general-purpose language like Python. In the case of Awk, BC and DC, Python's standard library does everything these do without their strange quirks. Gnuplot can be replaced with umpteen plotting libraries like Matplotlib. Shell-scripting can be done in a Python dialect like Xonsh. I don't know of a Python alternative to Make, but Make is a fairly perverse and ad-hoc language that looks ripe for being replaced by a library. I don't think a new operating system (however you define that) is necessary. I think you just swap out a lot of the crazy DSLs with one consistent general-purpose language. People will switch over when they want to accomplish things more easily (like me!). This is especially likely if you're not a SWE but you want to do file system automation anyway. The DSL-heavy approach is too Byzantine for such people (like me!). And it's mostly possible today.

eternityforest 5y ago
I wouldn't even say any of those make UNIX difficult to learn. 99% of people can be users and developers just fine without learning awk or sed or even make, if they don't do low level work. It can all be incrementally replaced over time, without starting over, just like how systemd and pipewire didn't need to totally start over. Make will probably need something more than just a library though, because it's gotta stay declarative. But the fact that make exists at all is kind of an issue. I think build and package management should be done in the language itself like non-C languages do. The other use of make is almost as a pseudo UI, just a standard place to put a list of actions you can do. Something like Ansible could replace that, in theory, or we could have some new "project control center" file with menus and inputs and settings.
- deleted 5y ago

eternityforest 5y ago

UNIX is fine. UNIX philosophy is an issue, along with C, and the fact that everything now is mobile and web based and the tools aren't well suited to offline/nonSaaS stuff yet. Linux is slowly becoming a standardized, integrated platform. I don't see why it can't be evolved to have all the main advantages of a LISP machine. I also don't see how that solves dependency management. No matter what, if you build against something and it changes, stuff breaks. That's the main issue with Linux. It also doesn't solve microservices being kinda hard and needing manual configuration specifically for the setup, rather than the one size fits all style of monolithic desktop software. That's an application architecture challenge. Nor does it solve cross-platform. Linux does have problems and could learn from LISP machines(Although I'd rather we have TypeScript machines or Python or something, LISP is pretty far from what I want a language to be, and is meant for creativity and expressiveness rather than Ada-like safety and boring hacker-repelling Java-like standardization). But a lot of issues go away if you pretend everything other than Debian and Red Hat don't exist.

agumonkey 5y ago
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.
- taeric 5y ago
  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?
  - agumonkey 5y ago
    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.

codr7 5y ago

The future is already here, but unfortunately it's programmed in elisp and still lacks a decent editor.

codr7 5y ago
Oh, come on; I love Emacs, and I admire RMS a lot. And I mean it, Emacs is as close to a Lisp Machine as you get in today's world.
ByteJockey 5y ago
Emacs has a great editor... The evil package.

DonHopkins 5y ago

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

mikewarot 5y ago

The key thing about those type of systems was the ability to reach down into the system and edit the code of the system currently in operation. Here's a demonstration of Symbolics Open Genera (TM) 2.0, demonstrated running in a virtual machine. It is noted by the author of the video in the first minute or so that even in emulation, it is much faster than the original machines. - https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible. The same was true of the Canon Cat, Hypercard, Ted Nelson's Xanadu project, Smalltalk, and a number of other early computing systems. The main feature common to all of these systems is that they all preserve context. In Genera, Oberon, Canon Cat, Hypercard, and SmallTalk the source was always available. (as far as I know). In Xanadu, the main functionality of the web was present, but it wouldn't allow the broken links (and lost context) that now plague the web. I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments. There's nothing stopping an open source project from taking elements of these existing systems and moving forward from that basis. It might be profitable to include ideas such as Coloring of the Source text to label intent, such as in ColorForth. Also, consider "Literate Programming" - Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code. You could also add the ability to store graphics and other data along with the source code. Of course, if you are required to run code you didn't write and don't trust, your operating system must provide means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model. Sorry it was a bit of a ramble, but this seemed to be a call for ideas, so I ran with it. PS: In the past, getting your vision of Computing required building a machine, and then getting it manufactured. Now it just requires that you make it work in a VM, Raspberry Pi, or web browser window. It is MUCH easier to try out and/or create alterative systems now that it has ever been in the past.

5y ago

reikonomusha 5y ago

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 remained one of the most powerful programming languages (I think it's true, but don't read into it too much). Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough. 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, interest, willpower, and/or money. Don't get me wrong, there are some Lisp programmers today developing superlative libraries and applications [1], but the Lisp population is thin on them. I'd guess that the number of publicly known, interesting (by some metric), and maintained applications or libraries that have sprung up in the past decade probably fits on one side of a 3"x5" index card. [2] Though I won't accuse the article's author of such, sometimes, I find, in a strange way, that pining for the Lisp machines of yore is actually a sort of mental gymnastic to absolve one for not having written anything interesting in Lisp, and to excuse one from ever being able to do so. [1] Just to cherry-pick a recent example, Kandria is a neat platformer developed entirely in Common Lisp by an indie game studio, with a demo shipping on Steam: https://store.steampowered.com/app/1261430/Kandria/ https://store.steampowered.com/app/1261430/Kandria/ [2] This doesn't mean there aren't enough foundational libraries, or "batteries", in Lisp. Though imperfect, this is by and large not an issue in 2022.

zozbot234 5y ago
> 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 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 boundaries in code and "programming in the large". So everything ends up being a bespoke solo-programmer project, there is no real shared development. You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall. This might explain much of their ongoing success.

chubot 5y ago

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-style coarse-grained composition. (Not just pipes -- think about a web server running behind nginx, or git reusing SSH and HTTP as transports.) You can also use link time composition. It takes some work but it's better than rewriting your Common Lisp code from scratch in Clojure. ----- Honest question: how do you communicate between two Lisp processes on two different machines? I know Clojure has EDN (which is sort of like JSON : JavaScript), but I haven't heard of the solutions for other Lisps. I wrote about this problem here: A Sketch of the Biggest Idea in Software Architecture http://www.oilshell.org/blog/2022/03/backlog-arch.html http://www.oilshell.org/blog/2022/03/backlog-arch.html > The lowest common denominator between a Common Lisp, Clojure, and Racket program is a Bourne shell script (and eventually an Oil script). I'll definitely update it if there's something I'm missing. I would say the design of Unix is "rotting", but the answer is to IMPROVE Unix. Not dream of clean slate designs that will never be deployed. Plus this post doesn't actually propose anything. If you actually start trying to build your Lisp machine, I believe you will run into dozens of reasons why it's not a good idea.

armitron 5y ago
The canonical Lisps still widely used today are Common Lisp, Scheme and Emacs Lisp. They all belong in the same family, and syntax / semantics are close. Porting code from Scheme to Common Lisp can be a lot easier than going from Python 2 to Python 3. Clojure is something else entirely which is why a lot of people don't consider it a Lisp. > Honest question: how do you communicate between two Lisp processes on two different machines? If you want to use built-in object serialization, there is print and read.
- iak8god 5y ago
  > Common Lisp, Scheme and Emacs Lisp... all belong in the same family Could you say more about what you mean by this? Is there another family of Lisps that excludes these three? I've met people who make a big deal about lisp-1 vs lisp-2 (https://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2 https://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2), and which is the right way to be a Lisp, but I think maybe those people just enjoy being pedantic.

fferen 5y ago

I have had the same thoughts before and come to a similar conclusion. I believe it's not about the language. It's about the features: runtime code editing, single address space, program interoperability. Lisp could be replaced with C or anything else. Unfortunately this is the hard part. No one is about to design completely new hardware or architecture for this, as it makes no economic sense. So we just get a shiny new language every few years, and nothing really changes.

nanochad 5y ago

> You could open up system functions in the editor, modify and compile them while the machine was running. Why would you want to do that other than hot patching a system that can't go down? Testing new changes requires more time than rebooting. If you just want to test simple changes, most debuggers can do that. > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. And with a single address space you have win9x security. > A modern UNIX system isn’t self-contained. I have 4 UNIX systems on my desk (Desktop, laptop, iPhone, iPad) I’m contentiously using the cloud (iCloud for photos, GitHub for text files, Dropbox for everything else) to sync files between these machines. The cloud is just a workaround for UNIX’s self-contained nature This is just your use habbits. Nothing is stopping you from using NFS or SSHS. Someone who feels the need to use iCloud for whatever trivial convenience it provides is unlikely to benefit from a Lisp machine's ability to edit code on the live system. > Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems. We need a replacement, something that can be built for the modern world using technologies that are clean, secure, and extendable The same thing will happen with any OS given enough time. Lisp is also not secure. It's prone to side channel and eval bugs. > eliminate memory leaks and questions of type safety, Lisp is not type safe.

reikonomusha 5y ago
> Lisp is not type safe. It is type safe. While Lisp is not statically typed, its typing discipline is strong: operations performed on incompatible types signal recoverable errors.
- deleted 5y ago
  [deleted]
- Too 5y ago
  Crashing at runtime, recoverable or not, is usually not what people mean when they say type safe. Spare me the static vs strong academia. Type safe when spoken, in practical every day terms, normally means enforced at compile time with IDE autocompletion support, usually implying static typing.

mumblemumble 5y ago

> With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack This seems like the kind of goal that's only palatable to a very few people nowadays. Specifically, the people who want to use that language, toolchain, and libraries, and nothing else. These days, I don't think that that's ever going to allow for enough of a community to support more than a relatively self-contained hobbyist scene. Which there's absolutely nothing wrong with that; personally I wish there were more compelling tinkering-oriented platforms; I'm a little meh on Unix too. But the article seems to be advocating rather loftier ambitions.

throw10920 5y ago

I think that, while the idea is solid (Unix is poorly-designed and we should have better) some of the specific ideas mentioned are lacking: > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. No! Bad! We have enough problems securing software on separate VMs running on the same metal, single address spaces are completely out of the question until someone manages to build a feasible trusted compiler system. > Then we add a gazillion programming languages, VMs, Containers, and a million other things, UNIX is a bloated mess of workaround for its own problems. A lot of these problems could happen with a Lisp machine - you could have a billion different Lisps, for instance (although, to be fair, with better (i.e. non-Unix) OS design you wouldn't need containers). > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. This is partially true, but a lot of the complexity in modern software doesn't come from Unix, but just...bad design decisions. Webtech doesn't really care whether it's running on Windows or Unix, after all. Also, high-level CPUs are a bad idea: http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html I think the good in this post is along the lines of: text bad, typed IPC good, runtime-aware OS good, standardized VMs good, interactive systems (Lispy stuff, Jupyter) > batch-processing systems (Unix, C).

amelius 5y ago

The main problem with Unix right now is security / permission control. Unix was built from the perspective that users potentially don't trust each other, but users all magically trust the applications that are run. In the age of the internet, this doesn't hold anymore, and we need strong permission control.

klodolph 5y ago

I agree that we need more operating systems, but... > These machines used specialized hardware and microcode to optimize for the lisp environments (Because of microcode you could run UNIX and the Lisp OS at the same time). This is a dead end in the history of CPU design. Processors are all vaguely similar these days. Your CPU is built around ALUs which typically take one or two inputs, produce one output. Around that, you build some logic for shuttling these inputs and outputs to and from registers, or in some cases, to and from memory. The core here, the ALUs, have gotten more and more sophisticated over the years, but the wiring on the outside has remained fairly modest relative to its excesses back in the day. I'd say that the lesson here is simple: rather than add complicated operations to make your high-level language faster, do the complicated stuff in software... which gives you a lot more flexibility, and the combined hardware-software stack ends up being faster and cheaper anyway. > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. I can understand where this notion is coming from... but practically speaking, switching to Lisp doesn't eliminate memory leaks or questions of type safety or binary exploits. Even with an idealized version of Lisp, I don't think these problems could possibly go away. Neither garbage collection nor systems like Rust really "solve" memory leaks, they just provide strategies to make memory leaks less common. The same thing applies to type safety. You'd have to define "type safety" very narrowly to say that Lisp solves all type safety problems. Again, I can understand where the author comes from--it's kind of an intuitive notion of type safety, that you don't end up operating on an incorrectly typed pointer, or something like that. But the notion of type safety is much more broad than that these days. And the C/Unix strategy is actually pretty good, too, when it works--contain memory leaks within a process, then terminate the process.

VLM 5y ago

The problem with language wars is the people whom cannot be trusted with pointers, also cannot be trusted with lambdas or recursion. The name of the game has always been to avoid directly insulting the bad programmers by making fun of the languages they use. Bad programmers have clustered in several languages over the course of my long career. Mostly they are the easiest most expressive languages, which would superficially seem to be an advantage, however they make it easy to express amazingly bad ideas. The harder to express languages require more work to express a bad idea thus somewhat filtering them out of that language's pool. People whom don't understand the game think the game will be won if the bad programmers would have access to better languages for the first time in history. Despite the idea being decades old its always presented as a new idea. There's an authoritarian streak where if only we could remove access to the inferior languages then they'd have to use the better languages and we'd have better code. However you can't force people to not use inferior tools and you can't force them to learn to use better tools. The graph of easy to write and code goodness is interesting and nonlinear. You can express very complicated ideas in lisp easier than in vb6 or perl or interpreted basic or spaghetti fortran. However, you can express very bad ideas easier in a "bad" language, so it accumulates interesting authors. There is always a crossover point where an intermediate complexity idea is equally hard to express in a simple language or a complex language. Frankly most of IT needs are and always will be below that point. So its counterproductive to demand difficult language for simple tasks, everyone laughs at "Enterprise Java Hello World" that is 100K lines of enterprise patterns. Expressing ideas in computer languages is much like expressing ideas in everyday language. Some esoteric philosophy texts require a VERY large precise complicated hard to use and hard to learn vocabulary. Road signs do not. For in between jobs, trying to use a minimum number of language vocabulary words and lexical complexity would be wise. It would be a fools errand to try to cut half the vocab words from street signs to "make driving safer", or an equally bad idea to force all road signs to be expressed as Shakespearean sonnets. The real world counterpart of "Enterprise Java Hello World" would be forcing the "No U Turn" street sign to be in the form of a Shakespearean sonnet. The difficulty of tasks is usually under a power law, so its nice that we have lisp, but usually a bad idea to use lisp.

peter303 5y ago

Hardware LISP machines didnt survive the 1980s because you could emulate LISP on a general purpose CPU faster than a special machine. That is because faster new general purpose CPUs cane out every year or so, while it took 3-5 years for the next special purpose CPU.

maydup-nem 5y ago

> genera eh, if it's gui is anything like clim which was based off of it, no thank you big time

karmakaze 5y ago

The trend seems to be toward statically-typed languages, with the exception of the adoption of Python being used for data. I also prefer having more problems being found before deploying and running on production data. Dynamic typing is great for prototyping, early development, and for small teams. If your definition of success is greater than that I would choose differently, or port at a good time early on. And if someone were to ask me to join a company using lisp, I would hope that it's Clojure, though arguably not a Lisp, is better it that it will vary less between usages. This gives it a better chance of a growing ecosystem.

xedrac 5y ago

> They were programmed in lisp the whole way down and could be run code interpreted for convenience or compiled to microcode for efficiency. You could open up system functions in the editor, modify and compile them while the machine was running. Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. So this is basically expanding Emacs to actually be the operating system. There's definitely some allure to it. Awhile back, I was hacking on the Lem editor for Common Lisp, using the Lem editor itself. It was great until I made a mistake in some code that restricted my ability to edit the code, sort of like performing brain surgery on my self and snipping a nerve that controlled my arms. It was amazing to have that immediate feedback loop, but in a world that is striving to find new ways to minimize human error, I'm just not sure it'd hold up.

mst 5y ago
Pervasive rollback in a sufficiently compartmentalised bit of the UI that it's really hard to break would seem like the ideal theoretical solution but practically really quite tricky to introduce to an environment retroactively. (I've been pondering this problem recently for something I'm working on an introducing it from the ground up is bending my brain hard enough, others may be better at it though ;)

ogogmad 5y ago

I've started using Mathematica recently. I quite like it: I've used Sympy before, which was good, but nowhere near as "good" as Mathematica. How does it compare to the Lisp Machine operating systems? There's some vague resemblance to Lisp in treating symbols as a basic type of object. In the Mathematica use-case, these symbolic values are used to stand for algebraic variables or unknowns. Undeclared variables by default have symbolic type, with their own names being their values. (I know that other CASes do similar things here). Also, algebraic manipulations produce expressions which double as Mathematica code, which resembles the meta-programming features of Lisp. There's even glimpses of reactive programming in the way you construct interactive plots. I know this is "uncouth" because it's commercial software, but Mathematica is one of the most interesting programs I've ever used. [edit] Might something like this be the future?

abecedarius 5y ago

If I'd like to try the emulated Lisp Machine linked to (https://tumbleweed.nu/lm-3/ https://tumbleweed.nu/lm-3/), is there a straightforward getting-started doc? The page lists multiple links for each of the simulator, the bootstrap, the documentation, and umbrella projects ("to make it easier setting up", though for this one it's only a binary choice). This is not counting the multiple system sources, since only one is recommended right now. This suggests it's too much work for now if you're just curious, but it'd be great to be wrong.

charcircuit 5y ago

IMO the biggest difference is that that there is no longer a difference between binaries and libraries. Everything is a library. In UNIX there are a bunch of utilities which you just can't use from C. Also the idea of just passing data structures around instead of using a pipe passing streams of characters around is an improvement since there is no longer the need to serialize / deserialive it.

daly 5y ago

Who cares if Lisp is popular? The "lisp epiphany" is real. Either you "get it" or "you don't". I've been writing lisp programs for 50 years. I've been paid to program in 60 different languages but nothing compares with lisp. There is an intellectual "distance" between a problem and its machine solution. I call this the "impedence problem". Lisp lets you think at the most abstract and write to the most specific. Writing changed the world. But if you give most people a blank piece of paper they don't know what to do with such freedom. Lisp is the "blank piece of paper" of programming languages. Everything, literally everything, comes from you. I loved my Symbolics machine. It was the closest expression of a "thinking platform" I've ever used. IDEs are horrible for thinking, ever interrupting at every keystroke. Lisp isn't "popular" because it provides a "thinking platform" you can shape to your thoughts. Lisp will never be popular. The reason should be obvious.

mbrodersen 5y ago
A number of Lisp fans seems to care. That’s why we regularly see articles on HN trying to convince other developers to use Lisp. It has been going on for years. Article after article written by frustrated Lisp fans, not understanding why the language they love is not mainstream. Often making bizarre claims about non-Lisp developers not being smart enough to “get” Lisp or whatever. Not having a clue that most developers care about a lot more than just the programming language. The best way to show the “power” of Lisp is to develop commercially successful software using it. That will do way more to convince smart developers to try out Lisp than writing yet another Lisp article trying to “sell” Lisp.
- daly 5y ago
  For the record, I made (and make) no claims about "non-Lisp developers not being smart enough". My claim is that Lisp is perfect for thinking about a new idea or a new approach. For example, I implemented a program that merged Expert Systems and Knowledge Representation into a single system (KROPS) that allowed a domain expert to express their knowledge as rules or as facts. Anything the system learned by either method could be expressed in either representation. Thus, the two representations were "unified". Another effort involved Human-Robot Cooperation to change a car tire (TIRES). The system could interact with the human through pseudo-natural language, learn rules dynamically, and expand its knowledge base of the current situation in real time. So the system self-modifies and learns through human interaction on the task. Both of these systems required self-modifying code which is rather more difficult to do in other languages. In Lisp this is trivial. As for commercial sales witness: Axiom, a 1.2 million line Computer Algebra program written in Common Lisp, was sold commercially by the Numerical Algorithms Group. YESOPS, an IBM Expert System program implemented in Common Lisp, was sold commercially.

nine_k 5y ago

> With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Oh man, wat? I love lisp as much as the next guy. But you absolutely can have library mess, memory leaks, and millions of lines of code using a Lisp. You arguably can have a "multi-language" mess, too, because Lisp gives you wonderful tools to create DSLs; I'd say creating a language that fits your needs, and then using it, is the right way to use Lisp. I use Emacs daily, and see how an all-Lisp environment can make for a good, productive interactive experience. More efforts in this area would be quite welcome, but this is a shell, not a kernel. I still suppose that systems software, and especially the key parts of an OS, need a language more like Rust than like Lisp, with a good affinity to raw hardware, and a ton of static guarantees.

yawaramin 5y ago

The Lisp machine of today is MirageOS: https://mirage.io/ https://mirage.io/ A unikernel that throws out the legacy of Unix and starts fresh to build a library operating system, it's exactly what OP describes: > With lisp machines, we can cut out the complicated multi-language, multi library mess from the stack, eliminate memory leaks and questions of type safety, binary exploits, and millions of lines of sheer complexity that clog up modern computers. Even better, Mirage is programmed in OCaml, which is basically a statically-typed facade over Lisp (or Scheme). That's the modern Lisp machine of today. It even takes care of security nightmares like this: > Everything worked in a single address space, programs could talk to each other in ways operating systems of today couldn’t dream of. Because in the Mirage model is program is a separate OS image and they can communicate only over defined service interfaces.