Version 75 of Who says Tcl sucks...

Updated 2005-02-19 09:19:58

Purpose: to collect negative quotes referring to Tcl. All in good taste, and if possible with an exact reference or URL.

RA2 To be taken with a grain of salt. There is no perfect language. Even if one coded a perfect language you'd always find people to criticize it left and right. Nothing is ever absolute. All tastes are in the nature! As the saying goes: "you can't please everyone and his uncle Charlie".

These people quoted below can say what they want. A lot of us say: "thank God there is TCL!"


Eric S. Raymond
Linux Journal (Dec 1999 Issue 68) I used to write a lot of Perl, until it got too painful. And the less said about Tcl, the better.
Guido van Rossum
Linux Journal (Dec 1999 Issue 68) (referring to Tcl)... Which is, there is no syntax, or it's so simple you have to do everything outside the syntax.
Larry Wall
<[email protected]> Tcl long ago fell into the Forth trap, and is now trying desperately to extricate itself (with some help from Sun's marketing department). (Should probably be read in confunction with another quote from Larry Wall: I don't want to fall into the Forth trap, where every running Forth implementation is really a different language.)
Larry Wall
<[email protected]> Tcl tends to get ported to weird places like routers.

[How is this a "Tcl sucks" quote? --setok]

 In the context it was used, it was as if to say it ONLY got ported
 to weird places...
