The more abstract a language is, the more complex it necessarily becomes to compile/execute/interpret code written in that language. The CPU/core only performs one simple operation at a time, and even something as simple as variable-sized array allocation is quite involved at that level.
I'm the kind of guy who rounds up to the next nearest multiple of 4 by saying "x + 3 & -4" (-: Throw something like loose types or garbage collection at me and I go into anaphylactic shock.
LISP doesn't have that kind of abstractness. Because everything is a prefix expression, there's no way to mangle LISP code in a way that makes it difficult to compile or interpret. At least for compilers and interpreters. Human beings are another story: because LISP supports and encourages meta-syntax, LISP code tends to be abstract in a very specific way. In C, you tend to read source code as a bunch of functions written in C and then blocks of code also written in C that invoke those functions. But in LISP you tend to read source code as a bunch of
syntax-defining expressions and then blocks of code
written in that defined syntax. So LISP tends to be meta: as more than one person has put it, C source is the code that does the thing, but LISP code tends to be the code that writes the code that does the thing.
Neither the compilers nor the interpreters have any problem with that, because macro resolution is itself performed strictly through the rules of LISP expression evaluation. Now, there are complexities to the runtime environment of some versions of LISP such as the allocator and GC. But those aren't things the interpreter itself has to worry about. The compiler sometimes does, but in exchange for having to worry about those things there are things LISP compilers don't have to worry about, like side effects or undefined behaviors. They don't exist in LISP, which opens the door to optimizations that are much trickier or dangerous in other languages (including C).
Which is really what I ultimately don't like about LISP: its syntactic neutrality. Because every LISP program tends to implement meta-syntax, it causes long-term headaches when it comes to readability and reusability. I haven't done a major (>5000 lines) project in C in over a decade. But when I had questions about ZFS, I went to the source code. I first learned C in 1985, and I can still read it today. What's more, I can read virtually *everyone's* C. True, some C is prettier, some C is messier, some C is stone-cold stupid. But its all dialects of C I can understand. The same is true for Fortran, COBOL, RPG, Python, even shell script. Unless its an entry into the OCCC, chances are pretty good that at a glance I can tell what the code does. Learn once, transparent forever.
That's not true with LISP. No matter how much LISP I wrote, it did not make me particularly good at reading other people's LISP code, because of meta-syntax. In fact, I had trouble reading
my own code after enough time had passed that I no longer had the same mindset and way of doing things. In C, style is style. In LISP, style is substance. To read someone's code, you have to absorb the mindset of the person who wrote it, so that their metacode becomes transparent. And you have to do this over and over and over again.
Its that kind of abstraction that ultimately just doesn't work for me. I need a language I can pick up, work on, put down, come back whenever, steal code from different places, work some more, put down, forget about, and then return later as if it was yesterday. For me, LISP is not that language. LISP itself at its core is easy to remember and easy to read, but no one programs in LISP. They program in their own JohnDoe language that LISP compiles for them. And I don't have enough free space in my brain to keep a functioning LISP compiler in there for when I might need it.
