Does this roughly offer the same benefits that the old lisp machines provided?
I've never used one, but have heard people rave about how productive they were on them.
I've never used one, but have heard people rave about how productive they were on them.
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.
http://metamodular.com/lispos.pdf
This is a really good paper, recommended lecture.
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.
Cool is synergistic with other qualities. On top of that, everything is contextual. Does anyone know of any particularly cool ClojureScript electron apps?
LightTable was cool.
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.
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).
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.
What was this?
The hardware was not powerful - for example they had very little RAM.
But an emulator was developed for SPARC/UNIX and X86/Linux. Called Medley.
When I worked at PARC I mostly used Interlisp, but I did use all those environments.
WANT!!!
Please write an article about it and post a link to it here.
https://github.com/rongarret/ergolib
In particular:
https://github.com/rongarret/ergolib/tree/master/web
The heavy lifting is all done by Hunchentoot:
I usually run nginx as a front-end because it's faster at serving static content and it provides some security benefits, but it's not necessary.
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 wasn’t aware of Hunchentoot.
https://github.com/fukamachi/caveman/blob/master/README.mark...
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.
I'm not so sure about the actual intentions behind the development beyond "experimenting".
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?
A few years later I got a Xerox 1108 Lisp Machine at work, a cheaper alternative to your Symbolics, but very nice.
(I particularly like: "I strongly encourage you not to actually use this to learn Lisp!" :-)
At least in part, because of storage and memory constrained things like home routers.
[1] https://news.ycombinator.com/item?id=1878220
[2] https://common-lisp.net/project/mcclim/excite.html
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.
https://en.wikipedia.org/wiki/BioBIKE
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.