1.GC that prevents it from using real-time and performance-oriented code. Lisp is a great language but it can't be the silver bullet for everything. If you nee

1.GC that prevents it from using real-time and performance-oriented code. Lisp is a great language but it can't be the silver bullet for everything. If you need hard real-time programming you need to look elsewhere. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. 2.Pervasive use of inefficient lists and dynamic typing, which puts steep memory requirements on top of performance costs. The same is true of Ruby, Python, C#, and other popular, well-accepted languages. And how can you speak about "inefficient" lists? Lisp uses linked-lists which is an efficient data type in the context of recursive functions, which Lisp coders make extensive use of. 3. Arcane write-only syntax which becomes context sensitive with Domain-Specific Languages which Lisp programs devolve to, creating unreadable and overly condensed spaghetti code(especially macros), making existing code inaccessible for developers. The whole point of creating a Domain-Specific-Language and then express the problem using the DSL is to, precisely, go away from unreadable code and spaghetti code. It seems you have not used Lisp enough. 4. Huge runtime which is embedded in every executable, that makes it less competitive with scripting languages. Lisp requires eval() and runtime interpretation which other languages optimize out and replace with fixed code paths. (some external programs called "tree shakers" remove the lisp's runtime cruft, but they're exception rather than rule) Common Lisp is generally faster than most of the scripting languages out there (Ruby, Python, Perl), and in reality approaches C speed... As for "Lisp requires eval() and runtime interpretation", this is not true. You need to read more about the Lisp compilation model. 5. Lisp has very loose safety. Any piece of data can be potentially executed at runtime and lisp programs have to be excluded from WriteXORexecute/NX protection, since lisp code/data are intermingled. Executable stack and heap expand areas for exploits and create a general lack of stability - any bug can corrupt running code, Lisp is so far removed from any concept of safety it even allows the programs to be modified at runtime(this is a fundamental feature shared with polymorphic viruses). "It even allows the programs to be modified at runtime". You mean allow the program to self-modify, right? How horrible, how sinful!! I guess we should stay with statically linked, statically compiled, statically typed, procedural-only, manually-memory-managed, code. I guess we should all go back to Algol-60 then.