Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.unix.misc,comp.windows.x.apps
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!news.duke.edu!convex!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!netcomsv!ix.netcom.com!netcom.com!netcom8!mayer
From: mayer@netcom8.netcom.com (Niels P. Mayer)
Subject: Re: Why you should not use Tcl
In-Reply-To: rms@gnu.ai.mit.edu's message of Fri, 23 Sep 94 19:14:52 -0400
Message-ID: <MAYER.94Oct1121520@netcom8.netcom.com>
Sender: mayer@netcom.com (Niels P. Mayer)
Organization: NETCOM On-line services
References: <9409232314.AA29957@mole.gnu.ai.mit.edu>
Date: Sat, 1 Oct 1994 19:15:19 GMT
Lines: 548
Xref: glinda.oz.cs.cmu.edu gnu.misc.discuss:18631 comp.lang.tcl:19772 comp.lang.scheme:10183 comp.unix.misc:16011 comp.windows.x.apps:8012


I think that Richard M. Stallman's reasons for disliking TCL are quite
valid despite a few slight mis-statements (e.g. his statement of TCL
lacking arrays sort of depends on what exactly you mean by arrays -- to the
neophyte, the language appears to have arrays).

I would think that RMS's motivation comes from a desire to not discard the
last 30 years of progress in computer science just to apply the KISS
principle (Keep It Simple Stupid) to a language that is being pushed as a
"standard."  Since RMS was there to witness some of that progress (and is
the source of much of that progress itself, including numerous advances in
portable, optimizing C/C++/Obj-C compilers), one can imagine the sinking
feeling of "barbarians at the gate" when learning of Sun's plans of TCL/Tk
world domination and attempts at standardizing safe-TCL as an
inter-application communications language. If it weren't for the hype
surrounding plans for TCL world domination, I think a lot of people
(including myself) would just shut up about TCL being an inappropriate
language.

Personally I'm less concerned about Sun's plans for TCL/Tk productization
-- they'll probably be able to stumble and fall all by themselves (can you
say NeWS, and OpenLook?). I also wonder about internal politics turf wars
between the COSE/Motif, Open Step, and TCL/Tk camps at Sun -- whatever
happened to "putting all the wood behind one arrowhead"?; why the switch to
IBM-style shotgun approach? No, my greatest concern are the plans for
pushing TCL as an interapplication communication language -- in particular,
the safe-TCL efforts.

We're at a juncture where perhaps we can sway some people not to accept
"good enough" and perhaps educate some people as to why TCL isn't worthy of
any kind of standardization. Maybe anti-TCL people are religious zealots --
some of us feel that we're saving the world from an abomination of MS-DOS
(or C++) proportions.

I'm not saying that TCL/Tk doesn't have its place in the
language/environment food-chain. But almost every nontrivial Tcl/Tk
application I've looked at has quickly grown beyond the means of the
language to cleanly support the name and object space of a medium size
application. I've looked at many a C implemented X program, and many of
these are quite twisted too -- bad programming is the norm. So I'm sure
TCL/Tk is acceptable in that it provides similar levels of abstraction and
modularization that people already accept as the norm in other
languages. Unfortunately, given the kinds of cost, or deadline overruns,
and/or reliability problems incurred by most software projects, we should
be striving for better, instead of "good enough."

Even if Sun's product TCL/Tk manages to fix TCL's semantic and syntactic
problems, they'll just be patches, and radical changes will be hampered by
backwards compatibility constraints. Why not start with a language that was
designed to be semantically and syntactically elegant right from the start?

One problem is that "scripting" does not apply that well to medium
complexity GUI-based *APPLICATIONS* which people claim is TCL/Tk's
strength. For one, "scripting" languages don't handle the data abstraction,
and manipulation required by most non-trivial applications, and you really
shouldn't need to drop down to the C level to implement such capabilities.
For example, how easy is it to cleanly implement a model-view-controller
architecture in TCL/Tk? The key here is "cleanly" and the level of language
support -- after all, a good programmer could implement MVC in assembly
language...

