Tcl is one of those rock-solid things that have been around for a while, where extrapolating from other projects of the same age you'd expect to find a somewhat

Tcl is one of those rock-solid things that have been around for a while, where extrapolating from other projects of the same age you'd expect to find a somewhat muted community, and that's not the case at all. Dormancy and stagnation can have many causes: author hiatus, the code clearing some threshold feature-complete, obsolescence by competing tech that solves similar problems. And it seems Tcl has managed to stay relevant through a combination of usefulness (like its standard lib, or Tk) sufficient paradigm difference to tech that came later, in some cases future tech building on top of it instead of replacing it wholesale, willingness to fix common gripes in the core (numbers, unicode, binary), and a developer-focused (instead of consumer-focused) approach to packaging. It's probably helped by being a captive scripting language on some embedded platforms too. Languages that became big and popular in later years faced demands around the distribution of third-party packages. Perl became an early pioneer with a community repository, but later languages had to cope with the expectation of using a language-specific package manager that would download from the official repository, and automagically make packages available globally. Tcl encouraged user contributions in a less formal way [1] -- develop programs (code that uses builtin commands) or extensions (code that defines new commands) for your own use, and make them available if you so wish. This minor difference in attitude creates an ecosystem that feels different from a language package repo, where thousands of packages of varying quality sit, the long tail of them effectively unvetted. [1] http://wiki.tcl.tk/2352 http://wiki.tcl.tk/2352