Why won't Tcl die?

Question

I've been forced to code in Tcl a number of times, and just can't wrap my head around this language.

It's not just that it is syntactically different than c-like languages: Lisp is different but genius, prolog is different with a valid cause. Tcl is different because it was a bad idea taken to its fullest possible extension.

"Lets make a language where the operator is on the left, just like a shell. When that runs out of gas we'll extend it a hair by letting you have sub-commands in square brackets. And when people notice that it is odd that there are no binary operators we'll extended it by nailing a different language onto it." (The expr syntax is not tcl, it is c-like.)

Yet it survives, especially in the embedded space. Perhaps because it has a small footprint. But there must be a dozen languages with a small footprint that are easier to code in. Is there some magic goodness I have just missed?

Here is a small Tcl example to refresh you on Tcl. Notice for instance the need for a $ before a variable when reading from it but not writing to it. How did every single other language manage to work that out without needing a hint from the programmer!? Recall that it would be a syntax error to omit the space between the while and the { because the parser itself is written in four lines of Tcl and can't deal with crazy stuff like that. Notice that an idea as simple as p-- takes a whole 8 tokens.

proc power {base p} {
    set result 1
    while {$p > 0} {
        set result [expr $result * $base]
        set p [expr $p - 1]
    }
    return $result
}

Answer 1

It's a good question, and I'm really not sure. I've had to program in it a few times, and I just don't understand the advantage. Every time I look at a block of Tcl code that does anything significant I get a strong feeling that I must have missed something.

Answer 2

Tcl gets a lot of hate, and yes, it's a little different than what most people are used to nowadays. If you never really liked shell-script (or make, for that matter), you'll probably dislike Tcl; however this is a very subjective thing - some people love it. Much of the hate comes from misunderstanding the syntax - simple yes, but subtle. Many people just have a mismatch with the way they like to think, though I'll freely that admit it has its ugliness.

But if you're operating in a situation where shell-script is nearly appropriate, but just a little too clumsy for the task at hand, Tcl can be a very handy middle ground; after all, that's what it was designed for. Heck, some of its features are still lacking in many mainstream languages (easy async I/O springs to mind, as well commands like "after" and "vwait").

To address the question at hand though, Tcl would seem to survive because:

1. It's available just about everywhere, and it's been around long enough to have many of the kinks worked out.
2. It has excellent documentation
3. It has a large collection of software implemented using it; and who really wants to spend the money to change if it works well enough?
4. It has a niche, and fits it well
5. Tk - hard to beat for a quick and easy cross-platform GUI; I mean, most "modern" scripting languages support Tk out of the box, which means that there will be a Tcl interpreter floating around. Tcl/Tk was a lovely alternative to C/Motif at the time, and Tk is still surprisingly usable, especially with the recent updates for 8.5

However, it isn't trendy, and is widely vilified, so its looking more and more likely that it will gradually fade away as a language and live on mainly through legacy applications and Tk bindings.

Answer 3

The machine understands it fine. Why does it have to die?

If you're the maintainer, remmeber that for the implementer at the time, it is the most useful/well known thing. If there are no maintainers for the tool you're using it may be best for you to rewrite it in something you and your peeps know better. Remember that for every technology that you hate, someone else knows it and finds it useful.

Answer 4

Tcl is easy to learn, and Tk is even easier, compared to other GUI languages. I learnt Tcl before Perl, and I liked it. Code in Tcl is more readable than Perl, however their purpose are similar. Tk has a great role in not letting Tcl lost in the shadows.

Answer 5

So, your example is to compute a factorial, and name your function "power"? Interesting. As for decrementing, "incr p -1" is perhaps better here, if the number of "tokens" is a concern.

As for why Tcl won't die - it just works. I use Tcl pretty extensively, and it is a very consistent language. 12 syntax rules is all you have to learn, and a relatively small number of built-in commands. It is very natural to prototype in Tcl, and move parts to C as needed. As noted in other comments, Tk is a very nice and flexible toolkit, and at the time it was in widespread use, it was perhaps the best multi-platform GUI toolkit, so there is a lot of support for it.

There are a lot of options for interfacing with existing code. For example, you can use SWIG to generate Tcl bindings for an extension, you can use critcl to compile C code (usually dynamically generated) within your script and then call it, you can use ddl, ffidl or others to call non-tcl aware library functions without any binding code. With TclBlend and Jacl you can call java code, or embed a scripting language in Java code. Twapi lets you call the Windows API functions.

It is easy to embed as a scripting language in a C program. It is easy to strip it down and add functions to create a domain specific language to drive external libraries. It is easy to use sdx or starkit or freewrap to generate a single binary executable, with all package extensions included with your application scripts in a virtual file system. Under Linux now, there are a lot of FUSE extensions that allow all kinds of cool file system extensions without having to get into kernel hacking.

Not that other dynamic language don't have many or all of these, but Tcl has been around for quite a while, is quite stable, works, and has a very helpful user community. There just isn't a reason for it die.

Answer 6

And expect is pretty useful, which also carries Tcl along with it.

Answer 7

The standard libraries that ship with Tcl distributions are extremely helpful for setting up test environments.

For instance, I recently needed a bare-bones SMTP implementation to verify that email was being sent by the system I was developing. Using the Tcl smtp library let me set up a local SMTP server in less than a minute. I've done the same for a quick TFTPD server.

Answer 8

Tcl also provides an excellent platform on which you can build large tools. Its package mechanism works well for incrementally loading functionality through shared libraries, as well as handling dependencies.

Plus, for a different view on why Tcl is good, read: http://www.yosefk.com/blog/i-cant-believe-im-praising-tcl.html - he makes a nice argument for using Tcl's syntax.

Answer 9

Adding more reasons (and seconding reasons already posted):

1. The language syntax has only 11 rules - brilliantly simple once you know them!
2. I have never used another GUI toolkit where I could create a UI quicker and with fewer lines of code. pack [button .b -text "hi" -command exit] - elegantly simple to create UIs quickly. I'm sure that same button would have taken me at least 5-10 lines of code in Java, C++, even Perl/Tk.
3. Cross-platform simplicity. Truly write-once, run anywhere, even with a GUI toolkit. No recompiles, just run it. And with Tclkit/Starkit, writing a simple tool you can deploy nearly anywhere gets even simpler.

Answer 10

Well it sounds probably lame but "Practical Programming in Tcl and Tk" is one of the best books about a programming language. Interfacing Tcl to C is one of the easist of all scripting languages and Tk is the base for every other portable GUI for any other Scripting language. Just have a look at the implementation, it's wonderful piece of well written code and last but not least check OpenACS, which uses AolServer. It's an excellent tool for web development, and with most Scripting languages it shares wonderful features to mangle strings.

Regards Friedrich

Answer 11

The industry I work in has incorporated Tcl into the command line interface of many applications. It allows our users to have access to a basic set of commands and the ability to write their own procedures which can call any of the commands our application provides.

i was skeptical about it when I first started using it, and my boss still hates it, but I now often find myself using Tcl where I might have used Perl. I recently wrote a huge set of Tcl scripts to checkout, build and run a standard suite of unit and regression tests after every check in. We can pull some of the procs out of this system and use them in our application code when necessary.

Answer 12

A demonstration of the active community is http://wiki.tcl.tk

Just type in something you want to do with tcl and it -will- find it.

The trouble with tcl (sounds like a star trek episode) is like with any other language: if you use it wrong, it can be a real mess. But with tcl, the mess will just be a bit more. Be kind to it, and you'll hardly see any limits to go your way.

Answer 13

TCL won't die because I like it :)

It's been ages since I coded anything in TCL, but the thing I remember was the ease of interpolation/substitution/escaping. Our network engineers built entire language in TCL, essentially reinventing Literate Programming. The driver for network device was also the documentation for it.

And, by the way, a better way to say

set p [expr $p - 1]

is actually

incr p -1

What other gems could you discover?

Answer 14

I use Tcl extensively, and the only thing I don't like is expr. It's already been pointed out by others that you didn't need expr in your code, but I still agree with your main point -- expr's awkward. However, that is absolutely all that I dislike about Tcl. For the rest, it's a great language that I find makes me very productive.

One of the things I like most about Tcl is that it's easy to make domain languages, including new control structures. It also has some great string-handling capabilities that (along with eval) allowed for this HTML parser to be written in 10 lines (created by Stephen Uhler):

############################################
# Turn HTML into TCL commands
#   html    A string containing an html document
#   cmd  A command to run for each html tag found
#   start   The name of the dummy html start/stop tags

proc HMparse_html {html {cmd HMtest_parse} {start hmstart}} {
regsub -all \{ $html {\&ob;} html
regsub -all \} $html {\&cb;} html
set w " \t\r\n" ;# white space
proc HMcl x {return "\[$x\]"}
set exp <(/?)([HMcl ^$w>]+)[HMcl $w]*([HMcl ^>]*)>
set sub "\}\n$cmd {\\2} {\\1} {\\3} \{"
regsub -all $exp $html $sub html
eval "$cmd {$start} {} {} \{ $html \}"
eval "$cmd {$start} / {} {}"
}

A couple of people have mentioned Tk, and that is an important draw for me, also. One the great things about Tk is that it is so straightforward to create GUIs that it actually gets in the way to use a GUI layout program. Heck, just code it. GUI layout programs are there because you have to say where everything goes. With Tk you just say how things are placed relative to one another, and how they should behave when the window is resized. The geometry manager takes care of the rest.

BTW, to me, the code at the top of this thread looks clumsy. It looks like it was ported directly from another language. For one things, it's begging for recursion -- in any language. It is important to realize that people who code regularly in Tcl (like me) can generate much better code, and really good Tcl coders (better than me) write extremely compact code that does a lot in a very few lines.

Answer 15

TCL has a bit of a learning curve if you are coming from a C-style language, but it persists due to the power in its simplicity. It is (relatively) easy to script together a test suite using command-line tools (without requiring any modification to the tools), which in the Windows environment can give you a lot more power and flexibility than is available through batch files. I can simply write a script and call DOS/console tools like they were functions in the language. Many TCL implementations also give you the option of using the TCL console, executing instructions as you type them and giving a more powerful alternative to the DOS console.

As to some of the comments on the OP's code, it looks like the code was written as a translation from some other language (or some other language's mindset). You can actually do quite a lot in a few lines of TCL once you understand the language's paradigm.

