I agree with lot what you say. In the 70s speed wasn't really the big problem, but performance. Sounds similar, but it wasn't. The performance of Lisp on a min

I agree with lot what you say. In the 70s speed wasn't really the big problem, but performance. Sounds similar, but it wasn't. The performance of Lisp on a mini computer seriously degraded with the number of users on the machine and the lack of available RAM (one megabyte?). A single Lisp on the machine could be relatively fast, but Lisp had high memory demands and a simple GC could walk through all allocated (virtual) memory of a Lisp process. Thus the machine got slow when 50 users suddenly worked next to one or two Lisp users. For Lisp users this was especially a problem, since they were often meaning to use interactive Lisp systems, not batch computation. The idea of Lisp computers was not so much about faster CPUs, but a performant machine for a single user with high memory demands. 90s memory sizes started to get bigger, but Lisp was then hit by the AI winter. Many projects at that time were either moving to C++ for applications (because that was the new efficient industrial language) or tried to develop new languages, which are simpler, cheaper and more deployment friendly (Dylan, Java, C#, Scripting languages in a C runtime, reimplementations of special languages in C/C++, ...). Cost of development systems and the cost of deployment - we are talking about cost of both software and hardware here - was a problem for a long time. There were always also people who tried to provide solutions, Scott Fahlman for example directed the CMUCL project and his goal was to have an optimizing CL system for free - providing CMUCL as no-cost public domain software was a major goal for him.