''from a posting on news:comp.lang.tcl by [Paul Duffin] (much more of his thoughts is on http://www.cs.man.ac.uk/~fellowsd/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 [the comp.lang.tcl newsgroup] on 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.

----
See also [The Tao of Tcl]