I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quicklisp has made strides her).
That is to say, you could probably write ansible/puppet in common lisp - but I'm not sure if you should.
Certain special programs, like unison (in ocaml)[1] combine breaking new ground, doing something a little complicated - and justify the use of a powerful language. Other examples might be pandoc (haskell) or gnu guix (scheme software/Os manager).
Perhaps it's wrong to throw scheme under the bus, for common lisp being too full of features.
But my (admittedly superficial) impression is that even "pragmatic" schemes tend to be difficult to integrate as system glue; that means both on a single platform (use for scripting, piping files, writing config files, start/stop services - Running Os commands) and as cross-platform (either distribution of artifacts for different systems, like an exe for Windows and elf binaries for Linux and bsds - or readily available run-times that work well on multiple platforms).
It may well be that many of these issues are fixed today - but the impression that sbcl is a poor fit for a system language for writing parts that are easy to integrate well remain. Both if you want a deb/msi package of a gui app, and if you want to drop some binaries in /usr/local/bin to call snippets of code that work well with the shell.
[ed: What is funny/sad is that java kept almost everything that was bad with lisp/smalltalk, and very few of the really good parts. But they introduced a more familiar api for files, streams etc - and managed to push for the jvm to be installed everywhere.]
> 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.
I think lisp did (to a lesser extent still do) suffer from the "whole system syndrome" that also affected Smalltalk; I'm still not sure that I'd find it comfortable to marry small lisp programs with a shell pipeline, or convenient to work with sockets, files or even databases in a familiar way from within common lisp. Nor would i know how to easily share such code (although quicklisp has made strides her).
That is to say, you could probably write ansible/puppet in common lisp - but I'm not sure if you should.
Certain special programs, like unison (in ocaml)[1] combine breaking new ground, doing something a little complicated - and justify the use of a powerful language. Other examples might be pandoc (haskell) or gnu guix (scheme software/Os manager).
Perhaps it's wrong to throw scheme under the bus, for common lisp being too full of features.
But my (admittedly superficial) impression is that even "pragmatic" schemes tend to be difficult to integrate as system glue; that means both on a single platform (use for scripting, piping files, writing config files, start/stop services - Running Os commands) and as cross-platform (either distribution of artifacts for different systems, like an exe for Windows and elf binaries for Linux and bsds - or readily available run-times that work well on multiple platforms).
It may well be that many of these issues are fixed today - but the impression that sbcl is a poor fit for a system language for writing parts that are easy to integrate well remain. Both if you want a deb/msi package of a gui app, and if you want to drop some binaries in /usr/local/bin to call snippets of code that work well with the shell.
[ed: What is funny/sad is that java kept almost everything that was bad with lisp/smalltalk, and very few of the really good parts. But they introduced a more familiar api for files, streams etc - and managed to push for the jvm to be installed everywhere.]
[0] http://www.cis.upenn.edu/~bcpierce/unison/index.html