Purpose: to detail some of the places where interacting with Tcl leads one to frustration, confusion, aggrevation, anger, hatred, ... (you get the idea...)
namespace: The concept is good, but the execution is flawed, especially if you're doing anything object-oriented. Which is kind of ironic, given that (AFAIK) namespace were created to support OO, specifically incr Tcl. The implementation has C++'s fingerprints all over the syntax. Tcl is many things, but C++ is not one of them. The two don't fit well together.
A problem that I keep running into is that I don't typically use the global scope operator :: for objects at global scope, so there's usually a string inequality between what I'm typing and the value of $self, $this, [self], whatever the OO system is using. And if you try and compose object names by combining object names, you get spurious ::'s lying around in the middle of names, which makes Tcl very unhappy.
glob: the need to somehow quote the glob {} combination so that one gets the quotes passed on to glob. Use quotation marks (") or braces around the arguments to get them past the parser.
Regular expressions: a similar problem - the need to quote arguments appropriately so that various regular expression metas make it through the tcl parsing.
Tcl comments: Why can I not place unmatched braces in Tcl comments
Tcl hashes vs arrays: Sometimes people attempt to simulate 2 or more dimensions of arrays using the Tcl associated hashes (aka tcl arrays). The gotcha here is that because the array index is a string, white space is significant.
$ set a1(1,2) abc
abc
$ puts $a1( 1,2)
can't read "a1( 1,2)": no such element in array
while evaluating {puts $a1( 1,2)}Another gotcha here is trying to set arrays with white space:
$ set a1( 1,2) abc
wrong # args: should be "set varName ?newValue?"
while evaluating {set a1( 1,2) abc}You need to use quotes if you are putting space into that variable.
Easily Tcl's most undeniable blemish: exec's brokenness in not directly allowing < or > as leading characters in arguments.
{expand} addresses another blemish.
[inconsistencies in names in library]
LV Shoot, exec doesn't allow | as a leading character in an argument either. And - as the leading character in an argument can cause problems, and so on...
On the other hand, if you are talking about using < or > as the leading character in a file name, you solve that problem in the same way you solve the others - make certain it isn't a relative path name:
% exec ls ./>stuff ./>stuff: No such file or directory
So it is doable.