5 ms·

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 e

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/ 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.

fundabulousrIII 9y ago
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.
- fusiongyro 9y ago
  Old is relative, but there aren't many alternatives to Tcl that are older.
  - fundabulousrIII 9y ago
    Good point.
  - throwaway135634 9y ago
    Depending on your exact use case, Forth might be one
sigzero 9y ago
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.
anonacct37 9y ago
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-introduction-to-irules https://devcentral.f5.com/articles/irules-101-01-introductio...
jrapdx3 9y ago
> "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.

fundabulousrIII 9y ago

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.

fusiongyro 9y ago
Old is relative, but there aren't many alternatives to Tcl that are older.
- fundabulousrIII 9y ago
  Good point.
- throwaway135634 9y ago
  Depending on your exact use case, Forth might be one

sigzero 9y ago

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.

anonacct37 9y ago

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-introduction-to-irules https://devcentral.f5.com/articles/irules-101-01-introductio...

jrapdx3 9y ago

> "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.