>Does this roughly offer the same benefits that the old lisp machines provided?
This project is cool, but, in short, no.
Please take a look at this paper, which answers the questions of which benefits could be obtained with a Lisp OS. This goes regardless of if such OS has or does not has a nice IDE.
I expect this will be a fairly controversial comment, so I want to preface this by saying that I'm a big Lisp fan (just look at my handle). Lisp is my favorite programming language. I've been using it for nearly forty years. My first Lisp was P-Lisp on an Apple II in 1980. And I worked on Symbolics Lisp machines in the 1990s. They were very cool, but there's a reason they failed: general-purpose computing is infrastructure, and the economics of infrastructure are such that having a single standard is the most economical solution, even if that standard is sub-optimal. For better or worse, the standard for general-purpose computing is the C machine.
Because it's general-purpose you certainly can run Lisp on a C machine (just as you could run C on a Lisp machine). You can even do this at the system level. But Lisp will always be at a disadvantage because the hardware is optimized for C. Because of this, C will always win at the system level because at that level performance matters.
But that in and of itself is not the determining factor. The determining factor is the infrastructure that has grown up around the C machine in the last few decades. There is an enormous amount of work that has gone into building compilers, network stacks, data interchange formats, libraries, etc. etc. and they are all optimized for C. For Lisp to be competitive at the system level, nearly all of this infrastructure would have to be re-created, and that is not going to happen. Even with the enormous productivity advantages that Lisp has over C (and they really are enormous) this is not enough to overcome the economic advantages that C has by virtue of being the entrenched standard.
The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level. I use Clozure Common Lisp. It has an Objective-C bridge, so I can call ObjC functions as if they were Lisp functions. There is no reason for me to know or care that these functions are actually written in C (except insofar as I have to be a little bit careful about memory management when I call C functions from Lisp) and so using Lisp in this way still gives me a huge lever that is economically viable even in today's world. I have web servers in production running in CCL on Linux, and it's a huge win. I can spin up a new web app on AWS in just a few minutes from a standing start. It's a Lisp machine, but at the application level, not the system level. My kernel (Linux) and web front end (nginx) are written in C, but that doesn't impact me at all because they are written by someone else. I just treat them as black boxes.
I don't want to denigrate ChrysaLisp in any way. It's tremendously cool. But cool is not enough to win in the real world.
[UPDATE] ChrysaLisp is actually doing the Right Thing with respect to its GUI by using a C-library (SDL). But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand. There are already many Lisps that can run on bare metal (ECL was specifically designed for that). None of them have succeeding in displacing C, and I believe none ever will because the economic hurdles are insurmountable.
I basically agree with everything you wrote, but for two subsidiary points.
1 - it's a phenomenal development platform. I have on multiple occasions built large systems later deployed, for the reasons you discussed, via C ports. It didn't nullify the work done in Lisp: we learned a lot, and quickly; were able to do quick experiments, etc. But ultimately we needed to join the wider world.
2 - there is / has been a sea change in the software deployment model; it includes web browsers, even more rapid and more flexible development etc. Clojure is a good example and consequence of this change. It's quite possible that the circumstances that led to Lisps decline (though was it really ever "mainstream?") may swing the tide the other way. E.g. "Rapid development and realtime deployment of lisp-based microservices" to agglomerate some popular buzzwords.
FWIW: I was a developer from MACLISP to MIT CADRS, various Symbolics machines (at one point I had two 36xx machines on my desk with color monitors attached) and various D machines. Right now I'm doing my development in C++ though.
Alto descendants from PARC, ranging in size (not year built) from the Dandelion (AKA Xerox Star) Dolphin and Dorado (an ECL logic screamer). You could boot them into standalone environments like Smalltalk, Interlisp-D, and Cedar/Mesa). By “standalone” I mean you loaded specific microcode into the machine and then booted an environment in which everything: OS, GUI, file system etc was written in that environment.
When I worked at PARC I mostly used Interlisp, but I did use all those environments.
> The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level.
Interestingly, another current top post on HN is HPAT - A compiler-based framework for big data in Python (https://news.ycombinator.com/item?id=15466829). This replaces C level languages with something like Python for a specific domain. That could be somewhere lisp wins as well?
I'd be more optimistic. Tools are better today. Machines are faster. Re-inventing the wheel isn't nearly as costly or involved as it had been. Look at how much has already been re-done and re-tooled in JavaScript. The same process is being replayed in Rust, Go, and Clojure as we speak.
As for the C machines, Moore's law already has a foot in the grave. Ten years ago, we would have just assembly-optimized any inner-loop bottlenecks and assumed that in a few more months Intel would get us the rest of the way there. Now I'm seeing more and more being pushed off into GPUs and custom ASICs. With clock speeds topped-out, the mainframe approach of pushing more into the hardware grows increasingly attractive.
That, and so much is written in other garbage-collected languages today that LISP-friendly hardware could benefit Python/C#/Java/PHP programs as much as it would LISP ones.
Are you interested in a web server for Common Lisp? We have had these for years, for example Hunchentoot. This is a standalone web server, doesn't need to be connected to any other server. No need for Apache.
Take a look at the "lack" and "Clack" packages for Common Lisp by Eitaro Fukamachi; they provide a layer of abstraction so your program thinks it has a web server, but in production it can be run by various Lisp web servers (i.e. Hunchentoot) without changes to your code.
I’m interested in running Lisp web applications inside of Apache web server, for example with mod_lisp or through cgi-bin, although I’d prefer the former, simply because Apache has modules for many other functions as well. Unfortunately, what documentation there is on mod_lisp isn’t step by step to get from point A to point B.
Take a look at Clack. (Caveman2 is a web framework for Common Lisp, by Eitaro ("8arrow") Fukamachi; another recent web framework is Lucerne, by Fernando Borretti ("eudoxia0"))
Caveman is built on top of Clack and I think Lucerne is, too.
Another good option is Ningle, by Eitaro, which is a really mínimal minimal set of functions and macros to create a web application. Runs on top of Clack as well.
But is winning in the real world really important? OPs question was after all "Does this roughly offer the same benefits that the old lisp machines provided", and as LISP machines did not really win in the real world the first time around, I don't think that is really prerequisite for bringing the benefits of a LISP machine.
Productivity measured against what quality metric? For getting code written fast, Lisp is pretty good. For writing an operating system on which you can run a web server that will be competitive with nginx on Linux in terms of requests-per-second, probably not so much.
Maturity? Gets out of the way? Advanced documentation/learning material? Wealth of prior work solutions to common patterns? It's not so hard to guess what any developer's productivity is hinged on.
I asked because many people that used them called out the machines as being very productive...above and beyond lisp. Another comment here suggests it might have been CLIM.
Ah. A lot of that was because the LispMs had really good IDEs at a time when IDEs were all but unheard of. This was possible because it's a lot easier to write an IDE for Lisp than for C. But all that can be re-created at the application level (obviously because IDEs are applications). There's no need for a system-level Lisp to get that win.
In fact, Clozure Common Lisp is a perfect example. It provides (IMHO) 80-90% of the productivity advantages of a LispM when you run it on a Mac (because the IDE is Mac-specific).
It's tremendously cool. But cool is not enough to win in the real world.
Cool is synergistic with other qualities. On top of that, everything is contextual. Does anyone know of any particularly cool ClojureScript electron apps?
The reason why Lisp machines failed is because, with compiler and CPU architecture improvements, "C machines" started trouncing Lisp machines in terms of performance, even at running Lisp code. Symbolics's last product was Genera running on a "C machine" architecture. This doesn't obviate your statements about library support, but I don't believe the dream of "Lisp from bare metal on up" is worth abandoning entirely.
In classical OS (Linux, Windows, Mac) the developer is responsible for seemless integration (in KDE or MS Office for instance). It is easy to break design guidelines here which causes ugly interoperation, or even lack of interoperation.
> But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand.
I'm not so sure about the actual intentions behind the development beyond "experimenting".
And there's absolutely nothing wrong with that. But the question I was responding to was about the potential to use this as a starting point for re-creating the productivity advantages of the Lisp machine.
How far do you think is the next local maximum from the current C one? I'm asking in terms of power of displacement of the status quo. Do you think it involves Lisp in one way or another?
The Lisp and C worlds are already kind of converging in languages like Python, Swift, Go and others. Unfortunately, as far as predicting what will happen, I can only quote the late, great Carl Sagan and say that prophecy is a lost art.
I've never used one, but have heard people rave about how productive they were on them.