Not an argument. you're full of shit
Go fuck a dead hooker. You're an idiot and idiots should be quiet. Common Lisp doesn't throw programmers into a quagmire of integer overflow, checking error return codes, using pointers for simulating multiple returns, stack overflow errors, use after free errors, and convoluted manual memory deallocation schemes. None of the examples >>3 provided show Common Lisp looking anything like C. The Norvig example shows, if anything, that Common Lisp is very similar to Python. The ray tracer example author blames a lack of pattern matching for Lisp and Scheme's verbosity, but both of them have pattern matching available, unlike C. Also, the ray tracer Lisp solution without pattern matching will be near identical to a Python or Ruby solution. Only idiots think because highly optimized Lisp subroutines look as ugly as C they might as well use Lisp instead of C. The Numpy people built a Python library with optimized C code running their speed critical parts, and Numpy is an excellent Python library. Lisp provides support for similar speedups without needing to use an FFI and C. There's little point in arguing with losers who start threads with names like "A lisp that doesn't suck" or the losers that support them, but maybe you'll learn something?