Also, anybody that knows anything at all about languages knows that it
takes very few language capabilities in order to perform arbitrary
computation. So claims that TCL is a good language because many people are
writing apps in TCL does not mean that the language is good. Many people
write full-sized applications in shell-script languages, assembly, and
Fortran too. The factors involved in TCL's success go way beyond technical
merit or lack thereof:

	(1) Simple language, easy to extend in C, not much different from
	    extant scripting languages.
	(2) Free toolkit, whereas OSF/Motif is hampered by OSF's patented
	    shoot-yourself-in-the-foot licensing policy.
	(3) Grass roots buy-in, academic development environment
	    (free student slave labor, sponsorship through UC budget).
	(4) Computers becoming fast enough, and memory becoming cheap enough
	    to support whole applications written in hybrid C+interpreter
	    languages (this factor is also enabling the success of other
            interpreted environments, e.g. Visual Basic, Actor, Python,
	    Perl, Smalltalk, Elk, CLISP, SCM, WINTERP, XLISP, etc). 10 years
	    ago, anybody writing serious apps in an interpreted language
	    for use on an IBM PC or VAX 11/780 would have been laughed at...
	    Nowadays, nobody seems to mind running a 5 megabyte TCL/Tk
	    image to read their mail.

Since nobody seems to be making any specific points about what is wrong
with TCL, I thought I'd repost two articles I've posted in the past, during
a previous "language war".

--------------------
From: mayer@netcom.com (Niels P. Mayer)
Date: 23 Jul 1994 21:22:41 GMT
Organization: NETCOM On-line services
In-reply-to: mayer@netcom9.netcom.com's message of Fri, 22 Jul 1994 18:21:40 GMT
Newsgroups: comp.lang.tcl,comp.software-eng,comp.lang.functional,comp.lang.misc,comp.windows.x,comp.lang.lisp
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)

[please excuse following up to my own last posting ... Ousterhout's
 original posting appears to have expired on netcom...]

From: ouster@sprite.Berkeley.EDU (John Ousterhout)
| There are many things in Niels Mayer's article that deserve a rebuttal, I'll
| just pick a couple:
| 
| |> TCL's problems of language quoting incosistency make it difficult to write
| |> higher level abstractions for UI construction -- macros, iterators,
| |> data-driven-UI-generation, etc. Not that higher level abstractions can't be
| |> done -- it's just that creating them in TCL is linguistically painful
| |> because the language uses the wrong fundamental data-type -- newline
| |> delimited STRINGs separated by spaces.  In constrast LISP chose the right
| |> fundamental data-type LISTs of SYMBOLs, and consistently applies this
| |> datatype across throughout the language.
| |>
| 
| This paragraph suggests that you don't understand Tcl.  In fact the quoting
| rules are very simple and very consistent;  I claim that it's quite
| straightforward to build higher-level constructs for UIs and I think there
| are many many examples in the Tcl community that illustrate this.  One
| can make religious arguments ad nauseum, but I know of no technically
| sound evidence that lists of symbols are fundamentally better than strings.

It looks like a number of your users are also having trouble understanding
Tcl. In my opinion, this is because the quoting and parenthisation rules
are neither straighforward, simple, nor consistent. About once every week
or two, I see questions come up on comp.lang.tcl dealing with one or more
of the issues raised above. Examples of these problems have been
appended to the end of this article...

When users are having real problems, it becomes clear that the arguments
are no longer religious. In Lisp, you can get arbitrarily complex and
inscrutable once you go to extreme macro-ology and multiple levels of
backquoting.  However, for the more typical cases handled by the neophyte,
the problems of quoting, time-of binding, time-of substitution, and scope
of bindings are more consistent and easier to understand in Lisp. And
when you need to, you know that there's a very nice macro capability
to back up any meta-level programming you need to accomplish.

By default, Lisp does the right thing for the case of binding at run-time,
and when you need to perform binding at evaluation time, you use
backquotes...  The places where backquote substitutions happen are clearly
marked by backquoting 'commands' e.g. (,foo); all other cases look up the
value of a symbol based on the closure surrounding the code being
executed. By using closures, one may limit the extent of variables to
groups of functions or methods, an application module, or the entire
application -- closures are the basis enabling any lexically scoped Lisp
solution to scale better than TCL.  And in Lisp, you don't have multitudes
of different ways of opening and closing expressions...

