NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/tcl/1203

Internet Message Format | 1992-08-16 | 4.4 KB

Path: sparky!uunet!mcsun!corton!sophia!bagheera.inria.fr!colas
From: [e-mail] (Colas Nahaboo)
Newsgroups: comp.lang.tcl
Subject: Re: why Tk doesn't scale well
Message-ID: <[e-mail]>
Date: 16 Aug 92 12:04:16 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Koala Project, Bull Research France
Lines: 72

In article <[e-mail]>, [e-mail]
(Dan Connolly) writes:
|> Tcl VS SMALLTALK
|> Tcl VS LISP
|> I wish Tk were built on top of XLisp -- then we'd have efficient
|> recursive list processing and an object system.

I agree with your post. Tcl is very nice for triggering commands, but do not
scale well to actually code significant portions of the applications in it.
Just in continuation of your nice analysys, I would just present my personal
experiments:

In fact, even traditional lisp systems (e.g. XLisp) have the problem of
converting back & forth C objects to their object representation. For instance,
collections of objects in C are often reprsented by the fammiliar linear array
model (argc, argv), whereas to be used in XLisp, you must convert it to linked
lists.
So when I set up designing Gwm, and X window manager with a built-in
interpreter (call it the emacs of window managers if you want), I coded a fast
lisp-like interpreter "wool" with easy integartion to C (used the same data
structures as C: (argc, argv) arrays, null-terminated strings, full 32 bit
numbers) and an incremental GC via refernce count (no refernece counting).
At first, wool in Gwm was intended to be used like Tk: mainly like a thin
glue around big C functions... but with a fast interpreter available, tons of
wool code were in fact written. Try running gwm and trace (trace t) the code,
you will astounded by the amount of wool code executed routinely for managing
your windows...
So just like TCL is pushed beyond its limits by its users in terms of
performance, wool showed its limitations for writing big amount of code in its
non-standardiness and sometime exotic features, but the performance was Ok
(smaller than mwm, as fast as other WMs). For instance I feel that as soon as
you are going to add backslashes to create TCL programs with lines longer than
80 chars, this means you are doing too big a program for tcl...

So with this lesson, I spend some sweat making a new wool version with a
common-lisp flavor, and even a small&fast CLOS object subsystem. Bull (My
company) is using it in-house linked with X & Motif in its developments and we
have a interactive design tool for it: egeria (not available outside of Bull
yet), and it works very well. It is simpler than winterp (the class system of
Xt is not mirrored int wool), but smaller and faster.

[e-mail] (Thomas M. Breuel) writes:
> what is it about Tk
> that makes you wish that it were built on top of XLisp?

I would too think that a more high-performance interpreter would be
beneficial to Tk:
1) Xt is a bit bloated with backward compatibility issues and the design
   VERY awkward at many places. Our editor egeria main problem was dealing with
   these inconcistencies, using a more coherent toolkit like Tk would be a
   bless for all interface-builder tools
2) TCL & Tk are very nice efforts. I, like others, although we have solutions
   based on Xt and other interpreters, would like TCL and Tk to succeed as much
   as possible just for the fun of it. If TCL is hampering Tk progress, a
   remplacement might be considered.

PS: before anybody asks, wool v2 is not yet freely available, both by my will
(I want it to be fully stable before releasing it, to avoid the problems that
happened with gwm constant changes), and by some temporary constraints on
diffusion that its use in a Bull commercial product implies. BUT: if you want
to port Tk to wool, just mail me, we will set up things very easily!

PS2: Please don't see this a as a flame. Since I designed wool, I am perhaps a
bit bised towards it :-), but TCL has advantages other it (multiple
interpreters
for instance, simpler operation), as have other languages other wool (xlisp,
xscheme). I feel we (promoters of embedding small interpreters in applications)
have the same problems, and can help each other by sharing ideas...

--
Colas Nahaboo, [e-mail], Bull Research Koala proj. Wool&Gwm Architect
Pho:(33) 93.65.77.70(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.