Answer 16

tcl is pretty amazing, it's a real sleeper. In other words, your first impression is not very good, but as you learn more and more about it you realise what a real gem it is.

For instance my first impression of tcl was that it was rather verbose. I could not have been more mistaken. I'm constantly amazed by the small size of tcl programs that do amazing things.

But aside from that, I have reach for tcl when I need something cross platform. I don't think I've ever had to "port" a tcl program to windows (I develop on linux), it just worked. I'm talking about graphical TK based applications, not just trivial scripts.

Answer 17

It's not just that it is syntactically different than c-like languages: Lisp is different but genius, prolog is different with a valid cause. Tcl is different because it was a bad idea taken to its fullest possible extension.

Think of it as "Lisp with no data types". It kind of makes sense then, in a funny sort of way.

"Lets make a language where the operator is on the left, just like a shell. When that runs out of gas we'll extend it a hair by letting you have sub-commands in square brackets. And

Square brackets simply mean to evaluate it. In Lisp, () means eval, '() means quote; in Tcl, [] means eval, {} means quote. It's not that bad.

when people notice that it is odd that there are no binary operators we'll extended it by nailing a different language onto it." (The expr syntax is not tcl, it is c-like.)

It's also one of the things I think Tcl got really right. Algol-like arithmetic is one of the biggest complaints about Lisp, even though you rarely need it. Tcl has both the consistency of Lisp, plus a function that gives you Algol-style arithmetic when you do need it.