Furthermore, there's 30 years of history and 30 years worth of books on
Lisp programming which have dealt with these problems from the pedagogical,
technical, and style/design perspectives. Most beginners find this helpful.
Reinventing the issues which are already solved problems in Lisp, just so
that you can have a language that doesn't parenthesize like Lisp -- that is
not helpful to the beginner. It does, however, open up a whole new market
for books.

Finally, I think that having language syntax depend on newlines is a bad
idea -- I think most unix shell programmers will grudgingly agree with me
on this.  I'd much rather have a Lispish syntax where you delineate your
current top-level evaluations by [ ... ] and don't bother with newlines.
Unfortunately, given people's knee-jerk response to Lisp, having such a TCL
would highlight TCL's parentage as bastard-child-of-Lisp. Something almost
Lisp-like would set-off or shatter people's preconceived panic
response. Can't do that! (Meanwhile, I eagerly await the chance/time to see
how the Dylan folks solved the problem of being politically right-thinking
with regards to syntax while retaining a Lisp core).

Well, here go the examples, gleaned from a random reading through
comp.lang.tcl articles on this site:

--------------------

From: hfvstud@bcarh80a.bnr.ca (7Z31 Coop)
| In article <1994Jul21.180848.12056@khis.com>, changd@khis.com (David Chang) writes:
| 
|  [... Stuff Deleted ...]
| |> I'm trying to get the number of word "set" appeared in $file and set 
| |> the scale value by using "set count [exec grep -c set $file]; .scale set $count".
| |> This doesn't work if no "set" appeared in file "$file" , so I change to use
| |> the following method (use catch) :-) Guess what ?
| |> 
| [... Stuff Deleted ...]
| |>
| |> catch [exec grep -c "set" $file] retval 
| |> if { $retval == 1 } {   
| |>    .scale set 0
| |>    return 0
| |>    }    
| |> 
| |> if { $retval != 1 } {
| |>    set count [exec grep -c "set" $file] 
| |>    .scale set $count
| |>    return 0
| |>    } 
| |> 
| |> So my question is : How do I set the variable "count" if the return value of
| |> "grep -c" is 0 ?
| 
| Try:
| 
|   if {[catch {set count [exec grep -c "set" $file]}]} {
|     .scale set 0
|   } else {
|     .scale set $count
|   }
|   return 0


From: frisoni@faw.uni-ulm.de (Davide Frisoni)
| Hello everyone,
| thanks to all people who answered my question, the main error come from a wrong use of [].
| 
| I wrote :
| set code [catch [my_cprogram] err] :-(
| and now with :
| set code [catch {my_cprogram} err] :-)
| it works.


From: Rob Earhart <earhart+@CMU.EDU>
| wessel@stt_even.let.ruu.nl (Wessel Kraaij) writes:
| > proc 8bitbindings {widget} {
| >     bind $widget \" {set nop 0}
| >     bind $widget \"\" {$widget insert insert \"}
| >     bind $widget \"e {$widget insert  insert \353}
| > }
| > 
| > Unfortunately, this does not work, because $widget in the binding
| > script is evaluated at event time, not at bind time!
| 
| proc 8bitbindings {widget} {
|     bind $widget \" {set nop 0}
|     bind $widget \"\" [list $widget insert insert \"]
|     bind $widget \"e [list $widget insert  insert \353]
| }
| 
|   Yeah, I stumbled on this when learning TCL, too :-)

