I think Tcl is ideal for writing domain-specific formats, e.g. file formats that require a few custom constructs but would still benefit from essentially an ent

I think Tcl is ideal for writing domain-specific formats, e.g. file formats that require a few custom constructs but would still benefit from essentially an entire programming language to help with specification. I also think Tk is a major strength, though I always preferred Perl's interface to it. Despite these strengths, I don't like Tcl as a language. It's not that its syntax isn't without certain charms (brevity being one), but it has a few flaws that I consider fatal: 1. It is far too easy to make the mistake of inlining a list. This can result in arguments being passed in the wrong order, or partial lists being processed when it "seems like" the whole list has been read, etc. This is a very hard problem to debug. 2. The Tcl interpreter does not trace blocks very well. It usually points you to the line of the last curly brace in a half page of nested constructs, which tells you almost nothing about where an error is. 3. While it's very easily bound to C, it has no concept of objects. So Tcl APIs seem to require constant re-querying; for example, rather than "set x [expensive_get_operation a b c]" followed by "[x do_y]" and "[x do_z]", APIs tend to look like "[expensive_y a b c]" and "[expensive_z a b c]". All other advantages to objects are, similarly, lost. Of course, Tcl has been evolving fairly rapidly lately, and 8.5 addressed a number of serious annoyances. Maybe my perception is out of date; if so, please enlighten me.