Why is tcl broken?

[Michael P. Reilly]

In comp.lang.python Fernando Mato Mira <matomira at iname.com> wrote:
: Hello,

:   I'm trying to collect a list of all the _current_ issues making tcl
: a bad language choice. I'd like concrete examples, and not just
: vague assertions that cannot be put porward honestly. I think
: that as is usual in this newsgroups, there's going to be people that
: actually know what they are talking about (and even better, experienced)

: when referring to a language that is not their favorite.
:   If you have references to articles of the sort, that will be useful,
: too.
:   Note that I've not listed comp.lang.tcl for increased productivity,
: and to avoid starting a flame war. Hopefully some misconceptions
: will be filtered down here, and _then_, the summary can be presented
: in that newsgroup for their defense.

I won't go into too many details, it was on an older version of Tcl.
But some years ago, I played around with making C library wrappers
(before SWIG was around) so the developers could write Tcl test scripts
for their libraries.

The problem was that null bytes ('\000') we frequently used in the
code, and Tcl (at the time) could not handle null bytes.  I abandoned
the proof-of-concept project for that reason.  I did have a little
following of developers who were looking forward to that functionality
tho.

I believe that current releases of Tcl can handle null bytes, but I
have not verified that.

In general, the lack of complex data structures is what I find to be
most troublesome in the Tcl language itself.  Beyond lists and
associative arrays (hashes), you have numbers and strings.  The
language makes it convenient to pack these (split, join, etc.), but not
always to utilize them (array names, etc.).  And evaluation is
sometimes difficult to deal with as part of the language.

But for its problem set, I find Tcl to be flexible, quick and easily
extensible (in C or Tcl).

  -Arcege