From: davida@london.sbi.com (David Artus)
| Long Pham (lpham@tern.NoSubdomain.NoDomain) wrote:
| : Hello tcl experts,
| 
| : I'm a newbie in this area, and have a small problem while playing w/
| : tcl.  So, be gentle.
| 
| : Here is my problem:
| : I'm trying to create an n number of buttons, each button will call 
| : a same proc upon activated.  And an argument passes to the proc is
| : an variable, i.e. different value for different button.  I want to
| : display the value of the argument that I passed to the proc everytime
| : I click on a button. However, the program doesn't work, it always 
| : display the last value of the variable no matter what button I
| : clicked on.
| 
| : set names {John Anne Mary Jim}
| : foreach b $names {
| :   
| :   button .$b -text $b -command {displayName $b}
| :   pack .$b -side left -padx 3
| 
| : }
| 
| : proc displayName bname {
| :   puts $bname
| : }
| 
| your problem is  -command {displayName $b}
| 
| The {} defer evaluation of $b till the event occurs. At that time
| b is, of course, set to Jim. You probably mean -command "display $b"
| for the purposes of this playing, or in real life maybe some
| cunning way of extracting the button name, contents or whatever.

From: hfvstud@bcarh80a.bnr.ca (Dan MacDonald)
|In article <1994Jul22.005941.19824@wmichgw>, 31challa@wmich.edu writes:
||> Hello Everybody,
||> 
||> I am a new user of tk/tcl. I have a question.
||> 
|
|Your entire problem:
|   Very simply it's the value being passed to your procedure s1 is
|   always '0'.  This stems from the fact that when you created the
|
|   button .watch22.yes -text YES \
|	-command "s1 $foo_value"
|
|   you specified the command (bind command) in quotes which performs
|   substitutions when created.  If you enclose the command in curly
|   braces the substitution will be performed later.  Although the (all)
|   bind command operates at global scope, this is acceptable since the
|   variable foo_value is a global variable - it must be because it
|   to is "bound" by the scale widget to store the value.
|
|Try:   button .watch22.yes -text YES -command {s1 $foo_value}
|
|Dan MacDonald

From: fms@cam-orl.co.uk (Frank Stajano)
| In article <303o17$4n2@hydrox.cs.umd.edu>, nlewis@cs.umd.edu (Nathan Lewis) writes:
| |> Hi everyone,
| |> 
| |> I'm still new to tcl and I'm having some trouble. I'm trying to write lines to
| |> a file. There is one line where I want to write a bunch of things to the file
| |> literally but the problem is that I want to write $variable-name to a file
| |> literally and the interpreter keeps trying to evaluate the variable and I can't
| |> seem to get it not to. 
| |> 
| |> 
| |> Thanks alot for any help.
| |> 
| |> This is the code:
| |> 
| |>     button $w.ok -text "EXIT" -command "   ;\ 
| |> 		puts \$datafile \"set precedence_relO \$precedence_rel\"  ;\
| |> 		puts \$datafile \"\n\n\n\" 	;\
| |> 		puts \$datafile \"set precedence_rel {\[lindex \\$precedence_relO 0\]}\" ;\
| |> 	This is the line ^			 This is the variable ^
| |> 		puts \$datafile \"\n\"	;\
| |> 		puts \$datafile \"set Threads [list $Threads]\" 	;\
| |> 		puts \$datafile \"\n\" 	;\
| |> 		puts \$datafile \"set exclusion_rel [list $exclusion_rel]\" 	;\
| |> 		exit	;\
| |> 
| 
| I must admit I haven't got a very clear idea of what you are trying to do, but
| if all you want is putting out stuff literally you could use curly brackets
| instead of quotes. If instead you want to have some of the things substituted
| (like the []'s) and some not (like the $'s) then I'd say your best bet is to
| make the command a separate procedure and build up the complex string in the
| procedure with "append". Otherwise it becomes a bit too complicated to do in one
| single command line, and the code becomes difficult to read and maintain.

