A little Tcl story. When John Ousterhout interviewed me to be VP of Engineering at the Tcl company (Scriptics) many years ago I told him I knew nothing about Tcl at all. He told me that the two great virtues of Tcl were that it was incredibly easy to learn and had very powerful regular expression facilities (I think he was trying to contrast with Perl which also has great regular expressions).<p>I blurted out "Don't those two things contradict each other? You can't have something that's easy and have regular expressions!".<p>I immediately figured I'd totally blown my chances and discovered afterwards from the recruiter that the one thing he really liked in candidates was to be challenged. Me and my big mouth got me that job.
As others have said, most uses of Tcl was no doubt Eggdrop bots. I made an eggdrop bot to do some interesting stuff in an irc channel. I also learned nice and important lesson in the process about Tcl and dynamic execution in general (such as in SQL) : Fully dynamic execution is great as long as you spend more time checking input than actually writing logic.<p>As an example, you can do the following in Tcl as the article points out:<p><pre><code> set a pu
set b ts
$a$b "Hello World"
</code></pre>
Awesome! I'll use this kind of dynamic behavior to let users of the bot have more freedom. Bzzzzt. This was back in the 90s and the idea of 'SQL injection' wasn't as widespread as it is now... Getting around these kind of injections in Tcl requires constant vigilance and sometimes is very confusing.<p>Another interesting issue is the lack of types and how Tcl interprets them. Ask the user for a number and check if its between 1 and 3, and reject if it isn't. Works fine until the user tries the number 0x01, which matches 1 in some places but not in others. Gave me a lot of appreciation for typed languages where an int really is an int.
I actually was forced to use Tcl recently on a project, and I came across this article at the time.<p>It so happens that I was getting into Lisp at the same time, and the parallels between them are obvious. You effectively get macros, so it's a pretty expressive language. There's even an object system in Tcl based on CLOS. But ultimately, it feels like a language with lots of good ideas, implemented poorly. I'm not a PL theorist or purist, but "everything is a string" constantly feels like a really poor abstraction.<p>Tcl is practical for small, quick projects, but you soon run into insane things like the fact that curly brackets are syntactically significant in strings - and comments.
We use TCL for a couple of core scripts at work because most of the tools we spend millions of dollars on in licensing use TCL as their embedded interpreter (I work in EDA/semiconductors).<p>I find the most unproductive use of my time at work is when writing TCL code. Switching to TDD has helped a lot, but I still find the language maddeningly frustrating.<p>I hate that this is both valid syntax with wildly different meanings:<p><pre><code> set env(VAR) "value"
set $env(VAR) "value"
</code></pre>
I hate that TCL error messages have no prefix, so there is no way to grep for them (the 3rd party tools merge STDOUT and STDERR to a single log).<p>I hate that the TCL error message line numbers are RELATIVE TO THE PROCEDURE instead of relative to the file.<p>I hate that the language is fully interpreted and not compiled, so you can have a syntax error in a code branch that isn't triggered just lying there for months if you don't fully unit test every code path.<p>I do not understand how anyone could like TCL unless they were using a linting tool to give the robustness of debugging that most other languages have.<p>Because of our code base and the 3rd party tools I'm not able to lint our code and it is a brutally painful language to debug.
One of the biggest advantages of TCL in my opinion is the simplicity of its syntax. The lexer is quite simple, straightforward and easy to create. Properly written TCL interpreters are quite small and memory efficient. Because of this TCL used to be quite a popular choice as an embedded scripting language for various appliances (eg. Cisco used TCL for their VoIP/IVR scripts).<p>Nowadays Lua has mostly taken TCL's place as an embedded scripting language of choice and I must say I'm a little sorry, there are some things that I miss from TCL.
There's no shame in calling Tcl a toy. It provides a fun way to learn lispy concepts and it has helped teach many that a simple lanaguage can be powerful. But I think Salvatore was unwise even in 2006 when he said Tcl isn't a toy. He is clearly a hacker in the best sense and his writing's appreciation for Tcl shows his respect for its power and simplicity. He was not
the first, nor will he be the last, to sing such praises.<p>Sadly his apparent ignorance or lack of concern regarding Tcl's numerous flaws leads me to question his engineering maturity. For instance, nowhere did he warn of how simple typo errors in Tcl's variable names and interpolated strings leads to a layer of engineering hell beyond anything Dante imagined, a place I've been and vowed never to return.<p>If you really think you need to expose something like Tcl in your product, please think again. These days you would be better off with something like Javascript or Lua. I strongly suspect the Salvatore of 2012 would agree.
The author missed one of the other huge advantages of Tcl: it is extremely easy to add Tcl to a C++ project as a scripting language. It took me about half an hour, and I had never done it before. Once added, it makes interactive debugging of big projects almost pleasant.
For me, the best feature of Tcl is actually not part of the language itself. It's a tool built on top of Tcl -- Expect.<p>Expect can be used to automate CLI tasks, but for me it is indispensable for testing programs with text-only UIs (I get to write a lot of those).<p><a href="http://www.nist.gov/el/msid/expect.cfm" rel="nofollow">http://www.nist.gov/el/msid/expect.cfm</a>
If any of you wonder whether you use an application everyday that still utilizes Tcl/Tk, you may be surprised (<a href="https://github.com/git/git/tree/master/git-gui/lib" rel="nofollow">https://github.com/git/git/tree/master/git-gui/lib</a>).
So, here's this article purporting to answer the misconception that Python is superior to Tcl in every conceivable way and, erm, I left with the impression that Python is superior to Tcl in every conceivable way except that Tcl is a smaller language. If you really want to do meta-programming in Python by putting together strings then eval() is right there waiting for you... but there are good reasons people try not to overuse it.
I use TCL in a consumer app that I develop, to allow users to load and run scripts that control the behaviour of the app. Its for controlling cameras (smart shooter), and actually I usually end up writing the scripts for my customers. But its amazing what you can achieve quickly and easily due to how flexible TCL is, users are amazing when I email back a custom script for some fancy HDR photo bracket the same day they request it!<p>And I myself am surprised at how many photographers have managed to write their own scripts, even non-programmers. I've been thinking about adding support for python as the scripting language, but I can't justify it just for been fashionable.
My first experience with Tcl was before I knew anything about programming. Tcl was the scripting language for Eggdrop IRC bots, which back in the day was pretty much the only IRC bot around: <a href="http://en.wikipedia.org/wiki/Eggdrop" rel="nofollow">http://en.wikipedia.org/wiki/Eggdrop</a>.<p>I remember being annoyed by Tcl back then when I was modifying existing scripts. Although now I can see that it probably isn't the easiest language to learn for a beginner.<p>I'm sure a lot of people's first, and probably only, experience with Tcl was from Eggdrop bots.
I had to use Tcl/Tk for a Uni project way back when, at the time I wasn't a fan but I looked at it again slightly later and appreciated how powerful it could be when you scratched the surface. It's definitely misunderstood, but if people give it a chance there's a lot to like.
My first real programming job involved building web apps using OpenACS - <a href="http://openacs.org/" rel="nofollow">http://openacs.org/</a>. OpenACS was all Tcl executing in AOLServer and used postgres or oracle. It was awesome.<p>I Learned a lot from "Tcl for Web Nerds" and its companion "SQL for web nerds" (all links listed here: <a href="http://openacs.org/doc/" rel="nofollow">http://openacs.org/doc/</a> ). Back when I started Tcl, I was more like a emacs-lisp script kiddie. Because Tcl was so easy to learn and because OpenACS was such a great MVC style framework, it didn't take long to master the framework itself and dive into the interesting things that were related more with the architecture of a web-app and not just the syntax of a programming language.<p>The "whereas" poem, as I like to call it, that announced Miguel Sofer's inclusion in the Tcl Core team was real fun to read too - <a href="http://code.activestate.com/lists/tcl-core/1983/" rel="nofollow">http://code.activestate.com/lists/tcl-core/1983/</a><p>Miguel Sofer had described an algorithm for representing hierarchical data in a RDBMS. What he put forward could be thought of as a different kind of a nested set representation. Whereas the nested-set approach involved keeping track of two numeric values (left & right) for each node in our relational records based tree, Miguel Sofer's algorithm would use the ability to lexically sort a base159 encoded string. This way, tree operations could be implemented via sub-string matching and sorting.<p>His algorithm was implemented in OpenACS because it allowed an efficient implementation of the OpenACS nodes table. Each URI in OpenACS has a node record associated with it and all these nodes are hierarchical records - <a href="http://openacs.org/forums/message-view?message_id=16799" rel="nofollow">http://openacs.org/forums/message-view?message_id=16799</a><p>The OpenACS nodes system allows the implementation of a fine grained permissions system which enables a child node to auto-magically inherit the permissions of its parent node - this is, if the child node didn't have any specific permissions set on itself - <a href="http://openacs.org/doc/permissions-tediously-explained.html" rel="nofollow">http://openacs.org/doc/permissions-tediously-explained.html</a><p>When I was learning ruby I implemented this algorithm using active-record - <a href="https://github.com/gautamc/hierarchical_objects" rel="nofollow">https://github.com/gautamc/hierarchical_objects</a> The utdt.edu link hosting the pdf that Miguel Sofer created is broken now; I found a copy here: <a href="http://www.tetilab.com/roberto/pgsql/postgres-trees.pdf" rel="nofollow">http://www.tetilab.com/roberto/pgsql/postgres-trees.pdf</a>
For a while TCL was also the state of the art in web applications development:<p><a href="http://en.wikipedia.org/wiki/AOLserver" rel="nofollow">http://en.wikipedia.org/wiki/AOLserver</a>
With all the discussion about the syntax, some of Tcl greatest features are overlooked.
The article could do with an update. I would like to see the current state of Tcl compared to node.js
Possibly the tcl core beats node.js on many points.
A few years back I researched for a scripting language for an embedded project. The choice came down to Tcl, Lisp and Lua. We went with Lua and liked it a lot.<p>After reading this article I wonder how Lua and Tcl compare. It seems like Tcl is more like Lisp than Lua really. Does anyone have experience with any two of those languages and would care to comment on their differences and similarities?
My exposure to TCL, or rather dialects were through Autodesk Maya (The MEL Script there seems a bit like TCL, IMHO). The other thing was Metal Gear Solid (PSX). Konami used TCL to set up the level entities - enemies, traps, etc. Internally each command was hooked through a "C" function that took argc, argv, and to my shock (and then grin), there were tons of "C" functions that we working like main() - e.g. parsing arguments. For a moment I thought - this must be slow, then I understood - it did not matter - it served it's job, and allow non "C" programmers (game designers, scripts) to set-up objects easy in the "C" world. The whole thing had to fit in 2MB along with textures.<p>Later working at our studio, I've stumbled on couple of sound tools written in TCL, and lately had to dabble once in a while in the MacPorts land (also TCL).<p>But then most of the people I've asked they don't know about it...
I love this article. The few times I've worked with Tcl I've found it an absolute joy to use. I just hope that people don't mistake his conclusion.<p>The core benefit to Tcl is also its main detriment. Tcl takes off in places like OpenOCD because its incredibly powerful simplicity makes it incredibly tiny. You can throw it in pretty much anywhere as an embedded language and it will buy you a TON of functionality. If you want it to be performant, however, you'll wind up writing a lot of piecewise optimizations which will ultimately cause you to lose the size benefit.<p>So no, it's not a toy language by any means. And yes, its simplicity yields incredible LISP-like power. However, it's not a language I'd _ever_ use to write the core of anything where performance is of concern.
Never used Tcl, nice overview.<p><pre><code> set a pu
set b ts
$a$b "Hello World"
</code></pre>
Seems pretty cool.
uplevel is neat as well. The modifications = DSL approach seems interesting, too.
Shorter Tcl Complainers #1: Why does Tcl require me to learn how to use it instead of just letting me carry over my assumptions from other languages?<p>Shorter Tcl Complainers #2: Why does Tcl punish me for my insistence on following bad programming practice?<p>Shorter Tcl Complainers #3: I hate Tcl because of traits it shares with several popular languages which I love!
I usualy use Tcl for my personal projects. It's nice and simple but powerful language, and the only real problem with it is that there's too many old libraries that can't work with multiple but different versions of Tcl on the same system.
I like Tcl. I like that it is quirky and that it different enough (non-algol) to be interesting to me. I like the folks in the community as well. BTW 8.6 is just around the corner.
I wrote a lot of Tcl back in my days and the one thing I remember is the awful scoping rules, e.g. if you want to reference a global variable, you need to say so first, otherwise you'll be referring to a non-existent local variable and you won't get any error, just an null value.<p>It was horrible.<p>Tk was nice, though.
My first job coding was in Tcl/Tk. it was a vendor system for trading,accounting and only supported Tcl/Tk even for APIs. It was fun. I had never heard of Tcl before that.
I think people who used Tk with other languages (which TBH it didn't really fit cleanly with) were scared away from Tcl.<p>I never found a use for Tcl myself but I had no problem with it.
Here is SICP author Hal Abelson's treatment of Tcl from yesteryear: <a href="http://philip.greenspun.com/tcl/" rel="nofollow">http://philip.greenspun.com/tcl/</a><p>There are more legacy Tcl articles at "reddit.com/r/tcl".