From: connolly@convex.com (Dan Connolly)
Newsgroups: comp.lang.tcl
Subject: why Tk doesn't scale well
Summary: Tk/Tcl vs. lisp and smalltalk
Date: 13 Aug 92 01:22:11 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

The Tk toolkit is a tremendous quick-and-dirty X11 app builder. It's
becoming so chock-full-o-features that folks are likely to build more
serious applications with Tk pretty soon. (maybe a usable alternative to
emacs?...)

But I think there are _serious_ problems with application development in
Tk, mostly due to limitations of the Tcl language.

Tcl VS SMALLTALK

I think the programming model proposed by SmallTalk is the clear choice
for visual interface design. A system of objects with state that respond
to messages has been adopted in NeXTStep via Objective C, the Mac
interface via Object pascal and C++, InterViews via C++, the X Toolkit
via C, and Tk via Tcl.

All but the last two have a full class system with inheritance and
subclassing supported by the language. It's possible (though painful) to
subclass Xt widgets to add state or messages. The Tk toolkit allows
class bindings to enhance the messages understood by a class, but it has
no mechanism for adding state to an interface object.

For example, suppose I wanted to mimic an emacs buffer with a Tcl text
widget. In an OOP language, I could subclass the text widget, add
instance variables for things like the filename, editing mode, "dirty
bit", etc. In Tcl I have to cook up some method to associate this
state with the text widget.

And I can change the bindings on that particular widget, or I can change
the bindings on all text widgets, but I cannot create a subclass of the
text widget with my custom set of bindings.

Tcl VS LISP

Tcl's strong points: it's a familiar imperative langage. It has a lot of
features to allow you to abbreviate commands and options, save values
in varables, and encapsulate sequences of commands into procedures.

The error reporting is good. You can usually start with "info commands,"
pick a command, type it, see what the syntax is ("wrong number of
arguments. should be: foo bar ?blech?"), type the command with some
arguments, see where you went wrong, and continue until you get it
right.

But the abbreviation features and high quality of error messages is due
to a lot of tedious error checking in the C implementations of the
commands. And these command implementations have to convert everything
to strings and back (not too difficult, but...) and keep track of all
sorts of dynamic memory allocation strategies (well designed, but
tedious and error prone nonetheless).

Then there's the evaluation strategy of Tcl: take the command string,
parse it into words expanding all $ and [] constructs, lookup word
1 in a hash table, and send words 2 thru n to the procedure.

Consider the evaluation of

	proc foo {x y} { concat $x $y }
	list [foo $a $b]

if the values of a and b are great big strings. Those great big
strings are expanded and passed to foo. Then they're bound
to x and y. Then they're expanded and passed to concat. Concat
just tacks them together with a space in between. Then the whole
ball of was is passed to list. List parses the whole thing,
navigating all the {}'s, ""'s, and ''s to preserve the list
structure of $a and $b.

Contrast all this expanding and reparsing with the simple
recursive list processing in most Lisp interpreters. I suppose
the tradeoff is that Lisp interpreters require garbage collectors.
But I think they scale well.

I wish Tk were built on top of XLisp -- then we'd have efficient
recursive list processing and an object system.

But it's not. Has anybody else looked at Winterp? It's an XLisp
interface to the OSF/Motif toolkit. I like it a lot, but the
motif toolkit isn't growing as fast as the Tk toolkit (multifont
editable text widget, canvas widget, etc).

I have also seen some scheme systems integrated with X11 and Xt.
They don't tend to be object oriented, but some of them are object code
compiled systems.

Dan