Tcl Me Pink

The Grid Engine test suite is written in Tcl. Tcl is in odd language. When I first started working with our test suite, Tcl made no sense to me. After I had worked with the test suite a bit and written a few tests, though, Tcl still made no sense to me. I got by by copying already existing tests and making changes. Only now, after writing a relatively complex test from scratch do I feel like I actually understand Tcl.

The real breakthrough for me came when I realized how similar Tcl is to LISP. OK. Perhaps similar is somewhat of an overstatement, but the strange way in which you have to contort your mind to write code in both languages is similar. In my opinion Tcl is to LISP as Perl is to Borne shell, i.e. more complex and more powerful.

Everything in Tcl is a string. Every string can be treated as a whitespace-separated list. There are lots of routines for doing interesting things with strings and lists. Tcl is also a functional language, hence the mind bending required to develop in it. For example, if I wanted to take the string "This-This-has-dashes-in-it", remove the dashes and the extra "This", a very Tcl way to do it would be:

set newString [lrange [join [split "This-This-has-dashes-in-it" "-"]] 1 end]
# newString is set to "This has dashes in it"

The first thing that should jump out at you is the functional programming style. The brackets indicate that the bracketed expression should be executed and replaced by the results from the execution. The next obvious thing is that most of the normal trappings of a programming language are missing. There's no parentheses (Big difference from LISP!), no semi-colon, no equals sign. I suspect the plan was to have a language that looked as natural as possible. The result, though, is something that causes the average developer to stare blankly for a few seconds while recovering from code shock. (It's like culture shock, but for developers. It also occurs when a JavaTM language developer looks at pointer arithmetic.)

Tcl also has the odd habit of treating every code block as a separate program. Tcl programs are executed from the inside out. The inner-most code block in a statement is executed first, and its results are used in executing the block that contains it. That sounds half-way reasonable until you notice that everything in Tcl is a code block. The conditionals on if statements and while loops are code blocks. Every segment of a for loop's conditional is a code block. The pervasiveness of code blocks becomes a problem when trying to debug a Tcl script. Instead of giving reasonable information about where an error occured, you get an unwinding of the code block stack that led up to the error. It's a lot like a Java platform stack trace without the line numbers.

Tcl is not all bad, though. It does have its uses. There's a reason why we use it for our test suite. I don't actually know what that reason is, but I'm sure it's a good one. Why else would we subject our developers to writing tests in Tcl?


I did tcl programming for a few years when it was the language used by Vignette Story Server before they joined the crowd and converted to Java. It made for very fast development since creating web pages is all about string manipulation, however it was not the fastest executing environment, so componentizing your page rendering into cachable pieces was critical to web page performance. I guess I am oldschool, having cut my teeth on basic and really flowered under Pascal, so I've never become a native OO thinker, I'm hardcore procedurally/functionally oriented - so your tcl sample brought back warm memories of a simpler life. With my fluency in Java I cannot come up with a one liner as elegant as the tcl:

String newString = "This-This-has-dashes-in-it".substring("This-This-has-dashes-in-it".indexOf("-")).replaceAll("-"," ");

Posted by John Hoffmann on August 12, 2005 at 01:27 AM PDT #

Not everyone has decided to ditch Tcl for their web serving needs...

$ telnet 80
Connected to
Escape character is '\^]'.

Server: AOLserver/4.0.9b

I stumbled across this as I was working on a project for a telecom company that needed to make their Tcl-based network management tool installable on Solaris. In a couple weeks, I got up to speed on the language and started to like it a bit. The ugliest part of the project was when they said "we need it to run on Windows." Writing code to make Tcl talk to things like the Windows crypto API, service control manager, etc. was kinda yucky.

The real upside of Tcl, was that all along, I was secretly developing on Linux and had it "just work" on Solaris. Once I fixed a couple architectural and style things (use file join!) having it work on Linux, Solaris, and Windows was quite simple. The Tcl-based tool could add support for a new device or blade in a couple days. The other one (C++) typically took about 6 months to get support for new hardware. I had a lot of fun the day that I found out that they were thinking of a Linux version around 8:00 and I gave a demo of it before noon.

Posted by Mike Gerdts on August 12, 2005 at 01:07 PM PDT #

How about the more self explanatory:
set newString [lrange [string map {- " "} "This-This-has-dashes-in-it"] 1 end]
# newString is set to "This has dashes in it"
I often wish that commands like split and join required the seperating character to be specified so that code like what you have written did not rely on the reader knowing that the default character for join is the space.

Posted by John Koehler on September 14, 2005 at 02:30 AM PDT #

A couple of notes: 1. TCL was developed... at Sun! by John Ousterhout. Originally it was designed to be embedded inside a typical C or C++ program so that you could script some of the functionality. 2. TCL is still going strong; have a look at one of the largest open source projects running, which uses TCL for all the programming logic (aside from some SQL logic) in this community web server toolkit. 3. The flexibility that TCL has lets you shoot yourself in the foot. since v8.0 they have namespaces so you can use mylib::foo to fully qualify what you are doing.

Posted by Patrick Giagnocavo on January 13, 2007 at 01:56 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016