From: fms@cam-orl.co.uk (Frank Stajano)
| In article <ASSON.94Jul15074028@chacmool.stsci.edu>, asson@chacmool.stsci.edu (Drew Justin Asson) writes:
| [...]
| |> >proc foo {x} {
| |> >    global Global_Var
| |> 
| |> >    if {$x == ""} {
| |> >        return $Global_Var
| |> >    } else {
| |> >        return $x
| |> >    }
| |> >}
| |> 
| |> 
| |> The only problem with this is that this will raise an error
| |> if no argument is provided.  To do what you want, you would
| |> have to declare the argument list as:
| |> 
| |>      { {x ""} }
| |> 
| |> Then, the code would work.
| 
| You're absolutely right, thanks for pointing it out. (Using args instead of x is
| another option.)
| 
| |> But, this isn't really what I wanted.  I was more interested in
| |> doing something that we often do with LISP code.  E.g.
| |> 
| |>    proc foo { {x minus-infinity} {y plus-infinity} } {
| |>      ...
| |>    }
| |> 
| 
| I can't think of a Tcl way of doing this sort of thing in the argument list. If
| someone finds one, I'd be curious to know about it.
 
From: sti@cs.hut.fi (Sami-Jaakko Tikka)
| In <30jdao$8mk@access3.digex.net> cobrien@access3.digex.net (Cary B. O'Brien) writes:
| >Why does expr { fred < sam } fail,
| >When expr { "fred" < "sam" } succeeds.
| 
| When expr sees strings without quotes, it tries to convert them to
| numbers.

--------------------

From: mayer@netcom.com (Niels P. Mayer)
Newsgroups: comp.lang.tcl,comp.software-eng,comp.lang.functional,comp.lang.misc,comp.windows.x,comp.lang.lisp
Subject: Re: What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)
Distribution: 

[note additional crossposting to comp.lang.lisp]

In article <LORD.94Jul21165437@x1.cygnus.com> lord@x1.cygnus.com (Tom Lord) writes:
	   ouster@sprite.Berkeley.EDU:

	   Since we're slinging arrows, allow me to sling mine.  It's
	   time to accept the fact that Lisp will never be a mainstream
	   language.  There's no question that Lisp is an intellectually
	   interesting language, and it is very important in certain
	   communities, such as AI and formal language design.  But it's
	   simply never going to be widely used.

   Right.  No general-use application written in lisp will ever fly.
   Only in a few exotic situations do people ever use lisp.

   Tom Lord
   part-time emacs hacker

Perhaps you mean no general use application written entirely in Common
Lisp will ever fly? I can think of lots of counterexamples:

	* GNU Emacs partially written in Lisp. It is a hybrid
	  implementation using C at its core, and Lisp as a configuration
	  and extension language. 

	* AutoCAD uses AutoLisp as an extension language. It is very very
	  popular given that it is a CAD package, and not, say, a spreadsheet.
	  I can't remember the figures exactly, but I've heard there's 500,000
	  to 1,000,000 copies of it floating around world-wide.

	* Various other CAD packages use Lisp extension languages as well,
	  for example Cadence Design Systems.

	* Interleaf uses Lisp as an extension language.

	* SoftQuad has an SGML editor which uses Scheme (a Lisp dialect) as an 
	  extension language.

	* All applications written in WINTERP (I know of one that had
	  an estimated 1500 users.) All applications using Elk. All.
	  applications using CLM/GINA. All applications using GNU Emacs
	  and written in Emacs-Lisp (such as the newsreader I'm using --
	  GNUS).

	* The statistics community has found Luke Tierney's XLISP-STAT
	  to be a very cool package as well. THis is a package with
	  a hybrid C/Lisp implementation of Lisp which is extended to
	  do graphics and plotting (Mac,Unix/X11) and with statistics
 	  primitives.

--------------------

From: ouster@sprite.Berkeley.EDU (John Ousterhout)
> Since we're slinging arrows, allow me to sling mine.  It's time to accept the
> fact that Lisp will never be a mainstream language.  There's no question that
> Lisp is an intellectually interesting language, and it is very important
> in certain communities, such as AI and formal language design.  But it's
> simply never going to be widely used.  Lisp has been trying for more than
> 30 years;  every few years we hear another round of grandiose claims, and
> a few years later they have evaporated.  We could argue about why Lisp
> hasn't entered the mainstream, but none of this changes the basic fact
> that it hasn't.
> 
> I believe that it is reasonable to give new ideas a chance and to accept
> plausible arguments that they might succeed, but when a system has been
> around for 30 years I don't think "plausible arguments" are enough anymore.
> If someone is going to argue today why Lisp should be a mainstream
> language, they must somehow explain why it hasn't succeeded in the past
> and what will happen this time to make things turn out differently.

