TCL is pretty old school and doesn't get a lot of attention nowadays. The main use I'm aware of is in BigIP F5 config files. There are some really interesting things about it though, for example how control flow constructs (if/else, while) are implemented as commands, using built in uplevel and upvar[1] commands to control the scope of the currently executing code. Some people say it's lisp-like, that's one of the things they mean.

TCL has an interesting history, it's creator is also known for Ousthout's Dichotomy[2] which is useful when disambiguating between "scripting" and "other" languages (an argument that occurs frequently on the internet).

Antirez has written about TCL, if you're an admirer of him or his work (redis) you may find his take on it interesting[3].

[1] https://en.wikipedia.org/wiki/Tcl#Uplevel

[2] https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy

[3] http://antirez.com/articoli/tclmisunderstood.html

I wrote a blog post where I show how to define "until" using Uplevel: http://christopherchase.cc/posts/tcl-until.html

upvar and uplevel are also the only parts of the language that I do not use in production scripting. They have their place. It is not in end user space.

Tcl is pretty old. A lot of the territory it covered well is now better covered by other things.

One of its great strengths was being extensible. It's pretty easy to bake some functionality into Tcl and provide a new shell with it. This is what expect (http://expect.sourceforge.net/) is, for instance.

Another early advantage of Tcl was Tk, which provided Tcl extended with GUI stuff. Tk was cross-platform and established very early on, so if you wanted to provide one GUI for Unix, Mac and Windows, it was a good choice. It was very ugly for a long time; I hear it has gotten better lately but I don't know that myself. Tk is still built-in to Python as Tkinter. This is another specialty shell provided by Tcl, wish ("window shell").

Tcl was supposed to be good for embedding. The original author was supposedly using it for robotics. I haven't seen much energy there; I think Tcl's lunch probably got eaten by Lua some time ago. Lua is smaller, more like a modern programming language and easier to embed, but Tcl is more like shell scripting, so I guess there might be style reasons why you might prefer Tcl despite Lua's advantages.

Tcl is easy to disparage, but there's a lot of misinformation out there. At one time, it really only had one data type (strings). Quotation is a big topic in Tcl, but like Lisp, you can supply your own control structures. Everything is a command and commands have a lot of freedom about how to interpret their arguments. It is rather Lispy, unlike Lua. Tcl does have modern data structures and it does pretty snazzy things behind the scenes to optimize access to them while making things still seem to be strings for the cases where that matters.

Tcl is still around in some surprising places. I wouldn't expect there being a lot of new development starting with Tcl but it's kind of a fun language to know about. I got the newest edition of the book and it's a neat book, but I confess I haven't found ideal use cases for it.

Old is relative. There is a good core dev community and recent development is promising. It's interesting you mention Lua because that is a language I picked up when looking to move from Tcl at some point in the last 8 years. I decided rather quickly against that.

The reason is the swig bindings for Tcl are sufficient to generate decent package cores for just about anything I care to extend and I can optimize later.

Old is relative, but there aren't many alternatives to Tcl that are older.

Depending on your exact use case, Forth might be one

Good point.

> "It [Tcl] is rather lispy..."

Yes it is, and that's a good thing. Over the years Tcl has become increasingly Scheme-like in some respects. In fact without too much trouble I've ported some programs I'd written in Scheme to Tcl because of Tcl's portability and easy access to GUI when needed. OTOH adapting some code from Javascript to Tcl was harder.

Tcl is very useful for utilities. Library support is enormous so there aren't a whole lot of things that are impossible in that domain. For ~20 years I used a a client-server scheduling program that I wrote entirely in Tcl/Tk. It required only minimal maintenance, in fact hadn't touched in over the last 10 years it was deployed.

The main difficulty has been marginal debugging support, but there are ways around it so it's not insurmountable.

Not sure if it's lunch has been eaten, but TCL was great for embedding and pretty widely used. So, to mix metaphors, it definitely had a few great meals before losing the spotlight.

I've seen it embedded in load balancers and used for test harnesses for embedded devices.

https://devcentral.f5.com/articles/irules-101-01-introductio...

I just purchased the new book by Ashok myself that covers Tcl (not Tk) 8.6. I have always thought Tcl a fun language and have decided to more of my daily stuff with it. I hang out on the developers list just to watch what is going on.

I use Tcl/Tk from time to time and it always seems the easy choice when I need a simple GUI and also need to make an executable for Windows (which is trivial with Freewrap).

Some of the things I've written are: a simple standby order input app, a Forms/Reports compiler (sends file to server, waits for response and informs user), and a Ghostscript wrapper for merging lots of PDFs into one file.

Awesome! I'm definitely going to be keeping it in mind as little projects come up that could use a GUI.

If I move out of shell for scripting, I go to Tcl. I also write little utilities with Tcl/Tk to do repetitive tasks that I do often.

TCL is really great for throwing syntax errors at runtime, having no real data structures, and an inconsistent API!

Better than throwing syntax errors at compile time; saves the programmer time. By the time errors happen, it's the customer's problem instead.