Larry Wall
<[email protected]> Historically Tcl has always stored all intermediate results as strings. (With 8.0 they're rethinking that. Of course, Perl rethought that from the start.)
Richard Stallman
[L1 ] Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.

Arjen Markus I just started reading the SICP book - my first encounter with Lisp and I began to wonder: does Lisp get the same criticism?

David Welton Uh...no, actually Richard Stallman picked Scheme for Guile, which was supposed to be the GNU project's universal scripting language. Lisp and Scheme have all those features, and many more that Tcl doesn't.

KBK - Note that RMS has an axe to grind; he rejected Tcl at least partly on the grounds that the Sun/Scriptics/Ajuba business model mixed open-source and proprietary software, and went as far as to harangue John Ousterhout, calling him a "parasite." [L2 ] The fact that he did so in front of Tim O'Reilly garnered him a fair amount of press, and a Google search on the three words "Ousterhout Stallman parasite" will return a couple of dozen links presenting the dispute from several viewpoints.

ZLM ~ The quote: "I don't think Scriptics is necessary for the continued existence of Tcl". Ouch!

[Axe to grind or not, I think tcl version matters here -- "lacks arrays" got addressed in tcl 8, and we're talking about comments made in 1994.]

[I'm not sure what "arrays" you are thinking about, but tcl's arrays are there for much longer whereas RMS's "arrays" are still not there. I'm not too sure, if I really miss them, though - I think not. AvL RMS's "arrays" are equivalent to Tcl lists. What got adressed in Tcl 8 is that element access time is essentially constant, as with e.g. C vectors, which was not the case in Tcl 7 where every access required parsing the string as a list. Lars H ]

Mark Hammond & Andy Robinson
[L3 ] Tcl: The (mostly hidden) language used by Tk and, hence, used by Tkinter to communicate with the Tk toolkit. describing terminology in chapter 20 of their book Python Programming on Win32.

[Again, not really a sucks quote, although inaccurate. --setok]

Craig Kelley
[L4 ] <[email protected]> I can't stand TCL due to the extensive mis-use of eval() calls ... The owner of http://www.tclsucks.com/ . Whoops, the URL doesn't work. I guess Tcl doesn't suck anymore?
Cameron Laird and Kathryn Soraiz
"... as a language it [Tcl] doesn't feel nearly as close to C and Java as do Perl and even Python. . . . Greatest liabilities: inadequately documented Win* interfaces, including COM, and faltering Mac OS support." [L5 ]
Randal Schwartz
"If it weren't for Tk and Expect, TCL wouldn't even be around now." Randal [L6 ] says this in public reasonably often, and occasionally he writes it [L7 ].

Peter Lewerin So? Tk and Expect probably do contribute a lot to the value of Tcl. If you read the article, you'll note that he admits that a similar statement can be made against Perl.

rob kudla: "Ugly code and ugly 1980's style Motif-like interfaces are what I think of when I think Tcl" [L8 ] - See Rob's remarks on about tcl and popularity to see he feels even more strongly now than before.

C J Silverio http://www.blackbook.org/2001/04/010402.html goes into details of why she despises incr Tcl performance, upvar, and command termination by newline.

Brian Kernighan
[L9 ] The split into two components was encouraged and ultimately forced by two issues. First, Tcl's notation for arithmetic expressions is clumsy; it is easier to write most expressions in C. More important, however, Tcl is not very good at data structures, since it provides only associative arrays and strings (upon which a veneer of linked lists can be applied). Again, C or C++ is more expressive and the code is much easier to maintain. These operations also run significantly faster in C/C++; this more than compensates for any extra file traffic.

Int the midst of his epic campaign to realize Tcl's universality, RS notes that blocking and lexical scope are ... challenges [L10 ]. On the same day, coincidentally, DKF mentions in the chat his own desire for anonymous functions (but see "Lambda in Tcl" (and also tricks unknown plays?)).

Frank Pilhofer mentions in news:[email protected] : [...] because arrays in Tcl are not "values", they're something special. You cannot pass them around by value, only by reference, you cannot return an array as a result, and you cannot nest them. (DKF notes that this is partially addressed in Tcl 8.5 with dictionaries.)

rjk has some negative comments about Tcl here: http://www.kudla.org/raindog/tcl/ and here: http://mini.net/tcl/9505 Tcl/Tk seems more and more stuck in the past to me, and I feel less positively about it these days than I did when I wrote the above article.


Amazon have published a review of Brent Welch's book:[L11 ] The review appears to have come from Amazon themselves. Considering they are trying to sell the book, it is surprisingly negative:

Amazon
Long after opinion leaders in the GUI scripting community abandoned Tcl/Tk for more modern scripting languages"..."Tcl/Tk survives despite its inelegance"..."Functionally, Tcl/Tk lacks nothing compared to modern scripting languages, except lexical flexibility and object-orientated architecture. Nor does it add anything except familiarity, consistency and a long history of above-average documentation"..."Welch perhaps wisely omits comparison with his competition, just as Dick Clark never mentions Howard Stern. It is beneath the dignity of ageing market leaders to look back--or even around".

Is there any way to send feedback to Amazon about that? How do they pick their reviews anyway? The above sounds like a review writen by someone with some strange grievances with Tcl and definitely by someone who is unfamiliar with many aspects of Tcl programming and who does not understand the beauty of the language. --Setok

And how about that twisted metaphor... Dick Clark and Howard Stern?? Someone needs to point that reviewer at http://www.wfmu.org


(strick) The first settlement condition for jerkcity [L12 ] to end the strike: 1. NOBODY HAS TO WRITE ANYTHING IN TCL FOR ANY REASON, EVER


Also see Tcl NG and Things holding Tcl back.


    Amazon.com

Despite its frequently obtuse syntax, Tcl/Tk enjoys a large and enthusiastic following. It's king of the world when it comes to building graphical user interfaces (GUIs) for C programs (particularly those running in X Windows environments), which is what the language originally was invented to do. Tcl/Tk (which is pronounced "tickle tee-kay," and which stands for "Tool Control Language/Toolkit" despite the abbreviation's unusual capitalization) is expanding its scope to encompass fields as diverse as voice scripting and molecular visualization. The latest edition of Practical Programming in Tcl and Tk, the fourth, offers an encyclopedic guide to Tcl/Tk that not only helps programmers solve problems, but enables them to conceive new applications for the language.


Erik Farley (quoted by permission):

Tcl/Tk makes the encoding of tool logic easy, with minimal support code required, so that the toolwriter can concentrate on business logic, which is what a tool (and a toolwriter) should do.

Tcl is the first step of a revolutionary idea, namely, create a language so simple and universal that nearly anybody could create business applications that would run on nearly any platform. Java does the crossplatform part, but only slightly better than Tcl/Tk. Java does NOT do the simple part. The Java scripting language "Groovy" reduces absurd 16-line "Hello World" GUIs to 3 lines, but it remains unacceptably Java-centric - meaning you still have to understand poetry before you are allowed to make a shopping list.

From the viewpoint of a linguiphile, Tcl is perhaps the Spanish of programming languages - simple, regular, teachable. Perl is more like French - evolved, beautiful, strange, but challenging in it's uniqueness. Perhaps the irregularity and universality of UNIX shell is analogous to English - successful in spite of its numerous flaws, with roots in both the command line (Germanic) and system languages (Romance). Java, in my mind, is Latin - all the power, and all the complication - but with a remarkable persistence despite all detractors.

LES: Interesting analogy with natural languages. But he clearly is not familiar with Tcl enough to judge. He wouldn't have said that "Java does the cross-platform better" otherwise.

LV I myself was thinking it might be fairer to compare Java to Esperanto than Latin.

RS Lisp is the most Polish computer language (always prefix operators/functions), and Tcl is mostly Polish (notation), with the exception of expr.

SYStems Well, I will have to disagree, expr is not an exception. I prefer if we think of expr in term of LOP (language oriented programming). expr is a math language/interpreter writen in/for Tcl. I think Tcl offer a good framework for creating new languages, like Expect, xotcl and wish. I am sure it was not always done intentionally or with LOP in mind, since LOP is not popular. But many feature are added to Tcl to facilitate creating languages in Tcl or create new language that transaprently interoperate with Tcl. Which I think is part of the Tcl "laissez-faire" genius.

RS Yes, but the expr engine, and "little language", is also used in the condition parts of for, if, and while, so it's not just a matter of one special command. Tcl made the compromise of doing arithmetics with infix operators, C-like, instead of doing everything in Polish (prefix) notation, like Lisp. But of course, it's a matter of taste whether you prefer

 expr {$a / $b + $c * $d}

to this Lispish construct

 [+ [/ $a $b] [* $c $d]]

Lars H: Come TIP#174 [L13 ], Tcl will provide both!


Chang Li: "Tcl has no intention to work for large programs. And it is good for drop-off software without reuse. And it works for internal use software not for commercial software." [L14 ] "Currently Tcl provides reuse support by extension and namespace. However these are weak to support large projects. For example, Tcl did not support the Tcl style object-oriented system like Tk in the Tcl source level. Can I define an object and use "$object action" in Tcl source? The answer is yes. But not in the core. You can download from somewhere to try. Why spent so many years without final agreement? Because the Tcl's vision for small programming is good enough. Today, OO may be more well known than Tcl itself. Without OO build-in support in Tcl, we are going to see more people switch to Python.

In summary, current Tcl is good at casual programming, other languages may be good for remains." [L15 ]

LES This bit above sounds a lot like "your-product-doesn't-have-the-feature-that-I-want-and-I-am-not-using-it-until-you-include-it". It does have a point, though.


[ Category Community | Category Advocacy ]