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.
 

Comments:

AndrewBinstock
2014-01-22T07:02:55

Agreed. I think Lua is to games what Tcl was to tools. But with a friendlier syntax. And as you know, LuaJit means the performance is superb.


Permalink
ubm_techweb_disqus_sso_-12013654d015384efe1eab46e654cc19
2014-01-22T06:19:24

Hi Andrew,

+1 for mentioning Lua :)

I have used the integrated tclsh on csco routers - and it's not very pleasant!

And on the language front - there could be lot of deployments which use TCL, but /today/, if I were to pick an embeddable language, that is user friendly [1], performs well, has all neat features and good reusable libraries, I will pick Lua[JIT].

[1] when I say "user friendly" I mean - the syntax very easy to grasp for developers with experience in imperative languages like C/Perl etc.


Permalink
ubm_techweb_disqus_sso_-e05f6a2dc54437c0fd01772747b9dd29
2014-01-22T01:19:31

Sorry, but I take issue with Andrew's comment "It enabled developers to do things that were simply not possible before."

Our company develops applications that leverage MS speech recognition and text to speech capabilities.

Given that we may have overlooked related features and facilities, a presentation was given to one of the SR product managers to determine what we could do better.

In addition to exceedingly positive statements about our solution's capabilities he asked about the language used in its development...but hastily added "Wait...I think I know the answer...it's TCL!"

Given that we view the use of TCL as a competitive advantage, we asked "How could you possibly know."

His answer: "Cause you couldn't have built your product with any language that we (Microsoft) offer to the development community".

Net: "Even today, TCL enables developers to do things that are simply not possible otherwise."


Permalink
ubm_techweb_disqus_sso_-c1319b5c2a8b278ec6190de7d1d46918
2014-01-22T00:21:02

Stroustrup may well have been making his comment in reference to my criticisms of C++. What he is implying - if you read between the lines - is that if there is little to criticise in a language, it is of little practical use. It is that thought that I strongly refute - a programming language can be both elegant (little to complain about) and practical at the same time.

I also agree with your observation, Andrew, that putting everything into one of two categories is over simplistic. This comes from the C philosophy that there is C and then there are teaching languages with training wheels (in reference to type-checking systems). This thinking has long been used to reject the many tools and techniques that we now know are needed for large-scale software production.


Permalink
AndrewBinstock
2014-01-21T22:34:33

Ron Fox of Michigan State University sent me a lengthy note about Tcl usage today. He has graciously allowed me to post it here (in slightly abridged form):

Tcl itself is very much alive and well. While, as you say, the use has declined and its visibility has declined still further there are still significant products that are very much dependent on Tcl.

Perhaps the largest use of Tcl underground has been as the command language for CISCO routers.

Getting back to its roots as a language for scripting
electronics design and simulation products, Tcl figures prominently as the scripting and user interface products of the Mentor Graphics product line.

Flightaware.com - flight tracking website is entirely Tcl
powered as well.

Here at the NSCL Tcl pervades every aspect of data taking and analysis. It is used to expose a scripting interface to users of our software as well as to provide both fixed and highly tailorable user interfaces.

Tcl is a language that is in active development with the
recent release of Tcl8.6 by the Tcl core team which took over the language when John Ousterhout moved on to other things.

There is an annual US Tcl conference that grew out of but now is independent of the Usenix Tcl conference. There is also an annual EuroTcl conference as
well. The Tcl conference in the US is organized by the Tcl Association at http://www.tclcommunityassocia... Conference proceedings are published by Tcl
Association Publications. The most recent conference was held Sept 23-26,2013 in New Orleans (proceedings ISBN 978-0-578-13517-5).

Ron Fox
Publications editor of Tcl Assocation Publications.


Permalink

Video