Who says Tcl sucks...

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!"

JMN : I'd much prefer to thank the people who built it, and the community of users & hackers who help to evolve it.

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 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
<[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 ].

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: About Tcl and popularity 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:

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 written 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.

On 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.

AMG: Obtuse??? Tcl's syntax is far more regular and understandable than that of more popular languages such as C++ and Java or even Python. The difficulty is that, linguistically speaking, Tcl's syntax is in a different class--- it's not a bunch of keywords and tokens and such--- and this makes it alien to the myriad descendents of Algol.

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 its 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 Actually, Erik is a friend of mine. He's been writing Tcl code for years. I don't know, however, whether he has written much Java code.

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

Kuoso I'd say Java is most like Latin, for pretty much the reasons given. I'd say that Tcl is like Esperanto (easy, regular, works well cross-platform but the interpreter isn't on a majority of machines) and Perl is like English (complex, but if you speak it fluently you probably like it; also theoretically cross-platform but only really runs on Unix-likes).

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 written 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 transparently 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.

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)

WJP In reacting to statements such as these, I think its important to recognize that many of them are true and were fair when made. Tcl did start life as an extension language with some severe limitations. When I first encountered Tcl I was interested in it as an extension language but rejected it in part because it didn't have floating point numbers which were important for my purposes. As I recall, it didn't have traces yet either, and that was another problem for me since the language I was considering using it to replace had traces and I made extensive use of them. Tcl has added quite a few capabilities since the early days, has become a good deal more efficient, and has shifted its orientation from being an extension language to general purpose scripting and use for fairly large and complex programs. Rather than sneer at people who had problems with earlier versions of Tcl, it would be more effective to point out that Tcl has changed and the criticisms are no longer valid.

