I actually wrote some code to find unbalanced braces in the codebase I was maintaining at work. One big downside of Tcl is that the parser gives you practically no help with syntax errors--never a line number, and only sometimes does it give you context.
Another common mistake is that curly brackets are VERY significant in [expr]. The author writes statements like "expr $i * $i" in several places, and it makes me cringe for two reasons:
1- This code prints "5" because expr does a double-substitution:
set a 5
set b {$a}
puts [expr $b*1+0]
What's going on here is that $b is evaluated (to the string "$a") before calling expr, then expr itself evaluates its argument:
$a*1+0
to 5. This is a problem because $b can be anything--for example, a call to [eval] arbitrary code.
2- Calling expr without putting braces around the argument is unfathomably slow. Tcl precompiles procedures as much as possible, and calls to functions requiring dynamic evaluation (like eval or expr without braces) can't be precompiled.
I once solved a huge performance problem by finding and fixing calls to expr made without braces. What was a process that took 40+ hours to finish was reduced to around 45 minutes by this change alone.
Why do I see people talking about this kind of thing in Tcl being perfectly okay, while PHP is nowhere near as randomly dynamic and gets a lot of hate?
I suspect for two reasons - first, that Tcl is always dynamic the same way and in clearly documented places, whereas PHP is a lot less consistent about it; and second, that in Tcl a lot of the core language constructs do so, so it's something you get familiarised with early rather than bitten by later.
Plus, PHP users seem to be most likely to either go "err, so?" or "YOU DON'T UNDERSTAND THE TRUE GLORY OF PHP!!!" in response to being asked about it, whereas Tcl users generally tend to respond "yeah, you need to learn about that and get used to it" - which tends to significantly alter the next comment made.
(not trying to imply that PHP doesn't have users in the third category, just that the first two are the more visible and it alters the discussion's tone)
Probably because Tcl has other redeeming qualities.
Command line programs are now passe in all except a few niches like routers, chip design etc, but IMHO there still isn't a better "/bin/sh++" that you can embed as command line shell interface between your C functions and the user.
I would make a distinction between a CLI (to be used by ordinary users of the program) and a scripting interface (to be used to "extend" the program, to be used by power users and/or other programmers).
And I would further submit that the same language may not be the right choice for both tasks.
Tcl leans further towards being a pleasant CLI interface language, while AFAIK Lua leans further towards being a pleasant plugin development language.
Another common mistake is that curly brackets are VERY significant in [expr]. The author writes statements like "expr $i * $i" in several places, and it makes me cringe for two reasons:
1- This code prints "5" because expr does a double-substitution:
What's going on here is that $b is evaluated (to the string "$a") before calling expr, then expr itself evaluates its argument: to 5. This is a problem because $b can be anything--for example, a call to [eval] arbitrary code.2- Calling expr without putting braces around the argument is unfathomably slow. Tcl precompiles procedures as much as possible, and calls to functions requiring dynamic evaluation (like eval or expr without braces) can't be precompiled.
I once solved a huge performance problem by finding and fixing calls to expr made without braces. What was a process that took 40+ hours to finish was reduced to around 45 minutes by this change alone.
edit: formatting