Karl Lehenbauer

If you need to program some interaction between a pseudo-user and the processes, Tcl could be really useful. (See Don Libes' "expect" program.) You might write Tcl programs that scan the results and notify you via email of problems. Also in Tcl you can read or write to files which are actually pipelines to subprocesses you've created, and in Extended Tcl you can execute Tcl-flavored system calls like pipe, dup, fork, wait, and execvp, which gives you as wide a range of subprocess management possibilities as C. Further, if you wanted to do something weird like generate the shell scripts that'll be executed on the remote hosts, the fancy string processing stuff in Tcl could be very handy.

: Also, a short list of examples where tcl has done easily what other languages or applications can't would be a big help. For instance, the stuff about regexp in the man page seems to be about the same as emacs. Why is tcl better than a system call in C?

The biggest thing, in my opinion, is that Tcl provides a royalty-free way to include programmability in a target application. Most of the most popular applications, it seems, have some form of end-user programmability. For example, Microsoft Word and Excel, dBase 3, even Word Perfect. In the Unix world there's emacs, mush, awk, perl and the shells themselves.

In comparison to C, in my opinion, Tcl provides the following advantages, among others that I haven't thought of yet:

It's a freely redistributable embeddable language, as mentioned above.

Strings are of arbitrary length. We've had them up to megabytes. You know what a pain it can be to do string, er, character array management like that in C. When you have a list of filenames, it's nice to know that you're program won't crap out if it gets above XXX characters.

Strings are just, in general, easier to use... to concatenate, to search, parse, etc. Oh sure, you *can* do this stuff in C, but most people take shortcuts that can fail if the size of something exceeds a limit, etc, and it's still more tedious anyway.

Because it's interpretive, you don't have to wait on compiles, and you can execute routines directly by typing the commands into the interpreter, which is nice. You can use this capability to write test suites and then do regression testing when you make changes. People have even added Tcl to applications for just this purpose.

Since it has an ability to demand load code, with an upward compatible demand-load-from-library capability in Extended Tcl, a good mechanism is provided to allow reuse of code. Also, since strings are the basis of all data types, it is easy to write reusable code, because many of the routines one writes don't get bogged down in the specifics of the data they're managing and thus are very general. For example, the list union and intersection functions in the TclX procedure library can be used for writing functions to diff directory trees.

Tcl has, in my opinion, all of the advantages of writing shell scripts versus writing C programs in terms of higher productivity, when appropriate.

Extended Tcl is, again in my opinion, superior to writing shell scripts with the usual mix of sed, awk, grep and so forth for at least the following reasons:

Tcl scripts tend to do far fewer fork/exec cyles than their shellscript counterparts. I have found that shell scripts recoded in Tcl typically execute ten to twenty times faster; I have seen as much as a 40X improvement, and never less than 5X.

Tcl programs are more readable than shellscripts or perl programs. Tcl achieves its results mostly through calls to commands and procs, and not through the complex syntax that abounds in perl and the shells. Thus, Tcl programs should be less expensive to maintain.

Tcl procedures receive formal arguments as named variables with default values that can be optionally specified in the procedure declaration. The shells don't, at least none of the really mainstream ones.

The file scanning and matching stuff in TclX makes it a good candidate for replacing most awk programs. Some of the frustrating things about awk, like how you have to kind of invert certain programs you write, for example, what you have to go through (in awk) to search for one pattern and, after you find it, search for a different one. That stuff is easily done in Tcl through the use of multiple scan contexts.

Scanning files in TclX has really good performance, too. I've found that TclX can significantly outperform standard System V grep when there are enough invariant characters in a pattern for the (totally transparent) Boyer-Moore prescanning to kick in, and not very many lines in the file matching one or more of the patterns.

Also, all the reasons given above for Tcl versus C.

I used to love to use SNOBOL whenever I needed to massage text. And on Unix you massage text a lot. Tcl gives me everything I need to do the things I used to do in SNOBOL, with the advantage of a more modern syntax and better integration and extensibility through its C programmability. I can't speak about Icon since I've never done anything serious with it, but it looks pretty cool.

Finally, if Tcl catches on as an embeddable language, the time would come when sophisticated users didn't have to learn one language to program their mailer, another for their communications program, and yet another for news. Not only does having all of these different languages cost programmers the time to learn them, but then many people suffer from a worse environment because they don't have the time or inclination to learn how to program their debugger, etc. Also, many of those little cooked-up application-specific languages have maddening limitations. Inevitably, you end up needing a general purpose language with application-specific extensions once the sophistication of the programs reaches a certain point. I think Tcl stands up very well in terms of being complete enough to actually write sophisticated scripts in. For example, the Tcl-based backtracking eight queens solution that's included in the TclX release.

 sysop of Sugar Land Unix

Category Person