Tk is great but Tcl itself... it's interesting but the difficulty in creating real data structures (as opposed to just strings) makes me start reaching for Scheme again...
Tcl was never meant for that, the Ousterhout way would be to extend Tcl with the data structure written in C. Now Lua has knocked Tcl crown of "designed from scratch with embedding in mind" but at that time Tcl was indeed quite unique and one of the easiest to embed. This in a backhanded way inspired Guile: scheme intended to be embedded and/or extended.
Talking about Guile, lots of fun things happening there lately. wiki.tcl.tk is a lot of fun too.
The Tcl shell itself (tclsh, which is many people's only interface with Tcl) is just a REPL that uses libtcl. The Tcl library is written in C, and built to be easy-to-use and powerful. Tcl also has an incredibly stable API/ABI which allows for a "stubs mechanism"[0] which is quite a nice, powerful facility that allows for seamless fixes to your Tcl-dependant work.
Great points. Something I feel that Tcl really got right and Python did not is handling concurrency. The Tcl way is to run the different interpreters in different threads and communicate between them by message passing but without the need for serialization - deserialization. They had this from the very beginning.
Yes. For multithreaded code, instead of deciding where/how to put interpreter locks (like Python's infamous GIL (global interpreter lock)) to manage low-level sanity wrt sharing data, Tcl punted and lets each interpreter run unfettered.
Short answer: size, API and ease of resource management.
My comment was more about the state then than the state now. At that time few, if any languages were designed from scratch to be extended and embedded. Tcl and Guile, to my knowledge were among the first. Tcl interpreter is a library. IMO Guile has grown beyond that charter and is more of a stand-alone Scheme now, but one that can be easily embedded / extended, but so is Chicken I guess.