Sure, you're correct. To do so would require much more and better interaction with a vaguely defined entity called "the open source community", though. I don't see anyone posting anything to advogato to correct raph, for instance (I'll do it myself, later, I guess). For whatever reasons, Tcl has moved rapidly to the margins of the open source world. We're not present at their conferences, we're not involved in local groups, we're not involved in other open source projects where "cross-pollination" could happen, and so on. Of course I'm generalizing, but by and large, I believe the above to be true, with some exceptions.

EKB - Increased participation in conferences, etc. seems important. But there does seem to be a Tcl presence in open source. SourceForge lists 905 projects that include Tcl as one of the programming languages (about 1/2 the number of Delphi projects). Of course, C++, Java, C#, etc. have more, but that's to be expected. The point is that it's a definite presence. On Freshmeat, there are 423 listed Tcl projects.

davidw - the important thing in this case is "community", not projects. Code is important too, but my point is that Tcl has dropped off the radar completely in part because of our community's isolation. RLH And that is a good observation. The question is, why IS the Tcl community isolating itself? EKB Yes, it is a good question. Here are two theories - feel free to shoot them down. First, there don't seem to be many Tcl zealots. I myself have a "live and let live" attitude toward other languages (or, rather, a "the more the merrier" attitude), and my impression is that this attitude is not so rare in the Tcl community. Do you need zealots to make a strong presence? Second, Tcl has some seriously functional forums (fora?), including this Wiki. Speaking for myself, I just don't feel a great urge to look elsewhere. (I do visit a couple of other general programming sites from time to time.) Maybe others feel similarly? RLH You are probably correct. My concern is that if the Tcl community doesn't look up every once in a while and see what the world is doing that it will stagnate from lack of "new blood" because Tcl is the hidden (though an extremely useful) language. Lars H: Hmm... Tcl--The Concealed Language? Or perhaps The Clandestine Language? Sometimes it is good to have a name even for things we want to avoid.

I see a lot of mention of Tk on this page regarding other toolkits. Yet, when I look at other languages, they are moving away from Tk and mostly to the wxWidgets UI framework. All the others (Python, Perl, Lua, Ruby) have bindings at some level of maturity.

http://www.kde.org/announcements/announcement.php (KDE Project announced, Matthias Ettrich, 1996): "I really recommends looking at this library Qt. It has ... the power to become the leading library for free software development. And it's a way to escape the TCL/TK monsters that try to slow down all our processors and eat up our memory". ... "You might wonder why I'm so against Tk. Well, I don't like the philosophy: Tk's doesn't have a textwidget, for example, but a slow wordprocessor. Same with other widgets. In combination with TCL the programs become slow and ugly (of course there are exceptions). I didn't yet see any application that uses Tk from C++ or C, although an API seems to exist. TCL/TK is very useful for prototyping. Ideal for example for kernel configuration. And since Tk looks little similar to Motif, the widgets are also quite easy to use. But I really don't like any TCL/Tk application to stay permanently on the desktop."

vkvalli Are we building software on sound foundation-?. I think Alan kay's remarks on present software trend is very insightful.(I will bring the link later). The whole world is experiencing a pop-culture. Even the intellectual world. What is happening is something not of lasting value, becomes hugely popular and remains so for some 4-5 years and goes out of the scene in 10 year.

This one could see with management philosophy trends like TQM(total Quality Management), BPR(Business process re-engineering) etc. The same way in IT industry. Part of the reason is media, internet and information explosion. Strong media leads to hype-amplification faster. Meaning the growth of hype with reference to time is faster than before. In 3 months, one would come across some 20 internet articles claiming some xyz technology gives productivity gains of 20 folds. Whereas in absence of internet, it will take 1 year for one to come across 20 articles in print media.

Another effect, is people spend more time in information consumption than processing.Meaning we don't spend that much time in reflection compared with reading. People keep embracing something intensely and then after 5 years another etc.

More specifically, new languages are crafted without much thought just to address a specific need. After a point the whole system is made of incompatible language pieces.

Typical example is Web-technology. For browser side scripting - javascripting. For sysadmin - perl, python, ruby, tcl. For shared hosting - php. For enterprise level - java. I don't think javascript is developed with lot of thought. Most are developed under a time-pressure to meet a short-term need. Same way perl , php etc. Everyone felt perl will dominate cgi. But because of its design, the performance was so pathetic that the only alternative that came around was php and everyone embraced it.

It did not have full-fledging programming language facilities and did not scale and people had to use java for complex stuffs.

Therefore we can forget trying to make TCL popular. Just make it a language that scale from small and big. New languages keep coming and going. Media needs to make "News" for them to be in business. There are always people getting sold out by the "anxiety" those news create. These news creates the feeling that "if you are not using it, you are missing something 'big' ". People are lured to jump in. and keep jumping in one after another.

I came to TCL after trying other languages and quite deeply ruby. I feel TCL will hang around for a longer time, in terms of decades. Rather than shine bright and fade language.

I am more for simplicity and scalability. If TCL evolves, deviating from its original simplicity philosophy, it will also suffer the same fate.

iu2: Taken from http://www.python.org/doc/Humor.html#vowels

"Tcl -- It is short (only three letters) and does a surprising amount given that it doesn't have a vowel. It can be pronounced "Tickle", which is a command.

Perl -- Bigger and has a vowel. However you'll note that it isn't a common english word; you'll have to know what you're doing to use it, especially with spell-checkers which otherwise complain that it looks like noise.

Python -- This is a Real English Word (honest, look it up!) that happens to refer to a type of snake, which you'll notice is an object. With the two vowels, python is quite readable."

TclAdvocacy: ESRs chapter on Tcl and some corrections

iu2 - See http://antirez.com/articoli/tclmisunderstood.html A quote from that site: "there is no language that is as misunderstood in the programming community as Tcl is." Also http://www.tiobe.com/tpci.htm ranks tcl 39 (for January 2007) right after CL. Just for comparison, Pythom ranks 8 and perl - 6... But I think having CL as a neighbour is quite a compliment ;-)

wjp By and large the Tiobe stats are not surprising, but I do wonder a bit about the methodology. The rankings seem to be based on search engine hits, which means that they reflect MENTIONS of the language, not necessarily programs or lines written or jobs offered. They presumably including people talking about how they would use language X for something if not for some reason or other, and people talking about how bad a language is. It isn't entirely clear to me what this kind of ranking means.

The one datapoint that struck me was the relatively high rank of D at 14. D looks like an attractive language (when you want something at roughly the C/C++/Java level) but I've hardly ever heard of anyone using it. Does it really get that much use?

Steve Blinkhorn I'm interested to note that the Tiobe rankings profess to be based on numbers of lines of code written. So long-winded languages get an automatic leg-up, whereas succinct languages don't get credit for powerful simple expression. I'm also intrigued to know how they know how may lines of code I and my colleagues wrote in Tcl in the course of 2006. All in all, it seems to be more about energy expended than outcomes achieved.

http://lambda-the-ultimate.org/node/908 is an older discussion (circa 2005) in which Tcl was recommended by Neil M (Neil Madden) for a particular need and forum member Andreas Rossberg objected to the suggestion. Neil M brings Tcl up again at http://lambda-the-ultimate.org/node/992 . There are more than a dozen pages on this site that mention Tcl.

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.

Stu 2007-11-13 What the h*ll does this mean, anyway? Sheesh.

AMG: Guido may not know it, but he has paid Tcl a compliment. Not having syntax to hold your hand means you're in charge.

EKB When I first read that quote, it just sounded bizarre. But I wanted to think about it, because GvR designed a really lovely language (IMHO), albeit one that attracted an annoying user community (also IMHO). Just reading the Python threads turned me off from seriously using it. After puzzling over the quote I finally decided that the sentiment behind it is tied to what makes the Python user community so annoying. The language is a lovely but elaborate structure that the community thinks is just right. In this mindset, if someone thinks some aspect of the language is sub-optimal then, well, that's their problem, not Python's. With this mindset, Tcl, which isn't built that way, can't be any good. I guess Python's more like a cathedral, whereas Tcl is so simple it just invites anyone to try things out, extend the language, etc. Sort of like a buzzing bazaar. Hm... cathedral and bazaar... I think there's a book title in there!

Tcl might not be viable because it is too hard to hire Tcl-savvy employees

I have to admit I would have second thoughts about hiring anyone who actually liked to program in TCL. Any large project written in TCL essentially has to be rewritten if you make any changes. No syntax, no debugger, no IDE. Please... get real.

slebetman: The above quote was written by goffster. Can goffster please attribute the quote to who said it?

Get real? Debugger? Maybe Tcl is SO SIMPLE you don't have to use a debugger. Debuggers are for bugger people.

Sarnold agrees. For those who feel angry with debug traces, there are real options. There are pure-Tcl debuggers - Yet another Tcl debugger is just an example. Furthermore, it is very easy to introspect a running application, say, adding Tkcon to your application.

AMG: Simplicity is only recognized as a virtue when aggressively marketed as such; otherwise it's regarded as unsophisticated and immature. Simplicity that must forcefully call attention to itself is often not simple at all when objectively considered, so many in the programming community have distorted perceptions. And so, the "problem" with Tcl appears to be that it's uninterested in groupthink and hype and is instead satisfied to remain simple yet technically superior.

Over at [L16 ] during late March, early April 2009, an article was posted about 25 open source project releases that were anticipated. One commenter added a note about Tcl 8.6. Replies to this posting criticized Tcl for lacking a real parser while a second commenter listed the lack of a collected reference including both the core features and all the major libraries. With index, of course!.

I just ran across [L17 ] which discusses the Tiobe Programming Community Index [L18 ]. Apparently Tcl is no longer popular enough to make the top 50 programming languages.

jbr 2013-01-14 And yet if you visit the TIOBE index you'll see that Tcl is ranked 49th. Apparently someone can't read.

CGM 2013-01-14: Dr.Dobbs article The Rise and Fall of Programming Languages in 2012 contrasting with Lua, says "Tcl meanwhile continues its decline, which has been attributed by insiders to core design issues, slow releases, and poor marketing decisions."

jbr 2013-01-14 David Welton's article, cited in the above DDJ article is dated 2010 and is a look back over the past decade. I think that Tcl's slow and conservative progress is spot on for a mature language. I'm quite pleased with modern features of 8.6 and even more pleased that my 15 year old scripts still run.

AM 2013-01-15 The Dr.Dobbs article also seems to have a very narrow view as to what programming languages are used for, though I admit that I have scanned it only. It seems to focus on mobile applications.

Zipguy (2013-01-15) - NOT ME! From my site [L19 ] "I like TCL. It is a robust language, but hard to understand, because there are so many options."

I'm a lot older than most people, 55+ years old. I've got to see Languages come and go. Tcl has been around since the late 80's, which makes it around 30 years old. It may be difficult to find the command you are looking for, finding the subcommand that will interest you, and try it. Tcl excels at this, has good documentation, it is freeware, that runs on almost any machine (with which, you may have some difficulties).

The best thing about Tcl is that there are people who know it, inside and out. If you're having a problem, you can post a page on it here at Wiki, and hope that type of someone, will help you out. I have been helped out, but Tcl does work extremely well on Windows, and gets most of the job you're attempting to get done, fairly easily, than in many other languages, sometimes, in a surprisingly small amount of code.

CGM 2019-05-03: In a Hacker News discussion Next-Paradigm Programming Languages: What Will They Look Like? user "spiralganglion" says "Yes, it's possible to make a terrible mess in a visual language. But the same is true of text languages — we had to learn the hard way not to goto, not to do TCL style string-based metaprogramming."

CGM 2022-06-01: In https://news.ycombinator.com/item?id=31113802 "bitwize" says "Attempting to understand how variable scoping works in Tcl is like attempting to stare into the maw of some eldritch horror, deeper than the earth itself by some trick of other-space, and lined with infinite rows of writhing, fang-tipped cilia. The central tenet of lexical scoping -- that bindings visible outside a set of braces should also be visible inside unless overridden with a specified inner binding, didn't occur to Ousterhout when he designed Tcl and Tcl has to deal with the implications of that. 'upvar' sometimes works, but sometimes doesn't, and in some cases you have to reason through when your code is being called and what's visible then."