I'm not sure I get this. Any competent programmer can learn Tcl. So find one versed in scripting languages like Python or Ruby, and they can learn how Tcl works in a week and learn how the program is structured over a few weeks and start making small changes. I'm skeptical that this training overhead would really cost more than replacing the whole system if it really was working well.
You're looking at it soley from the PoV of the company.
> Any competent programmer can learn Tcl. So find one versed in scripting languages like Python or Ruby, and they can learn how Tcl works in a week and learn how the program is structured over a few weeks and start making small changes.
Sure, but why would they want to? They'd be wasting time on a skill that adds exactly $0 to their market value.
The longer they stay with you, spending time getting experienced with Tcl (and not with some other popular language), the less they are worth.
> I'm skeptical that this training overhead would really cost more than replacing the whole system if it really was working well.
For the company, no. For the developer, most developers tend to shy away from dead-end tech stacks. If you get someone close to retirement (10 years away), they'd be happy to use your dead-end tech stack, because to them their current market value gets more irrelevant with each passing day.
No, I'm not. I personally am not at all concerned about "dead-end tech stacks" because the kind of companies that care that you have specific skills rather than overall engineering competence are not the ones I want to work for. I'm sure I'm not the only one.
And as people left, the theory of the program was being lost, turning it into "legacy code." There were other problems as well - in particular, the initial data structures that were coupled to billing made it difficult to try other business models, and the industry was starting to innovate with point to point in other markets. Those were solvable in Tcl, though. The real problem was people.
Right, it's always something like that. Thanks for clearing that up.