Updated 2017-02-23 02:25:36 by AMG

Is Tcl Different! enumerates what makes The cool language special'' -- Richard Suchenwirth
Tcl has a paradigm all its own. The fact that it has no types is not poor but the contrary: rich. An expression can be seen as a number or as a string or as something completely different -- depending on the target you pursue.
The man page Tcl(n) [1] teaches you, in 11 rules and 264 lines, just about everything about the syntax: basically it's about semicolon, newline, whitespace, braces, brackets, dollarsign, pound/hash (*). Of course there are "words", but all on the same level as the procs you write. List elements are joined with whitespace, this allows for beautiful human-readable coding with little effort (see Salt and Sugar). Bidirectional pipes are available with just set p [open |foo r+]
Unity of data and code
after all, just about everything is still a string [2]. If you know (or want to find out) what you're doing, just eval it.
Introspection capabilities
see what vars, commands, procs, widgets, ... you have available; for a proc, dump its args and body; ..., let widgets say their configuration... "Supraspection": Look above you in the call stack with upvar and uplevel
Lazy parsing
No processing step subjects code or data to more parsing than absolutely necessary. This allows commands that completely disagree about the interpretation of e.g. * (such as expr, regexp, scan, and glob) to coexist happily, and more generally makes it possible to employ little languages.
Automatic conversion
surf between string, list, integer representations with no explicit conversions (**). This may at times cost performance, but at other times allows beautiful simple code, e.g. add a list of numbers with expr [join $list +]
Unicode (see Unicode and UTF-8), and thus just about every widely-used writing system in the world, is allowed in all strings. How much needed and how fully implemented this is, is sometimes debated. The read and source commands can't handle Unicode files opaquely ["transparently""?] yet. But with all its flaws, Tcl offers the best i18n environment I've seen so far. Tk's mechanism of finding a Unicode char in other fonts is extremely helpful when you go global. See The Lish family for helpers from 7-bit ASCII to 16-bit Unicodes.
Even most Tcl error messages are kind of a joy to read - endless loops (recursions) aren't endless anymore but detected and reported. Most commands are implemented in a pretty common-sense, evident way. Quite a number of Tcl friends read, and often answer questions, in news:comp.lang.tcl
you can do much more with this extremely flexible language than you'd expect, by combining string manipulation, eval, and sometimes the unique 'unknown' command (see Radical Language Modification). Consider Stephen Uhler's HTML parser in 10 lines. You can write Tcl procs that are called in SQL syntax (but never the other way round ;-)(***)
Perl, in contrast, is hard to understand. For instance, the Perl man pages contain 493 occurrences of the word "magic" - used when the details are too overwhelming to fully explain - it's easier to just say "the right choice will be made, it's magic, trust us". Even the Programming Perl book uses words like magic, incantations, etc, all over, which is startling considering that it's supposed to be a reference. In contrast, the Tcl documentation contains zero uses of magic or anything remotely suggesting something is going on behind the curtains that is simply too hard to grasp. The Perl source echoes this inability to explain the details and contains over 400 occurrences of the word "magic. The Tcl source contains none and in fact is beautifully documented.
Tk is the best, easiest GUI scripting toolset around.
Proof is that the Perl and Python colleagues also use it, even if they have to emit some Tcl code for that. But the freshest Tk is always bundled with Tcl.
Expect is the best, easiest tool around for automating, testing or gluing interactive programs.
Even Perl, Python, and Java experts prefer Expect over trying to do the same thing in other languages.

* Couldn't write this up there :-)

** I replaced the word "shimmering" with "automatic conversion". Shimmering is not only meaningless to most people (and therefore smells of intentional showing off), but the word refers to unfortunate frequent conversion, which is the exact opposite of the point you're trying to convey. "automate conversion" is a lot more pedestrian but clearer and ultimately better all around. (God forbid people should understand what we are trying to tell them.)

*** [what does this last mean? CL believes Postgres prooves the contrary.] RS: I doubt that it is possible to write a Tcl interpreter in SQL :^)

For fun and serious code goodies, see Bag of Algorithms - Bag of Tk algorithms - Braintwisters - Tcl Gems!

HD: Another point: there are obfuscated C contests and obfuscated Perl contests, and half the activity in cplm seems to be about posting incredibly obscure one-lines that print out "just another perl hacker", but when's the last time someone boasted of their obfuscated Tcl code?

DGP: Why on the Obfuscation page, of course!

RS: Just yesterday I glanced at an older GCLISP manual - they have more than two dozen types to choose from. Or Java's class hierarchy, where it takes many minutes just to see what's all there. With Tcl it's different: you don't have a monster toolbox to wonder at, just knife, fork, spoon - and yumm!, off you go! ;-)

RS: one more thought: Programming languages of old had arithmetics and I/O operations as central elements. Came C and said, "I/O is not part of the language, use libraries for that" (and only had to allow varargs for printf). Some years later came Tcl and said, "Arithmetics is not part of our language either, use specialized commands, e.g. expr", leading to a substantial simplification again. Q: can this trend be continued - are there parts in Tcl that may be defined out (without loss of expressivity)? Or is Tcl essentially essential? CL replies: the cheap answer is, yes, of course, $-dereferencing is purely epiphenomenal [deref ref].

DKF: Tcl's core syntax is actually insufficient to be a full programming language; it's not inherently Turing Complete. To get there, you have to add some commands (not many though; with expr, set and while you could do a (bounded-tape) TM relatively easily).

sergiol: DKF Why do you say it is not Turing complete?

AMG: DKF is drawing a distinction between the Tcl core syntax and the Tcl command library. The Tcl syntax has no branching and looping capabilities; those are provided by the [if] and [while] commands. While it can get the value of a variable using $, it cannot set it without a command such as [set].

See Also  edit

Stephen Uhler's HTML parser in 10 lines
Tcl heritage
Arts and crafts of Tcl-Tk programming
Tcl/Tk is too easy