> I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome
There are a bunch of problems of Lisp for systems/application programming:
* dynamic typing and dealing with runtime errors
* garbage collection vs. real-time response
* amount of memory used is usually higher for GCed systems
* interoperability with C code and code in other languages
* abstraction mismatch between C code and Lisp code.
* the need for a foreign function interface to inter-operate with C code
* the integration with C++
* the minimum size of a program and how many programs can be started
* sharing much of the runtime and library
When people started to write lots of Lisp code (80s) then the question of delivery came up. The were a bunch of responses to that:
* don't run systems and applications in Lisp,
for example rewrite the Lisp applications into C++
(smaller footprint, possibly faster execution, ...)
* develop new Lisp-like programming languages,
but which are more efficient to implement.
Example: Apple's Dylan or see Dynace ( https://github.com/blakemcbride/Dynace )
* develop special Lisp implementations which address
the above issues and are specialized in application
delivery
Let's look at the latter approach.
Germany had for example the Apply project which for example created the CLICC compiler ( https://www.informatik.uni-kiel.de/~wg/clicc.html ). CLICC is a whole-program compiler for a restricted subset of Common Lisp. mocl is based on CLICC and was/is a commercial CL compiler for macOS X, Android and iOS.
There are a bunch of similar compilers (Thinlisp is one https://www.cliki.net/ThinLisp ). Many years ago Oracle also bought an Lisp compiler (which was very expensive for users, IIRC in the range of $100k), which actually generated 'maintainable' C code.
Another interesting system is WCL: https://github.com/wadehennessey/wcl
WCL allows one to use Common Lisp as a shared library (mostly). Each Lisp application starts with tiny RAM usage and tiny application size. This allows to run possibly hundreds of smallish Lisp applications at the same time.
Eclipse was a Common Lisp which has a direct integration in C and compilation to C, which made something like a Foreign Function interface unnecessary: https://github.com/blakemcbride/eclipse-lisp
Generally these tools are often 'old', not widely used and not many applications have been written with them.
I was rather excited a while back when discovered iso lisp/ standard lisp/EU lisp. A few newer than common lisp standards that tried to extract a sane subset of clos and some other cl features (but trying to avoid cruft and overlapping functionality). Unfortunately, there didn't appear to be many viable implementations; one French one that was commercially licensed, and. Not much else that I found at a time.
But it looked a lot like the good parts of cl (pragmatic standard) with the good parts of scheme (small, but not minimal).
At least on paper. I guess the fact that there's a lot of viable cl systems and not really any iso lisp systems is telling...
ISLISP was defined/implemented mostly outside of the US (exception, Kent Pitman, IIRC) and mostly by work from Europe&Japan. But that funding dried up long ago. One of its purposes was to have a Lisp standard outside of the USA, not controlled by US standards bodies and US vendors/users.
It's too much like Common Lisp and the standard itself is not bringing exciting stuff. It's nice in itself, but not really needed.
Can't remember anything in the language which really addresses the delivery topic - though I've never read the spec in depth.
There are a bunch of problems of Lisp for systems/application programming:
When people started to write lots of Lisp code (80s) then the question of delivery came up. The were a bunch of responses to that: Let's look at the latter approach.Germany had for example the Apply project which for example created the CLICC compiler ( https://www.informatik.uni-kiel.de/~wg/clicc.html ). CLICC is a whole-program compiler for a restricted subset of Common Lisp. mocl is based on CLICC and was/is a commercial CL compiler for macOS X, Android and iOS.
There are a bunch of similar compilers (Thinlisp is one https://www.cliki.net/ThinLisp ). Many years ago Oracle also bought an Lisp compiler (which was very expensive for users, IIRC in the range of $100k), which actually generated 'maintainable' C code.
Another interesting system is WCL: https://github.com/wadehennessey/wcl WCL allows one to use Common Lisp as a shared library (mostly). Each Lisp application starts with tiny RAM usage and tiny application size. This allows to run possibly hundreds of smallish Lisp applications at the same time.
Eclipse was a Common Lisp which has a direct integration in C and compilation to C, which made something like a Foreign Function interface unnecessary: https://github.com/blakemcbride/eclipse-lisp
Generally these tools are often 'old', not widely used and not many applications have been written with them.