home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / tcl / 1178 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  4.3 KB
  1. Path: sparky!uunet!olivea!apple!news.oc.com!convex!connolly
  2. From: connolly@convex.com (Dan Connolly)
  3. Newsgroups: comp.lang.tcl
  4. Subject: why Tk doesn't scale well
  5. Summary: Tk/Tcl vs. lisp and smalltalk
  6. Message-ID: <1992Aug13.012211.10452@news.eng.convex.com>
  7. Date: 13 Aug 92 01:22:11 GMT
  8. Sender: usenet@news.eng.convex.com (news access account)
  9. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  10. Lines: 86
  11. Nntp-Posting-Host: pixel.convex.com
  12. X-Disclaimer: This message was written by a user at CONVEX Computer
  13.               Corp. The opinions expressed are those of the user and
  14.               not necessarily those of CONVEX.
  15.  
  16. The Tk toolkit is a tremendous quick-and-dirty X11 app builder. It's
  17. becoming so chock-full-o-features that folks are likely to build more
  18. serious applications with Tk pretty soon. (maybe a usable alternative to
  19. emacs?...)
  20.  
  21. But I think there are _serious_ problems with application development in
  22. Tk, mostly due to limitations of the Tcl language.
  23.  
  24. Tcl VS SMALLTALK
  25.  
  26. I think the programming model proposed by SmallTalk is the clear choice
  27. for visual interface design. A system of objects with state that respond
  28. to messages has been adopted in NeXTStep via Objective C, the Mac
  29. interface via Object pascal and C++, InterViews via C++, the X Toolkit
  30. via C, and Tk via Tcl.
  31.  
  32. All but the last two have a full class system with inheritance and
  33. subclassing supported by the language. It's possible (though painful) to
  34. subclass Xt widgets to add state or messages. The Tk toolkit allows
  35. class bindings to enhance the messages understood by a class, but it has
  36. no mechanism for adding state to an interface object.
  37.  
  38. For example, suppose I wanted to mimic an emacs buffer with a Tcl text
  39. widget. In an OOP language, I could subclass the text widget, add
  40. instance variables for things like the filename, editing mode, "dirty
  41. bit", etc. In Tcl I have to cook up some method to associate this
  42. state with the text widget.
  43.  
  44. And I can change the bindings on that particular widget, or I can change
  45. the bindings on all text widgets, but I cannot create a subclass of the
  46. text widget with my custom set of bindings.
  47.  
  48. Tcl VS LISP
  49.  
  50. Tcl's strong points: it's a familiar imperative langage. It has a lot of
  51. features to allow you to abbreviate commands and options, save values
  52. in varables, and encapsulate sequences of commands into procedures.
  53.  
  54. The error reporting is good. You can usually start with "info commands,"
  55. pick a command, type it, see what the syntax is ("wrong number of
  56. arguments. should be: foo bar ?blech?"), type the command with some
  57. arguments, see where you went wrong, and continue until you get it
  58. right.
  59.  
  60. But the abbreviation features and high quality of error messages is due
  61. to a lot of tedious error checking in the C implementations of the
  62. commands. And these command implementations have to convert everything
  63. to strings and back (not too difficult, but...) and keep track of all
  64. sorts of dynamic memory allocation strategies (well designed, but
  65. tedious and error prone nonetheless).
  66.  
  67. Then there's the evaluation strategy of Tcl: take the command string,
  68. parse it into words expanding all $ and [] constructs, lookup word
  69. 1 in a hash table, and send words 2 thru n to the procedure.
  70.  
  71. Consider the evaluation of
  72.  
  73.     proc foo {x y} { concat $x $y }
  74.     list [foo $a $b]
  75.  
  76. if the values of a and b are great big strings. Those great big
  77. strings are expanded and passed to foo. Then they're bound
  78. to x and y. Then they're expanded and passed to concat. Concat
  79. just tacks them together with a space in between. Then the whole
  80. ball of was is passed to list. List parses the whole thing,
  81. navigating all the {}'s, ""'s, and ''s to preserve the list
  82. structure of $a and $b.
  83.  
  84. Contrast all this expanding and reparsing with the simple
  85. recursive list processing in most Lisp interpreters. I suppose
  86. the tradeoff is that Lisp interpreters require garbage collectors.
  87. But I think they scale well.
  88.  
  89. I wish Tk were built on top of XLisp -- then we'd have efficient
  90. recursive list processing and an object system.
  91.  
  92. But it's not. Has anybody else looked at Winterp? It's an XLisp
  93. interface to the OSF/Motif toolkit. I like it a lot, but the
  94. motif toolkit isn't growing as fast as the Tk toolkit (multifont
  95. editable text widget, canvas widget, etc).
  96.  
  97. I have also seen some scheme systems integrated with X11 and Xt.
  98. They don't tend to be object oriented, but some of them are object code
  99. compiled systems.
  100.  
  101. Dan
  102.