I think the single largest barrier to a well running compact Lisp is simply memory. The more often you run out of heap, the more often you have to GC, and that

I think the single largest barrier to a well running compact Lisp is simply memory. The more often you run out of heap, the more often you have to GC, and that memory churn on those very slow CPUs has great impact. FORTH doesn't have this problem because it's quite static. It "never" reuses memory, the dictionary (where all the code and data live) just gets larger. When it gets too big, you restart/reset the dictionary (via FORGET), and memory reclamation is a simple pointer change. BASIC only has the memory issue at runtime, specifically with Strings and the heap they're stored on. Everything else is quite static. When you type "RUN", the pointers to the working memory are reset and the variable tables et al are rebuilt as the the program is run. Since BASIC separates the code from the data, this is easy. FORTH intermixes the code with the data, but since it doesn't reuse any of it, that works quite efficiently. Lisps tend to mix code and data and that make heap fragmentation a real issue. Slow CPUs make for slow GC. But, give more memory, GC happens less. When it happens, it's "more", it's "harder", but that can be more acceptable if the user is prepared for it. As I understand it, even the Lisp machines would get into states where it was simply faster to restart than have a "full" GC run. Memory and MHz makes Lisps much happier. The Commander can have a lot of memory, but it's all in banks. A Lisp, perhaps, could be written that leverages that seamlessly, but it's not free. Not like with, say, a 65816 or the x86 where the banking (segmenting) is part and parcel to the addressing and instruction set vs being bolted on to something like a 6502. Obviously one can write Lisp that CONSes less, but it's not especially idiomatic.