If small Tcl doesn't exist, it becomes necessary to invent it:
> In an era of 32K ROM/4K RAM microcontrollers, we don't really have a well-featured scripting language that works down there.
What about Forth? http://www.forth.org/
Just ... no. I'm trying to solve a problem, not play intellectual games for how to create stack threaded code.
I had really high hopes for Lua. But 1-based indexing when you're interfacing to C is just not flying. Apparently I'm not alone as Lua comes in at #9 on the "Dreaded" languages list:
https://insights.stackoverflow.com/survey/2017#technology-mo...
> 1-based indexing when you're interfacing to C is just not flying
That does not stop a lot of people. Not that it matters, because Lua will not run in 4KiB RAM.
Threaded code is a compiler/interpreter implementation technique. That makes as little sense as saying you won't use C, because you are "trying to solve a problem, not play intellectual games for how to create static single assignment code."
Instead of being an armchair programmer, you should actually try to learn those programming languages.
The primary issue is that Tcl was a language designed on the wrong side of the memory cost divide. Many of the languages designed with "memory and CPU are expensive" got swept aside because newer languages that didn't make that assumption had a lot more features.
What is sad is that Tcl didn't STAY SMALL. In an era of 32K ROM/4K RAM microcontrollers, we don't really have a well-featured scripting language that works down there.
It also didn't help that Tcl went into a period of instability right as the Dot Com Boom/Crash went full tilt whereas Python, for example, was stable from 1997-2000 (A LOT of people standardized on 1.5 for a loong time)
And, as smart as he is, John Ousterhout was one of the big coding problems and getting him out of the codebase helped Tcl dramatically.