The strength of Tcl

Tcl is a programming language - a scripting language in fact. It has been around for fifteen years. Most programmers have never heard of it, a few people like it, a few don't. Below are my notes on what I consider useful and valuable about it. If you want religious statements, a side-by-side comparison with <insert-your favorite-language>, or a list of what's wrong with it: sorry, you'll have to go elsewhere...

Dynamic types

Tcl's #1 strength has to be its dynamic datatypes, i.e. the lack of having to specify what type a value is: integer, string, list, etc. In static languages such as Java and C/C++, types are set at compile time. There are a number of variants of dynamic data types, which all scripting languages seem to have in common. In Perl, values have a type, but some of them can change depending on use (e.g. adding string representation of numbers). In Python, each value has a fixed type which can determined (ints/strings are immutable, lists/dicts are mutable). In Tcl, values do not have a fixed type - it depends entirely on usage.

Note that dynamic datatype is not the same thing as runtime typing, which is about being able to store differently-typed values in variables and other containers.

Is type-less coding, i.e. the combination of runtime typing and dynamic datatypes, a good thing? Just asking this is probably the easiest way to start a fight amongst programmers. I'll just summarize that after over 30 years of programming, I've seen many sides of this and consider the answer to be "yes". A lot of algorithmic code and a lot of administrative code (in the sense of administering data) does little more than pass around data without actually acting upon it. All of that just works regardless of what information is represented by each data value. Databases, GUIs, even something as "computational" as sorting and searching - it all consist of a lot of code which need not deal with separate types. Type-less code pushes the burden of comprehensive testing forward, but tends to continue to work unaltered when software evolves.

Ok, by now I will probably have alienated all Java and C/C++ programmers. Soit.

Everything is a string

The way Tcl does type-less coding is often summarized as "everything is a string". This is an effective way to communicate the essence of this approach, even though it's not an accurate representation of what really happens inside, technically.

If everything is a string, then it can be shown on the screen, it can be stored and loaded back in, and it can be passed across the network without any further programming. And that's exactly where Tcl and Tk have gone.

Data structures require some care in this model. Lists are strings with specific conventions (essentially "things separated by whitespace", though the actual representation is a bit more sophisticated and able to deal with arbitrary textual and binary data). Lists can be used for structural aggregation and for indexable collections, and can be nested to form trees.

No references

Pointers and references are powerful constructs, but can also a source of hard-to-find bugs when side-effects are allowed. Purely functional languages (of the "clean" type) disallow it entirely, and even good old Lisp went out of its way to prevent in-place alteration.

Tcl addresses this by offering a single mutable mechanism, as an associative array. Arrays are named, taking strings as keys and strings as values. The only way to "reference" an array, is to pass around its name.

One consequence is that it is totally impossible to create loops of references. Loops simply cannot be created, and reference-counted memory management need never deal with cycles.

Copy on write

Tcl uses copy-on-write everywhere in its implementation. In terms of programming, this means that nothing will change underneath you as side effect, yet memory is used efficiently. This lets you write a loop over a list, whereby you can safely delete elements and not get bitten by side-effects. With extensive and safe data sharing going on behind the scenes.

The exception to copy-on-write is the one mutable mechanism Tcl has: associative arrays. Arrays can change "underneath you". This is not an oversight but a controlled way to make mutable data work, and it comes with "traces" - a way to detect and act on any array access or change.

Tcl's "traces" are not a gimmick in the style of "let's add some change trigger capability, since it so neat" but a very fundamental part of the data model, which brings together immutable type-less data, mutable arrays as aggregators of state, and an event-like access and change control mechanism to manage transitions.

Little languages

Tcl is one of those languages (along with Scheme and Forth) which are well-suited for creating small domain-specific languages. The reason for this is its total absence of syntax and parsing. When a command is invoked, the arguments are handed over to it - if these are enclosed in braces, then virtually no processing takes place. That means one can define a command which takes a string and interprets it in some very domain-specific way.

Taking this in another direction, Tcl commands are really just groups of words and symbols. It is very simple to define a set of new commands and then "program" in the new language of these commands. Nothing special needs to be done to process a set of lines of which the first word is one of the newly-defined commands.