Imagine a language in which was so easy to write code that code flowed from a thousand keyboards, simply and correctly.
Imagine a language where it is so easy to roll your own OO system that you forget that code reuse was one of the key reasons you did it.
Is that what we've got ourselves in Tcl?
If so, Tcl is a victim of its own success.
This page is for qualities of Tcl which properly fall simultaneously into both Things holding Tcl back and Things pushing Tcl forward, because the interplay between those two categories is what will steer Tcl toward what it will become, or will cause it to stick in place. Sometimes one relies too heavily on that which one does best, to the detriment of other things.
RS 2004-09-20: I have to admit that often in Tcl coding, my brain is the code repository - some frequently used procs like K, every, lambda, lpick, lreverse, or algorithms like cartesian/polar conversion, just flow into the keyboard as needed...
Imagine a language with a rich set of core features that work consistently and predictably. Imagine not having to rely on batteries included libraries outside of the core (i.e. libraries written in the language itself which aren't always subject to hardcore unit testing and regression testing and don't religiously catch every potential error condition). Hey, wait a minute. That's why I chose Tcl over other so-called scripting languages. Tcl's core language keywords (really more like libraries) work. While tcllib is wonderful, I tend not to rely on it for mission critical apps -- tcllib is great for getting things done quickly without duplicating a lot of effort. But, I tend to use C code (exposed to Tcl) for hardcore stuff where everything must work flawlessly and every potential error condition must be considered. This is not a criticism of tcllib, but a praising of Tcl core. It works as expected.