> "Where necessary?" is almost always, because vectors almost always outperform linked lists based on cons cells. Let's see, I have here a Common Lisp compilin

> "Where necessary?" is almost always, because vectors almost always outperform linked lists based on cons cells. Let's see, I have here a Common Lisp compiling to machine code, here non-optimized generic Lisp code: I'm allocating n elements list/vector of vectors and reverse it p times. reversing allocates a new list/vector. (defun test1 (n p) (let ((v (make-array n))) (map-into v (lambda () (make-array 10 :initial-element 1000))) (loop repeat p do (setf v (reverse v))) v)) (defun test2 (n p) (let ((l (make-list n))) (map-into l (lambda () (make-array 10 :initial-element 1000))) (loop repeat p do (setf l (reverse l))) l)) CL-USER 15 > (time (test1 10000 100)) Timing the evaluation of (TEST1 10000 100) User time = 0.005 System time = 0.000 Elapsed time = 0.003 Allocation = 9088696 bytes 1 Page faults GC time = 0.000 #(# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ...) CL-USER 16 > (time (test2 10000 100)) Timing the evaluation of (TEST2 10000 100) User time = 0.008 System time = 0.001 Elapsed time = 0.006 Allocation = 17113288 bytes 842 Page faults GC time = 0.003 (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ...) The list or vector is 10000 elements long and 100 times reversed and the difference in runtime is tiny. The list version is only marginally slower, but allocates a lot more memory. I can also construct cases, where the list is much faster. Adding a one element list/vector to the front: CL-USER 22 > (time (test1 10000 100)) Timing the evaluation of (TEST1 10000 100) User time = 0.016 System time = 0.000 Elapsed time = 0.012 Allocation = 9148776 bytes 0 Page faults GC time = 0.000 #(A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A ...) CL-USER 26 > (time (test2 10000 100)) Timing the evaluation of (TEST2 10000 100) User time = 0.000 System time = 0.000 Elapsed time = 0.000 Allocation = 1042248 bytes 0 Page faults GC time = 0.000 (A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A ...) Here the runtime for lists is much faster, since it does not copy the complete list or -> lists share storage, consing to the front is cheap. -> for many practical use cases for lists the total runtime and the runtime difference does not matter Obviously there are also many case where a list would perform much worse, like accessing the last element of a list. > Are you even capable of admitting that Lisp has serious faults You seem to be keen to find "faults". Usually things are not black and white. There is no true and false, but engineering trade-offs. These tradeoffs can Lisp make the wrong choice for problems. Many of the trade-offs are also influenced by non-technical issues: like the amount of engineering time invested into a language implementation: see SUN/Oracles investment into Java.