Of course . . . you can also use a flat rock to hammer in nails when framing a house, but a framing hammer might be a better idea. Doesn't mean it can't be done, though, especially if you're really good with rocks and already have them lying around, whereas you'd have to go to the hardware store just to buy the framing hammer.

My point was not "language X can't do project type Y," but rather that the things that put a language in the sweet spot for certain types of projects kind of inevitably pull it out of the sweet spot for other types of projects. I.e. it really is always about trade-offs. Sometimes the mere fact that you know how to use a given language is enough of a win to outweigh any potential benefits of switching to another language.

While I'm not a big fan of Tcl/Tk, I'm quite familiar with it and find I this statement confused or misleading in at least two ways:

First, GWL once told me the bulk of the code is actually rather mundane GUI form definitions (the sort of crap that is trivial to generate with high level interface tools). There's only a small amount of actual "logic" at that level that ever needs to be maintained (the real control isn't done in Tcl).

Second, even if there are 50,000 lines of Tcl (actually I think the actual number is closer to 300,000), it doesn't mean it's one big script. It's probably more fair to compare it to a unix system with hundreds or thousands of separate smaller write-once scripts.

Ironically I think the real fault here lies with GWL and other Tcl enthusiasts for quoting a true but misleading "number of lines" in the first place. The number of separate scripts and average script length would be more meaningful and representative of the system's real complexity.