My view of where TCL went wrong

February 20, 2012

Recently there was both an article and the resulting Hacker News discussion on the topic of where Tcl and Tk went wrong. As it happens, I have some vaguely heretical opinions on this.

I have two and a half backgrounds with TCL and TK. First, I've used and minorly hacked some decent sized TCL and TK applications for years, primarily exmh; for the half point, I've also written some trivial TCL/TK programs. Second, a very long time ago I embedded an early version of TCL into a program I was writing and tried to push as much functionality as possible into the TCL code. The latter experience especially left me with some strong opinions about TCL.

To put it bluntly, where TCL went wrong was in core language design and especially in two areas. To start with, TCL is simply not a very nice language. Serious TCL code is simply littered with noise and extra verbosity, where fundamental programming language operations all need additional work. Let's take a representative example:

set x [expr $i/8 + 8]

This requires two extra keywords and an extra set of []'s for what most other languages would write as 'x = i/8 + 8'. The variable names aren't even used consistently; we set x but use $i. Even Lisp manages to be more compact and regular. TCL's semantics may be simple and pure and easily written down in a short amount of text, but that doesn't mean that it's a good language; simplicity by itself is not magic.

(I half understand why TCL syntax is the way it is, but I don't think it's a good decision. One way to put it is that TCL is what you get if you half-heartedly try to create a Lisp, or compromise a Lisp in order to theoretically get greater acceptance from ordinary programmers.)

But that's the smaller problem. The larger one is that TCL adopted a terrible data model; it decided that everything should be a string. Anything that is not actually a string, such as lists or hashes, is at least nominally encoded in a string with special quoting conventions. In early versions of TCL this was quite literal and caused endless problems with quoting; my understanding is that current versions are somewhat less literal and thus more convenient. But even with the interpreter faking things to help you out this is a terribly limited data model, even worse than Perl's.

This quoting issue was the largest single problem when I tried to use the early version of TCL. It caused me serious hearburn and in the end significantly limited what I could easily do in the language itself; my final program did a lot more in C than I really had wanted it to because of this. The experience was sufficiently bad that I swore off TCL afterwards, despite its attraction as an embeddable language.

(At the time, in the early 1990s, it was your only real option for this.)

Sidebar: my view of TK

I don't really have enough experience with TK to have firm opinions on why it didn't catch on. However, my suspicion is that it was too strongly tied to TCL to work anywhere near as gracefully from other languages. Using TK from TCL makes great use of a number of TCL features in order to make code compact and convenient; my vague experience is that writing TK code in Python is not anywhere near as fluid and easy.

I also believe that TK was mostly or entirely documented only from the TCL API for a long time, which can't have helped. Even today I don't know if ordinary TK installations come with C-level API documentation.

Comments on this page:

From at 2012-02-22 19:37:41:

What is Perl’s data model?

Aristotle Pagaltzis

By cks at 2012-02-22 21:12:10:

The Perl data model issue I'm thinking of is how collections can't contain themselves.

Written on 20 February 2012.
« The most popular sender domains for spam messages sent to here
Why I still have a custom-compiled Firefox »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Feb 20 00:55:54 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.