I don't really know what he meant, with the references to managed code and assembly language in relation to Lisp, but what he actually wrote is wrong when it comes to Common Lisp.
Perhaps he's referring to the batteries included feel of other platforms. Every other platform (i.e. .NET/java/ruby/python) have gobs of built-in functionality in the standard library - everything from parsing, to different I/O models (NIO in java), to frameworks (WSGI, WS consumption and production, etc). Lisps diverge fundamentally (e.g., the threading model) if it isn't specified in CLtL or ANSI CL. CL seem hamstrung by those documents.
Concrete Example:
7 years ago I couldn't (using available libraries) reliably parse in lisp a DB dump in XML (~8GB), select some records based on a set of calculations, and convert it to CSV. Most libraries insisted on needing the whole document in memory, some libraries leaked like a sieve and caused heap exhaustion, others couldn't handle UTF8. In the end, I could do it python (couple hours to develop and took 45-60 minutes to run), I could do it in java (several hours to develop and ran in ~8min), but I couldn't do it in LISP without writing a custom XML parser or delving into FFI. Maybe it was an abnormal case, maybe not.
I miss macros and the expressiveness; I miss the community; I don't miss the insanity.
Well, it's not like that any more. There are portable ways to work with threads, there are multiple XML libraries, some of which do not read the whole document in memory, and all implementations support UTF-8.
These things happened because some people decided to improve CL (both implementations and libraries) instead of using something else.
You should always pick the right language for the job. You could have written the right language in Lisp or you could pick a good enough language to solve the problem.
