Some thought why LISP OSes can't compete:
1.The functions 'eval' and 'read' are insecure where any user input is expected. When LITHPers mentiong 'gets' and 'printf' vulnerabilities its doubly ironic:
LISP doesn't require any complicated exploits, the LISP computation model with its runtime interpretation will happily start overwriting its own code when requested.
2.LISP garbage collection and real-time computing are mutually exclusive. Its required that garbage collection would be replaced by manual allocation/management(which LITHPers despise) or code be rewritten for constant/static allocation(which LITHP computation model makes insanely difficult).
3.LISP doesn't actually allow low-level access in the same manner as inline assembler of C does. The high-level nature of LISP introduce unexpected large overhead where C translates to few opcodes. This means drivers in pure LISP cannot compete.
4.LISP isn't suited for real-world tasks where resources are scarce, due its generous "runtime allocation"/GC it cannot run on
microcontrollers, low-memory systems and Internet-of-things devices. The minimum requirements for LISP OS seem to be much higher than C.
5.Hardware optimizations for LISP don't exist. The use-case for LISP is fairly narrow, so introducing 'LISP machine' features doesn't make economic sense for manufacturers.
6.LISP is hard to optimize(with few exceptions like Stalin Scheme):
LISP enables combinatorial explosion of complexity where functions, lambdas and macros stacking around create layers of dead code and cruft that LISP compilers cannot remove due various deficiencies.
The purpose of most LISP optimizations is to remove 'low-hanging fruit'
to run the parens soup at acceptable speed(or LISP weenies lose interest). There is much less effort at analyzing and low-level optimization than C, and LISPers viewing assembler as low-level 'implementation detail' and 'machine-specific code'.
Thats why Scheme-to-C compilers exist: LISPers outsource optimization of their C interpreter output, hoping the resulting complex
C constructs will be somehow 'optimized down' by C compiler.
7.LISP is hard to program with, especially when low-level interface
is required. What do you expect with language where loops are not
a native construct and memory pointers considered an anathema to computation model. Despite claims of x100 productivity(which usually involves prototyping some academic shitcode heap), LISPers
have to invent entire new DSL(Domain Specific Languages) each time
they encounter a new problem(fortunately LISP is flexible to abstract that out). These 'problems' are somehow solved by normal
languages without involving heavy machinery of interpreters and spoecialized syntax.
8.Specific language deficiencies:
LISP requires mentally interpreting data as code.
Due its nature(no comma separated arglists) as 'opportunistic interpreter' LISP needs careful
attention, so that any data wouldn't leak to arguments.
LISP treats everything as semantic soup of tokens(parens soup), where function names, arguments to these functions and data are treated dependent on their context and position, wholly determined by parens structure, which rivals in nesting depth most complex C expressions that Cdecl can unravel(btw try https://cdecl.org/ ).