> 1) performance costs

Keep in mind that a compiler like SBCL will put Lisp performancewise in the range of other statically compiled language/implementations.

> 2) puts steep memory requirements on top of performance costs

Such that the Dylan IDE ( https://news.ycombinator.com/item?id=14478942 ) written in Macintosh Common Lisp needed 20 MB RAM. Steep memory requirements! Current Lisp implementations run nicely on a first-gen Raspberry Pi.

Lisp fought with memory efficiency in the 80s (the Lisp Machine operating systems ran in 20 MB RAM + 100MB virtual memory -> which were 4 MWords RAM of 40bit memory), but hasn't grown much since then. The jump to 64bit implementations has brought some size increase. But the size varies widely between large machine code (say with SBCL), space efficient byte code implementations (CLISP) and tiny executables created by whole-program compilers like mocl.

> 4) Huge runtime which is embedded in every executable, that makes it less competitive with scripting languages

If you want to compete with 'scripting languages', then just don't include the runtime. You can use many Lisp implementations just like scripting languages.

> Lisp requires eval() and runtime interpretation which other languages optimize out and replace with fixed code paths

If a compiler is used (say: SBCL, ECL, LispWorks, GCL, CCL, Allegro CL, mocl, ...) , then Lisp does not require runtime interpretation.

> some external programs called "tree shakers" remove the lisp's runtime

They don't. Treeshakers remove unused code and data. Parts of the runtime are still there.

> 5) Any piece of data can be potentially executed at runtime

If you remove the compiler & interpreter from the executable, that can't happen. See for example the LispWorks documentation on 'Delivery':

http://www.lispworks.com/documentation/lw70/DV/html/delivery...

> since lisp code/data are intermingled.

Not necessarily. Code in compiled Lisp implementations is machine code. If all fails, you can always compile Common Lisp to C code using GCL, ECL, MKCL, mocl, CLASP (C++).

> Lisp is so far removed from any concept of safety it even allows the programs to be modified at runtime

Only if you include an interpreter.

Actually one of the nice features of many Lisp implementations is that usually all data is tagged and that Lisp code checks applicability at runtime, incl. array/string/vector bounds checks...

>Keep in mind that a compiler like SBCL will put Lisp performancewise in the range

Simple short benchmarks don't show a complete picture of the language, since they're easy to optimize

>written in Macintosh Common Lisp needed 20 MB RAM

At the time when computers had 32/64 MB of RAM.

>. You can use many Lisp implementations just like scripting languages. >If a compiler is used (say: SBCL, ECL, LispWorks, GCL, CCL, Allegro CL, mocl, ...) , then Lisp does not require runtime interpretation. >Only if you include an interpreter.

So which one is it?

>Treeshakers remove unused code and data. Parts of the runtime are still there.

Huh, What kind of unused code and data is there in a 25MB hello world? https://web.archive.org/web/20090324024745/http://mbishop.es...

>If all fails, you can always compile Common Lisp to C code

Compiling to C doesn't improve safety of Lisp. As a C programmer, "Compiling to verbose cryptic C" doesn't sell me as a feature, more like a potential security threat.

> Simple short benchmarks don't show a complete picture of the language, since they're easy to optimize

I didn't say anything about short benchmarks.

> At the time when computers had 32/64 MB of RAM.

Exactly. Phones now run with 4GB RAM. A Raspberry now comes with 0.5GB and more.

> Huh, What kind of unused code and data is there in a 25MB hello world?

debugger, inspector, compiler, interpreter, command line interface, debug info of those, ...

> Compiling to C doesn't improve safety of Lisp. As a C programmer, "Compiling to verbose cryptic C" doesn't sell me as a feature, more like a potential security threat.

You get rid of any runtime interpretation and compilation. All that remains is a static C program.

> "Compiling to verbose cryptic C"

Then compile to readable C.

>All that remains is a static C program. That what i mean in "verbose cryptic C". Machine-generated C is huge and hard to comprehend in its entirety, with recursion and continuations practically impossible. It is just a step above from dis-assembled programs. C isn't some magic format that prevents bugs or ensures safety(in fact opposite of that, the larger the code the more bugs it will produce).

Which Lisp compiler output to C have you seen?

Bigloo Scheme CHICKEN Scheme Gambit Scheme https://github.com/justinethier/cyclone RScheme SCM Stalin