TCL (pronouced tickle), or Tool Command Language, is a small interpreted scripting language that maintains a relatively low profile amongst the big languages of our time. Most software developers have either never heard of TCL, or would deride it as a toy language. Compared to the behemoths of development like Java and C it may occasionally appear to be a toy, but that may be an unfair assessment.

A lot of time is spent debating what language is the best. Ignoring primarily interface design languages like Visual Basic, and also ignoring C-Sharp (Microsoft's Java-esque language) which I know nothing about, we are left with most people blathering on about the machine independence of Java, the speed of C, or the ease of development in PERL. Not wanting to engage in the pointless pissing match of what language is best I will instead offer a brief defense of TCL as a programming language.

TCL is slow

Compared to a compiled language like C, or Java running on a fine JVM TCL is definitely slow. There are two major compensating factors:

1. Oftentimes you are spending longer in the database then in the code, and in these cases the advantage of Java's speed is muted.
2. Programmer time is expensive, hardware is cheap. TCL is small, easy to learn, and has a satisfactory (if you're careful) macro-ing mechanism. This, plus the fact that it is interpreted, makes development very fast. Even if you know the J2EE standard inside and out you will be slower in writing your software then I will with TCL. When you find that you are having trouble scaling you can often rely on machine upgrades to insulate you from issues generated by the speed of your language. Hardware can't save you from bad design, but it can save you from language speed.

TCL isn't OOP (doesn't have struct's etc.)

While Object Oriented Programming is all the rage right now, and it definitely can be a powerful paradigm, it is not the best tool for every situation. Sometimes a functional or procedural language is a better fit. While it is true that TCL's main language structure is the list (it does have an associative array), the list has been the backbone of LISP. This is not to say that TCL's data structures are always good enough, there are some problems that are not list friendly, but with the addition of an RDBMS, TCL is up to the challenge of most website's needs.

TCL doesn't have as much available functionality as .. (PERL, PHP, Java, C)

I don't think that any language has as many packages tied to it as PERL. The PERL community loves to create libraries for their favorite language. This being said, it doesn't meant that everyone should use PERL. While TCL may never catch up with these other languages in popularity it is the backing of a solid web toolkit, (as well as a nice graphical toolkit -- TK) and if you are working in these areas you should consider the toolkits on their own merits.

There are some real issues with TCL. Although I sort of brushed it aside, the data structure issue will occasionally be an issue when building a complex website. This will not often be the case, but when it does become a problem you may find yourself with a list of lists of lists of lists of lists. This is a very unfortunate situation. AOLserver tries to get around this with another type of associative array called an ns_set. Unfortunately their implementation has linear lookup times on keys, which I personally find offensive. TCL is also easily extensible via C for those of you who can't give up your struct's.

Another issue is that when designing a serious infrastructure (like OpenACS) you need to be fairly careful in design. This is true in all languages, but TCL allows people to do very lazy things which are extremely frightening. Consider "set_the_usual_form_variables", an old ACS function which would set a bunch of variables in the calling environment. If you had a web request like:

GET /object?oid=12&order=date_asc&user_id=145

you would find that after running "set_the_usual_form_variables" you would have the variables oid set to 12, order set to "date_asc", and user_id=145. Nowhere in the code had you expressly called for these variables to be set. This means that anyone sending a web request can set variables in the calling environment. Having a bunch of unspecified variables floating around leads to bugs, and even worse security issues. If you are careless and don't initialize a variable you may find that some URL hacker has set the variable in your environment without you knowing. This terrible practice is not limited to TCL, and in fact you find a lot of web-friendly languages doing just this. Even worse is a language like PHP which sets these variables and if a variable is referenced and not set it substitutes "" for it's value. This is a very dangerous and lazy practice. Now that was quite the digression, but it does illustrate how TCL makes it easy for lazy programmers to make big mistakes thinking that they are good practices. Any language can run into this problem, but languages like Java make it a little bit harder.