Well, modern C++ discourages the programmer from doing manual memory management. There's a very strong push to use vector and string instead of arrays and C st

Well, modern C++ discourages the programmer from doing manual memory management. There's a very strong push to use vector and string instead of arrays and C strings, references instead of pointers, or, if you really need them, smart pointers instead of raw pointers, etc. Any book or article on modern C++ will tell you to let the compiler and language run-time handle memory management. It's not quite GC, but it's similar. On the other hand, the default in Lisp is always to let the compiler handle memory, but Common Lisp in particular gives the programmer a lot of flexibility and control over types, memory management, and other optimizations. It's been fighting the "Lisp is slow" stereotype for a long time, so there's been a lot of work done to optimize it and give the programmer optimization options. For your specific question about memory access patterns, Common Lisp does allow some control over that via the "dynamic-extent" declaration: (declare (dynamic-extent variable-name)). It tells the compiler (or interpreter) that a variable in an inner scope (of a loop, for example) can be allocated once and the space reused each iteration instead of allocating fresh memory each time. It's not full blown C style control of memory, but it's similar and can have a big impact in some situations. The book "Common Lisp Recipes" has a section on it, and so does the hyperspec: http://www.lispworks.com/documentation/HyperSpec/Body/d_dynami.htm http://www.lispworks.com/documentation/HyperSpec/Body/d_dyna... The recently published "Common Lisp Recipes" is a great book that covers a ton of topics in this area. I think a lot of people would be surprised just how much control and flexibility is available in Common Lisp. I wouldn't say Common Lisp is faster than C++ in general, and certainly not by default, but with a bit of work it's possible to get pretty close. Importantly, the optimized code will still look and feel like more or less idiomatic Lisp.