Grex Systems Conference

View Responses

Grex Systems Item 32: The Tcl/Tk and Expect item
Entered by cross on Sun Sep 17 00:03:38 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.

14 responses total.

#1 of 14 by other on Mon Sep 18 20:03:13 2006:

Please elaborate on this impact.  I experimented with a TCL/TK
implementation under Mac OS 9, but found it provided functionality more
easily found elsewhere when making the switch to Mac OS X shortly
thereafter.

#2 of 14 by gull on Mon Sep 18 20:54:58 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.

#3 of 14 by gull on Mon Sep 18 20:56:35 2006:

Oh yeah, and TCL was also sometimes used as a CGI script language, in 
the days BP (Before Perl.)

#4 of 14 by twenex on Mon Sep 18 21:04:27 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.

#5 of 14 by remmers on Mon Sep 18 21:21:34 2006:

Re #3:  Before Perl?  But Perl predates the web.

#6 of 14 by cross on Tue Sep 19 03:33:09 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.

#7 of 14 by gull on Tue Sep 19 06:41:29 2006:

Ah, I see.  I was missing that historical perspective.  That explains, 
too, why I occasionally see X applications that use TCL as a scripting 
or macro language.

#8 of 14 by cross on Wed Sep 20 04:06:21 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...).

#9 of 14 by twenex on Wed Sep 20 13:59:17 2006:

How much of a problem is that, in practice? I cringe at code blocks in Python
(because they use whitespace as a delimiter), as do many other programmers
- but look how popular it is.

#10 of 14 by cross on Wed Sep 20 22:12:36 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.

#11 of 14 by sholmes on Thu Sep 21 02:18:51 2006:

The space delimiter thing gets messy when you copy-paste code using the mouse.

#12 of 14 by cross on Thu Sep 21 02:32:40 2006:

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

#13 of 14 by sholmes on Thu Sep 21 02:39:12 2006:

You have to take care where [location] you start your selection and where you
end it.

#14 of 14 by cross on Thu Sep 21 12:54:16 2006:

Ah, that makes sense....

Response not possible - You must register and login before posting.