Yet it survives, especially in the embedded space. Perhaps because it has a small footprint. But there must be a dozen languages with a small footprint that are easier to code in. Is there some magic goodness I have just missed?

There's nothing magic, but then, there's nothing magic about any language. If they're useful, they survive.

Here is a small Tcl example to refresh you on Tcl. Notice for instance the need for a $ before a variable when reading from it but not writing to it. How did every single other language manage to work that out without needing a hint from the programmer!?

All homoiconic languages tend to have issues with quoting, because you need to be able to refer to "the name X" and "the value of the variable X" separately. In Lisp your line might be (set 'result 1), for example (at least before SETQ was invented). Take away homoiconicity, and some things get easier, but some things (like macros, or a way of simulating them) get much, much harder.

If you can come up with a way to do everything elegantly, I'm sure the Python people would love to hear about it. :-) But Lispers have been struggling with this for decades, to the point where Steele and Gabriel said (in 1992) "Perhaps this process should be regarded as a rite of passage for Lisp hackers". Nobody has yet found a way to make a programming language that does everything perfectly.

Notice that an idea as simple as p-- takes a whole 8 tokens.

"incr p -1", though it's common enough many people write their own "decr" to do this.

Answer 18

I use TCL extensively. I am a systems engineer, not a software engineer. As far as I am concerned if it can't be done in WatFive FORTRAN or TCL, it isn't worth doing, i.e. MS Word.

Answer 19

TCL was one of the first languages I learned, and I've loved it ever since for quick and dirty programs to get things done. The syntax can be learned in about 10 minutes, and the fact that everything is a string makes type handling a breeze. When I went from TCL to strongly typed languages like Java/C++ it drove me crazy always having to convert user input strings to integers or whatever other type I needed.

Some of the things you complained about are what make it nice.

Recall that it would be a syntax error to omit the space between the while and the { because the parser itself is written in four lines of Tcl and can't deal with crazy stuff like that. Blockquote

The reason for this is that everything in TCL is really a proc. While? If? For? It's a proc. It takes input arguments, does something, and produces an output. If you want, you could override the while proc yourself, if for some crazy reason you wanted to. Once you realize all the data being passed around are strings, mostly all the keywords are procs, and the basic syntax of the language, you can wrap your mind around it.

I can write a program to open and modify files with regular expressions, make a simple GUI application, or even make a client/server chat client in just a few lines of code. Doing any of these things in another common language would almost certainly result in more code.

Plus, the fact you can launch interpreters inside others and that it supports threads make it great for gluing together other applications.

The only real downside to TCL is that the OOP libraries for it are not only sometimes lacking, but competing. It's a case where choice isn't always a good thing since it leads to compatibility issues. I think if it TCL had gotten a better OOP library early, it would have been a good competitor against Ruby.

Answer 20

There are some idiosyncrasies when you get deep into tcl. I don't like the (mis)use of upvar, uplevel especially. TCL's main problem is that it is so easy to learn that your average dummy engineers who are afraid to touch C/C++ will start producing crapware a lot quicker than your good engineers can clean up. TCL tricks you to think that it is really simple but try explaining the following to a dummy and see how long it takes:

> set foo {abc(\d)}
abc(\d)
> puts $foo
abc(\d)
> puts [lindex $foo 0]
abc(d)   <<<<<<<< where did the backslash go?