The Tcl/Tk and Expect item

Sep 17 00:03 UTC 2006

This item is for discussion Tcl/Tk and its variants (such as expect and
expectk).  John Ousterhout's Tool Command Language has had a lasting inpact
on computing and the scripting landscape.

response 2 of 14:

Sep 18 20:54 UTC 2006

TCL/Tk was very popular for a while for writing small applications 
under X Windows.  It abstracts out a lot of the more painful parts of 
dealing with the windowing system, and its event-driven design works 
well for user-response-driven applications.  I suspect it inspired some 
of the later "visual" languages, but I don't really know.

response 4 of 14:

Sep 18 21:04 UTC 2006

Its popularity is also no doubt due in no small part to the fact that
applications implemented in it use the Motif User Interface, which in the 90s
became the closest the X Window System had to a standard interface.

response 6 of 14:

Sep 19 03:33 UTC 2006

Regarding #5; Perhaps before the widespread dominance of Perl for web
applications (which I would disagree with, but I don't want to  put word's
in David's, uh, fingers).

Regarding #4; Actually, Tk had the "look and feel" of Motif but was
implemented independently.  Those familiar with Motif applications found the
widget set to be close to what they expected it should look like.  But it
didn't use Motif under the hood.

Regarding #1; The original idea was that, under Unix, you have this set of
semi-interactive tools: FTP, telnet, mail, etc.  Each has its own little
quirky command language that's implemented either by hand or using yacc and
lex, and none are really like any other.  Or you have non-interactive tools
that have behavior that's defined by the contents of some file that, again,
has some quirky syntax that's slightly irregular.  These things are parsed
by bespoke interpreters implemented for the task (either by hand, or via some
yacc/lex combination).  They have weird limitations, aren't easily extendible,
etc.  TCL was meant to replace all of these with a standard, extensible
language with a canned interpreter.  So, if it had worked out the way
Ousterhout wanted, someone would put Tcl in the base system, take, say, the
FTP command, gut it, and replace the command language with TCL.  The plethora
of dot files that liter the average user's home directory would be replaced
by TCL scripts.  Learning TCL would allow one to unlock the mysteries of most
tools and their command and configuration languages.  It *was* a good idea,
but didn't really pan out: no one ever replaced the FTP command language with
TCL, and most commands still had some weird dot file associated with them
still do.  TCL was quickly relegated to, "just another scripting language."

But, the ideas has lived one: many tools now use Perl or Python as a
configuration language (for instance, fetchmail), and the expect tool for
driving interactive programs uses TCL as the base language, and *is* widely
used.

Anyway, that's what I meant by lasting impact.

response 8 of 14:

Sep 20 04:06 UTC 2006

Yeah, it's kind of a shame: the world may have been a bit better had the idea
caught on.  Perhaps some of the aversion to it was really to the Tcl language
itself, which has some weird-isms (I recall something weird about semi-colons
and comments...).

response 10 of 14:

Sep 20 22:12 UTC 2006

It depends on the application.  If its quite involved it could be a real
problem.  If it's smaller, it won't be, though one might find the behavior
suprising if one wasn't expecting it.

The Python space-determines-scope thing is the sort of thing you either love
or hate.  Some consider it great because it forces the programmer to
explicitly deliniate scope, but to others it's just Weird and forces one
into a specifc style that sometimes is ugly.  To me, it would be great if I
could ever remember what Python thinks is the relationship between tabs and
spaces.

response 12 of 14:

Sep 21 02:32 UTC 2006

How so?  Is it a tab expansion issue, or something else?

response 14 of 14:

Sep 21 12:54 UTC 2006

Ah, that makes sense....