> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based. The "string based" part lies at the very heart of Tcl and plays a

> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based. The "string based" part lies at the very heart of Tcl and plays a big role in what makes Tcl Tcl. However, modern Tcl has moved away from "everything is a string" to "everything is also a string". The difference is that in the normal execution path native types are manipulated for speed, but the string representation is always available should one need more dynamism. Tcl/Tk pioneered the notion of a scripting language as a library. It got threading right. You can run multiple independent Tcl interpreters in the address space of your process and they can exchange messages. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable). Its virtual file system was another great innovation. Lua has taken the crown for small embeddable/extendable language but I still have a soft corner for the playful vibe of Tcl. I would hesitate to use it in a project where I have to interact with folks with whom I have not programmed before (things like 'upvar' and 'uplevel' ups the amount of trust you need). But when its play time, breaking out Tcl is one of those guilty pleasures. Getting rarer these days, playtime that is. Tcl had a reputation for being slow. But those were different times when the standards for 'fast' was much more demanding. Now I doubt it would be any slower than Ruby, it would likely be faster.