> And of course there is Forth. Which always felt like it was just around the corner from some kind of breakthrough but it never really happened.

Forth, (I think even more so than lisp), is fragmented, because its philosophy is not that you write “a forth program”, but that you write “a forth” that does what you need it to do. Don’t like the sign MOD chose to compute ‘-3124 modulo -17’? Don’t add a new one, but change yours. Need better approximations for integer goniometric functions? Change them to work in half-degrees, etc.

That makes sharing code difficult and that, in turn, makes it hard to write large programs.

Nowadays, I guess a ‘solution’ to that problem would be to run zillions of forths as microservices in a single process, but I don’t think that’s practical (could be fun, though. In the limit, one could give each forth a VM page of RAM or maybe even less to work in. Imagine a forth whose sole goal is to maintain and edit a string, with words for string indexing, search, replace, duplication, etc. that runs together with millions of other forths in a single process.

Your musings at the end reminded me vaguely of https://www.greenarraychips.com/ a Chuck Moore designed computer chip.

"With 144 independent computers, it enables parallel or pipelined programming on an unprecedented scale. Map a data flow diagram or an analog block diagram onto its array of computers for continuous processes without interrupts or context switching."

Interesting view. The way I approached Forth was to create a DSL that made it easier to write the application in.

The biggest issues that I had with Forth were: hard to work on code as a team, the 'screens', finding it increasingly hard to name words.