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: <199705101952.MAA00756@wall.org> ''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 conjunction 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: <199710071721.KAA19014@wall.org> ''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: <199710071721.KAA19014@wall.org> ''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]: [http://www.vanderburg.org/Tcl/war/0000.html] ''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." [http://content.techweb.com/wire/story/TWB19980824S0012] 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: [http://www.oreilly.com/catalog/pythonwin32/chapter/ch20.html] ''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: [mailto:ink@inconnu.isu.edu] ''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." [http://www.sunworld.com/unixinsideronline/swol-02-2001/swol-0202-regex.html] Randal Schwartz: "If it weren't for Tk and Expect, TCL wouldn't even be around now." Randal [http://www.stonehenge.com/merlyn/] says this in public reasonably often, and occasionally he writes it [http://groups.google.com/groups?hl=en&selm=m11yg5ozds.fsf%40halfdome.holdit.com]. [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" [http://www.kudla.org/raindog/tcl/] - 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: [http://www.usenix.org/publications/library/proceedings/tcl95/kernighan.html] ''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 [http://groups.google.com/groups?q=algol+pascal+group%3acomp.lang.tcl*&hl=en&lr=&scoring=d&selm=3D0076DB.9DF58F4F%40siemens.com&rnum=1]. 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:slrnagc42u.167.fp@rose.fpx.de : [[...] 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 [dict]ionaries.)'' [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:[http://www.amazon.co.uk/exec/obidos/ASIN/0130385603/qid=1032368450/sr=2-5/ref=sr_2_3_5/202-2172097-6608616] 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 [http://www.jerkcity.com/jerkcity742.html] 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 [http://tip.tcl.tk/174.html], 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." [http://groups.google.com/groups?selm=89cc6e1f.0411150959.52cb7346%40posting.google.com] "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." [http://groups.google.com/groups?selm=89cc6e1f.0411161220.112d1c36%40posting.google.com] [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. ---- Raph Levien, noted Gnome hacker, has this to say: "Another very important axis is the choice of programming language for the app. If your language rocks at strings but sucks at everything else (like Tcl), then obviously having the GUI toolkit treat everything as strings is a good thing (hence Tk)." : http://www.advogato.org/person/raph/diary.html?start=398 (but on the other hand he praises Tk's simplicity of passing strings around in an entry a few days older) ---- [[ [Category Community] | [Category Advocacy] ]]