Perhaps your organization believes this: "Tcl seems to be an interesting language, but if we use it to solve a problem, then we'll forever be at risk for losing all our Tcl expertise with no effective way to replace it." Your organization would be correct, of course, in its awareness of the strategic nature of its information technology (IT) assets.
Tcl's part of the solution, though, not part of the problem.
[Explain contracting possibilities, acknowledge hiring mis-practices, distinguish Tcl "learnability" from C++, ...]
RS Tcl skills are less frequently in the market than, say, Java, but
Re the "mastering" side... seems to hold for all programming languages. Maybe that explains why people stick to what they know, against all further reasoning? -jcw
[Explain radical claim that Tcl can be so much more productive in apt problems than, say, Java, that a company will find it cheaper to maintain a solution coded in Tcl, even with the cost of learning Tcl from scratch, than applying its in-place Java expertise on the comparable Java-coded solution.]
Let's be precise: no one knows what Tcl skills are available in the marketplace. There certainly are people who present themselves as experienced in Tcl who are, at best, terrible stylists; but I'd guess we've all encountered abundant instances of faked Java- or C-knowledge. What's most certain is that hiring departments are unaware of Tcl. With rare exceptions, they don't have a category for it, they don't track its presence or absence, and most work-seekers know not to waste space and time advertising their Tcl savvy. Few organizations have any positive information about the availability of Tcl skills. They certainly have a right to base decisions on that ignorance. It does not mean, though, that those organizations know that Tcl skills are absent. In fact, I'd guess each of us knows of instances in which an organization believed false things about Tcl, including the mistake that it lacked Tcl experience.
Question: I've been of the opinion that if someone knows a scripting language (such as perl), then they have already learned the scripting mindset and can easily pick up tcl. I've thought that was the main hurdle -- moving from a non-scripting to a scripting language. Is this not so?
Script-like thinking might confuse a non-scripting thinker because they don't, e.g., think of lists as code or code as lists, but a scripter can pick it up in a snap. They've already made the leap.
If we were looking to hire someone and had trouble finding a person with Tcl experience, I'd be willing to hire up a person who had familiarity with another scripting language. The learning curve is not steep.
Just make sure you hire smart people. Smart people write smart code... dumb people write dumb code.
I'm not trying to insult any coders here, I just wanted to present this rule of thumb in a form that a manager can get his mind around.