The Tcl Way

from a posting on news:comp.lang.tcl by Paul Duffin (much more of his thoughts is on http://people.manchester.ac.uk/~zzcgudf/tcl/future.html ):

Syntactically / Semantically

Everything can be a string (used to be "Everything is a string")
Everything is done using commands.
The $ sign is only a convenient shortcut for the "[set ...]" command. - FP
All commands are treated equally.
A command is a sequence of whitespace separated words.
Each word in a command is treated the same (*before* passing to the command).

Conceptually

No artifical limits.
Provide simple building blocks.
Things should be as general as possible.

Community

Use the best tool for the job. Often Tcl can be the best tool but not always.

I/O

Event driven is good.

GUI

Event driven is good.

Threading

Threads are really little processes inside a big process and therefore should be isolated/protected from one another.
Data shared between threads should be explicitly requested.

Internationalization

Unicode is good, for just about every language.
UTF-8 is good for representing Unicode, when most often you have low-ASCII characters. (RS)

Error handling

Error messages should be helpful and friendly.

WHD wrote in comp.lang.tcl, 2002-11-19:

It came to me in a flash this weekend: The Tcl Way is the relentless exploitation of ambiguity.

Examples:

Q: Is .frm.btn a command name, a window name, or the position of a window in a hierarchy?
Q: Is "set a $b" a command, a string, or a list?

The answer to both of these questions is "All of the above."

It seems to me that the secret of the Tcl way lies in creating strings whose overt meaning is inherently ambiguous--and exploiting that ambiguity without mercy.

20nov02 jcw - That sounds more sneaky than need be, IMO. It's really highly "natural":

Q: Is "orange" a color, a fruit, or the start of a shopping list?
Q: Is "I" a pronoun, a Roman numeral, or a tally counter (the one where you write 4 bars and then strike them out before writing the next bar)?

We tend to deal with things in exactly the same way in real life. A word can be an item and the start of a list depending on context only. We don't change the way we write down things when switching from one to many "items" (well, actually we do add hints, many people start to "bulletize").

In other words, words have multiple meanings, but even whether something is a list is often determined from context. No one would consider this sentence a list. But:

  No
  one
  would
  consider
  this 
  sentence
  a
  list

... looks much more like an enumeration, all of a sudden.

20no02 WHD - I agree that it's highly natural--but it's far from the norm in computer languages. But really, I posted that on c.l.t mostly because I think it's 1) true and 2) amusing. I'm not at all sure it's helpful for newcomers to the language.

2002-11-20 RS: They should be aware of the fact that there's only strings ("data typing is an illusion"), and views on how to interpret these strings - in Clif Flynt's example

 set set set

the parser interprets the first "set" as command name, doesn't bother about the other two, and calls set with them. set interprets its first argument as variable name, looks it up or creates it, and assigns it the second argument as value. This "parser thinking" makes understanding Tcl much easier than experiences with other languages.. so newcomers should be hinted at it early. (Oh, and I love Tcl because it is "far from the norm in computer languages" - if ever there is one that covers LISP, APL, Fortran, C++..)

Neat, "set set set" is a great example to explain things with -jcw