Repeating "Lisp is dead" over and over and over again will not make it
true, just like repeating "Tk has a Motif Look and Feel" will not make it
true to someone expecting a Tk application to "feel" like Motif.

All you have to do is go down to any technical bookstore and you will find
many many books on Lisp programming, Lisp application programming and
Scheme programming. And I'm not talking about 30 year old books on Lisp,
I'm talking about books that are in their third or fourth printing and have
been published in the last few years. There is a market for these books,
otherwise the publishers would never have put these books out, nor put out
new editions of older books (e.g. Winston&Horn).

In addition to Lisp books, there are also a number of recently published
books on the Scheme dialect of Lisp. One of the best introductory books on
computer science, Abelson&Sussman's "Structure and Interpretation of
Computer Programs", uses SCHEME and not Pascal or C to introduce the
student to a variety of interesting CS problems. The fortunate few that are
able to make it in to MIT end up taking 6.001 (which uses the
Abelson&Sussman book) as their introductory computer science and
programming course, which tends to put these folks on the right track right
from the start.

Finally, I know of at least three books on GNU Emacs which discuss
Emacs-Lisp programming, and there's whole rows of books on AutoLisp
programming for AutoCAD.

(Since WINTERP uses XLISP-PLUS, I'll also mention that I know of two books
on XLISP, and one on Luke Tierney's XLISP-STAT).

Meanwhile, I know of exactly one book on TCL/Tk (Ousterhout's) that is now
available in bookstores. More importantly I haven't come across any books
on applications using TCL/Tk as an extension language (like the GNU Emacs
or AutoCAD books).

> |> Yes, TCL is a simple language -- I contend that it is too simple and too
> |> simplistic for constructing well engineered applications:
> |> ...
> 
> Again, I think the large number of Tcl applications and the growing size of
> the Tcl community speak for themselves.  What better evidence could there
> be that Tcl and Tk are practical for building interesting and useful
> applications?

I already answered to this in my original post when I said:

| The fact that people *can* program applications in the bourne shell, or
| tcsh, or the korn shell does not imply that a language having the above
| limitations is a good or expressive language for building applications.

Some of the problems I addressed:

| 	* type-overloading of strings, and lack of any real type system.
| 	* lack of proper automatic memory and resource management (freeing
| 	  up data when a widget is destroyed doesn't quite cut it).
| 	* lack of lexical scopes for functions/procedures.
| 	* lack of closures (forcing programmers to use too many global
| 	  variables).
| 	* Lack of object orientation in the standard TCL/Tk release.

Are clearly problems with TCL in terms of building larger applications that
scale well, and aren't mired in a sea of global references. I can't imagine
that people spent the time to develop [incr tcl] and [incr tk] unless
they were attacking a known problem.
 
I think the whole "popularity" line of reasoning is questionable: MS-DOS
and MS-WINDOWS are more popular than Unix/X, but many of us have good
reasons to keep working on Unix and X. Beyond that, if you're worried about
popularity, both the Lisp and TCL/Tk community are no doubt insignificant
when comparted to, say the Visual Basic community, or Actor, or other
similar packages available for MS-WINDOWS.

In other words, the popularity argument is meaningless at best, and
specious at worst. Some people are willing to pay the costs of Lisp in
return for its benefits. Others may be lured to TCL/Tk because it is small,
simple and free and includes a free toolkit. None of these have anything
to do with the fact that the language may not be good for building
GUI-based applications. People write applications in assembly too.

When discussing language features, one shouldn't confuse a trend with a
movement.

I personally couldn't give a deleted expletive about whether Lisp is more
or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
program.  In the mean time, I'm happy to see that we all have choices and
are not locked in to any particular form of lowest-common-denominator
groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.

--------------------

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
==           Niels Mayer -- netcom!mayer -- mayer@netcom.com		   ==
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
