Channels ▼
RSS

Design

A Quarter Century of Tcl


Bjarne Stroustrup, the creator of C++, once said with reference to criticisms of his language, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." While Stroustrup is quick to point out that formulations of the type "there are only two of x" should be taken with a grain of salt; it's important to note that there truly are several other categories of languages.

For example, the small group of languages that are both used and widely loved. In general-purpose languages, I think Ruby comes very close to this ideal. In niche languages, Lua definitely reaches the mark. One tier down are languages that are mostly loved, but abide pockets of critics here and there. Python, for example.

To these three categories (criticized, not used, and loved), we should add a fourth category: languages that are little used today, but have had a significant effect on computing. Three of them come immediately to mind: Lisp, Smalltalk, and Tcl. The youngest of these is Tcl, or what was once called the "tool command language." This week, Tcl celebrates its 25th anniversary — that is, a quarter of a century since it was first implemented by John Ousterhout at Berkeley (its actual release would come a while later).

Tcl was designed to eliminate a frustrating problem: the profusion of package-proprietary domain-specific languages (DSLs). Ousterhout was hoping to create a widely adopted scripting language that would be embedded by vendors in to larger software packages as a universal programming extension. He reasoned that an easily embeddable engine with a highly structured, but fluid, syntax would be a better solution than the numerous vendor-written languages.

His solution worked: It became, for many years, the preferred scripting engine for numerous high-end tools. This embedded context is where most developers first encounter Tcl. Far fewer programmers use it as a general-purpose language for building greenfield applications (although that use case does exist).

Tcl's design is a curious thing with much to marvel at and a lot of quirks to consider. For all intents, every line of code is a command, most often followed by arguments, which vary from simple values to complex expressions. Each statement, then, can almost be thought of as a command line with arguments. Under the hood, Tcl uses an interpreter to translate the commands into actions. This interpreter is itself highly plastic. For example, commands in the language proper (such as if - yes, if is a command) can be redefined.

Tcl  is easy to embed because of its portability and its simple integration with other languages, most especially C. Tcl scripts can do all sorts of work while moving data back and forth easily from the larger package. It is, in this sense, a toolmaker's dream.

It would never have broken out of this niche, however, were it not for Tk, its GUI toolkit. Tk solved a vexing problem — how to easily create user interfaces. Even today, a considerable amount of ceremony in Java, C++, or C# is required for even simple interfaces with one or two controls/widgets. In the days when Tcl was hitting its stride, the amount of ceremony was hugely greater than it is today — to the point where experimentation in interface design was truly painful. But even by today's standards, can any language top this brevity?

button .hello -text "Hello, World!" -command { exit }
pack .hello

Actually, this can be all put into one master command:

pack [button .hello -text "Hello, World!" -command exit]

This line creates a button with the indicated text (which exits when clicked). If I want to specify the typeface, the color of the button, its size or location, then I tack on more -arg value pairs to the original command line. With this spartan syntax, it suddenly became possible to prototype GUIs quickly using Tk. Moreover, packages themselves could use Tk for their own UIs. So the embedded language moved from being a programmable extension to an integrated part of the software. At the time, this was a significant breakthrough made all the more important because the widgets in Tk were portable (although heavily influenced in their look and feel by Motif.)

The simple syntax made Tk the natural GUI toolkit for then-nascent scripting languages. As such, it became the default GUI toolkit for Python (TkInter), Perl (Tkx), and Ruby.

It also led to a second major extension of Tcl's reach — the Expect project, which was a popular sysadmin tool. Expect enabled scripted interaction with utilities that exposed a text-based interface. For example, here's how an automated FTP session would be done:

spawn ftp $remote_server
expect "username:"
# Send the username, and then wait for a password prompt.
send "$my_user_id\r"
expect "password:"
send "$my_password\r"
expect "ftp>"
# Switch to binary mode, and then wait for an ftp prompt.
send "bin\r"
expect "ftp>"
# Turn off prompting.
send "prompt\r"
expect "ftp>"
# Get all the files
send "mget *\r"
expect "ftp>"
# Exit the ftp session, and wait for a special end-of-file character.
send "bye\r"
expect eof

This easy scripting eventually moved Expect into new areas, particularly test automation, where it is still widely used today. Pure Tcl, too, has a place in testing, particularly for testing C code. For example, SQLite, which started as a Tcl extension, relies on more than 30,000 Tcl tests.

Tcl's popularity has declined during the last 10 years due to factors both political and technical. In addition, the rise of general-purpose scripting languages with more conventional syntax has siphoned off developers who would previously have worked in Tcl.

However, what can be said of Tcl that can be said of few other languages is perhaps the highest compliment any language can receive: It enabled developers to do things that were simply not possible before.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy
Google+


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video