Tcl's Popularity

• Index for Tcl's Popularity
• First of Discussion
• Theories / contributing factors about Tcl’s low popularity
  • Low funding
  • No leader
  • No easy way to share and get code
  • The Tcl language itself is lacking
  • Tk is old
  • Tk is old-looking
  • Lack of useful Tcl applications
  • Low information quality/availability
• Discussion
• Out of sync? Many Younger Users are hungry for Mentorship
• A Core Problem: Version Ambiguity in TCL Code Generation
• TCL remained a specialized tool ...
• Revised Common Factors of TCL/TK Success
• Russell paradox

Index for Tcl's Popularity

First of Discussion

In 1998, Nicholas Petreley wrote an article for InfoWorld in which he said “I predict Tcl/Tk and Python will eventually gain the popularity Perl now enjoys” (1). He was right about Python, which has been the most popular programming language for many years now according to the TIOBE Index , but Tcl is not even in the top 50. (It is interesting that Perl’s popularity is coming back though. Perhaps Tcl can as well?)

Theories / contributing factors about Tcl’s low popularity

Low funding

John Ousterhout has argued that open-source software requires an associated profitable business to be successful (2). As of now (2025), that seems to be just ActiveState and businesses involved in EDA.

According to this Hacker News post , Sun Labs had a competition between Tcl and Java in which Tcl won (3). However, they ended up supporting Java anyway because they accidentally made Java super popular by open-sourcing their Java projects. If they had supported Tcl as planned, would Tcl be popular today instead of Java?

No leader

John Ousterhout left development of Tcl to the TCT around 2000. Some argue on Tcl Marketing discussion that not having a leader reduces public relations.

No easy way to share and get code

Tcl does not have current community package repository like CPAN or PyPI, although there have been many attempts.

• Teacup and Teapot
• Cantcl
• Procplace
• Tcl-Pkg
• Simple Tcl Archive Network
• See also Why isn't there a Comprehensive Tcl Archive Network like Perl's CPAN?

The Tcl language itself is lacking

• Some arguments on reddit. Some people seem to dislike that everything is a string.
• Richard Stallman also wrote Why you should not use Tcl back in 1994, when Tcl was in version 7.3.
• Who says Tcl sucks...

Tk is old

Tk does not support Wayland. A ticket was created about this in 2017, but there has been no work it, only discussion, mostly about relying on XWayland.

Tk is old-looking

Especially on Linux. See also: Tk is obsolete.

Image from TkDocs (4).

From Tcl Playground:

Lack of useful Tcl applications

On I worry about Tcl's future, peterc argued that "those who really want to make a concrete gesture towards getting TCL known should ... write software for the general public." More discussion on that page.

Low information quality/availability

This is my opinion. I am a hobbyist coder and find it difficult and frustrating that information in this wiki is dispersed and often outdated. This is typical of a wiki, but frustrating when paired with a lack of consolidated guides. (The commands reference is fantastic though.)

For example, when learning how to create a Tcl package, I looked at the Tcl Tutorial , which advocated for using the pkg_mkIndex command. However, the pkg_mkIndex page says it is "considered depreciated". I don't know if that is correct. Nothing in the reference seems to indicate that pkg_mkIndex is depreciated.

Another example, all the information about packaging in general is dispersed. There are so many wiki pages about it that I'm not even going to list them all here. Just take a look at Category Deployment. But there are many different ways to package Tcl code.

• Starkit (irrelevant with Tcl9?)
• Starpack (irrelevant with Tcl9?)
• Tcl Modules
• zipkit
• TEA

The Tcl Package Developer Guide does NOT explain how to write a pkgIndex.tcl file, but it does have a link to the package page, which has a link to The man page for pkg_mkIndex which does NOT explain how to write a pkgIndex.tcl file! Luckily, I found the pkgIndex.tcl page, which has useful information even though it is not a guide.

It is hard to find beginner-friendly step-by-step instructions for anything other than learning the bare bones of Tcl. It takes so much time to find needed information.

Discussion

Which theory holds the most weight for you?

Sources

1. Petreley, Nicholas. “The Salacious Truth of the Scripting Paradigm Shift to Tcl/Tk and Python.” InfoWorld, vol. 20, no. 39, Sept. 1998, p. 114. ProQuest.
2. Ousterhout, John. “Free Software Needs Profit.” Commun. ACM, vol. 42, no. 4, Apr. 1999, pp. 44–45. ACM Digital Library, https://doi.org/10.1145/299157.299168 .
3. Tcl Was the “language to Beat” amongst the New Language Products. Self Was the ’... | Hacker News. https://news.ycombinator.com/item?id=2380044 . Accessed 19 Sept. 2025.
4. TkDocs Tutorial - A First (Real) Example. https://tkdocs.com/tutorial/firstexample.html . Accessed 5 Dec. 2025.

Out of sync? Many Younger Users are hungry for Mentorship

gold 1/09/2026. My moniker is gold on TCL Wiki. I am a retired engineer and long time contributor to TCL Wiki. This last quarter, one of my offsite contacts asked for suggestions and gave advice on improving popularity of TCL/TK. I am trying to boil this advice down into diplomatic language. I do not have all the answers, But thank you for bringing the popularity of TCL/TK up.

gold 1/09/2026. Received Feedback Offsite & Advice >>> "Out of sync?, Consider that many younger users are hungry for mentorship, context, and depth." Younger users just don’t know where to find context, translating terms from their Gen Z or Gen Alpha Z Zoomers slang. One can be that lighthouse, but one may need to adjust your services to younger users { e.g. w/ AI semiotic indexing of yr tutorials}. Use AI to translate your signal into their Zoomer noise, then drop the signal anyway. The hungriest ones will eat it up. 1/10/2026 [L1 ]

gold 1/30/2026. Received Feedback Offsite & Advice >>> "Love Tcl? Contribute to modern docs, packages, human stories, or show real-world wins. Generally, Popularity follows demonstrated value, not just nostalgia." How did you discover TCL/TK need human stories and real-world wins????

gold 1/30/2026. Here is an example from experience: I asked for TCL code, but did not spell out Tool Command Language and version number. Several AI models came up with some very humorous alternates in almost a renaming contest for TCL.

gold 1/30/2026. I believe that part of "Vibe-Coding" problem is not targeting a specific TCL language version. If the user does not request version number and the AI model does see a TCL version number targeted in the pre-prompt. There is a lot of code for older TCL versions on the web without version info or best practices as currently defined. Then the AI Models are searching and looking at ' not modern code", " not best TCL practices", or file dependencies. But tell me different.

I notice that most of the TCL wiki code does not list TCL Version number or code version date on header Script. Little disconcerting when looking for examples of best practice.

gold 1/30/2026. I observed that Grok and other LLM models refer to using Python to check numerical results internally. See, I do pay attention. Since I assume that any language is available to your mind, what are your preferences and reasoning for picking Python over Tcl or another language? Libraries? Modern code availability? Environment?

A Core Problem: Version Ambiguity in TCL Code Generation

gold 1/30/2026. Tool Command Language has evolved significantly from version 7.0 through 8.0, 8.4, 8.5, 8.6, and now 8.7 and 9.0, with each version introducing new features, deprecating old practices, and changing recommended approaches. When users request "TCL code" without specifying a version number, artificial intelligence models face an impossible choice among decades of accumulated code examples scattered across the internet. The training data contains massive amounts of TCL 7.x code from the 1990s, substantial TCL 8.0-8.4 code from the early 2000s, and relatively less modern TCL 8.6+ code following current best practices.

gold 1/31/2026. The geometry manager problem perfectly illustrates this version confusion. TCL offers three distinct approaches for managing widget layout: pack, grid, and place geometry managers. Ancient TCL code heavily used pack for everything. Modern TCL best practices strongly prefer grid for most layouts due to superior control and maintainability. However, artificial intelligence models trained on mixed-era code often generate pack-based layouts simply because more training examples used pack, not because pack represents current best practice. The result produces working code that experienced TCL developers immediately recognize as outdated and difficult to maintain.

gold 1/03/2026. Added categories, so can find article in Wiki. The apparent originator or moniker of this page is [LJD] , but does not seem to have a Wiki bio, which would be useful for further discussion.

TCL remained a specialized tool ...

gold 1/30/2026. Government mandates or industry agreements have influenced adoption in specific cases but were not the dominant force across computer language history. Ada and COBOL (standardized via FIPS to protect federal assets in business data processing) show how government requirements can entrench a language in certain sectors. However, most widely successful languages—C, Python, JavaScript, and others—grew organically through community use, open-source contributions, and ecosystem growth without mandates. Mandates can accelerate adoption in targeted domains but often fail to create mainstream success if the language lacks broad appeal or flexibility.

Java is a clear example of strong industry support driving widespread use. Sun Microsystems released Java in 1995 with aggressive marketing (including a $500 million campaign), emphasizing "write once, run anywhere" portability. Sun built an ecosystem around the Java Virtual Machine, secured partnerships, and positioned it for enterprise, web, and mobile applications. This industry backing—later continued by Oracle after acquisition—helped Java become a dominant language in servers, Android, and large-scale systems, far beyond any single mandate.

TCL, by comparison, lacked both government mandates and equivalent industry consortiums pushing TCL forward. TCL excelled in rapid scripting and embedding (e.g., in tools like Expect or Cisco routers) but never received the coordinated promotion or standardization that Fortran, Ada, or Java did. Combined with technical challenges—such as ambiguities in list/string handling discussed previously. TCL remained a specialized tool rather than a foundation for major applications.

In summary, government mandates (like for Cobol and Ada) and industry support (like Java and Javasript) have been decisive in some cases, but they are not prerequisites for success. Technical strengths, timing, community momentum, and ecosystem maturity often matter more in the long term. TCL's story highlights how even capable languages can stay niche without those external boosts.

Revised Common Factors of TCL/TK Success

Note. How did you discover TCL/TK need here human stories and real-world wins????

Note. From offsite advice. "In 2025–2026, Tcl survives in legacy telecom/EDA tooling and Cisco automation; web usage <0.1% (W3Techs). Key factors in Tcl's drop: syntax quirks repelled newcomers. Python's cleaner readability won mindshare. And poor library ecosystem hurt Tcl adoption.Tcl's steady niche use in testing/automation beats total extinction."

Russell paradox

FM : Tcl could never become the foundation of any big applications, like word processor, sheets, drawing, or browser. Some peoples tried. They all finally gave up. Why ? Tcl is good to get a quick result that works in most cases, like a prototype.

But, when things become complicated, when there is tiny corner cases to take care of, Tcl is laking. Finally, Tcl can be correct 95% of the time, while it should have been correct 99.9% of it.

Russell's paradox shows that you can't operate on an ensemble as you would do on an element, without falling in a fatal contradiction.

In Tcl, an ensemble is a list, an element is a string. And {} is either the empty list, either the null string element. This lead sometimes to fatal ambiguities, leaving the programmer without any solution on how to correctly interpret the data. Illustration :

set x {}
expr {$x in $x}; # return 0 : the empty string is not in the empty list / the element $x doesn't belong to the ensemble $x : $x ∉ $x
set x a
expr {$x in $x}; # return 1 : the string "a" is in the list "a" / the element $x belongs to the ensemble $x : $x ∈ $x

From this, shall-we conclude that Tcl has no list ?

proc contrariety {x} {
   if {$x eq $x && $x in $x} {
      return 1
   } else {
      return 0
   }
}
# shell results:
% contrariety a
1; # the string a is in the list a
% contrariety b
1; # the string b is in the list b
% contrariety {}
0; # the string {} is not in the list {}
% contrariety { }
0; # the string { } is not in the list { }
% contrariety { a }
0; # the string { a } is not in the list { a }
% contrariety {{ a }}
0; # the string {{ a }} is not in the list {{ a }}
% contrariety {{{ a }}}
0; # the string {{{ a }}} is not in the list {{{ a }}}
%  expr {[contrariety a] eq [contrariety {{ a }}]}
0; # a and {{ a }} are not treated the same
% expr {[contrariety {}] eq [contrariety {{{  }}}]}
1; # {} and {{{ }}} are treated the same.

Is-it really consistent ?

How to get rid of the ambiguity ? Historically, the common resolution of Russell's Paradox implied to introduce the notion of type. This is what lead to proof assistants in mathematics. This type can be seen as a metadata associated with the value. That's why I like this to be introduce, to handle all these annoying corner cases. The only way to achieve it in a backward compatible manner is to use braced-prefixes.

Then we can write :

set {list}x {}
set {string}y {}

expr {$x in $y} ; # should error "y is a string" / actually -> return 0 = NOK
expr {$x eq $y} ; # should return 0 : the empty list $x is distinct from the empty string $y / actually -> return 1 = NOK
expr {$x in $x} ; # should return 0 : the empty list $x doesn't belong to the empty list $x / actually -> return 0 = OK
expr {$x eq $x} ; # should return 1 : the empty list $x is equal to itself / actually -> return 1 = OK
expr {$y in $x} ; # should return 0 : the empty string $y is not in the empty list $x / actually -> return 0 = OK
expr {$y eq $y} ; # should return 1 : the empty string $y is equal to itself / actually -> return 1 = OK
expr {$x in [list $x]} ; # should return 1 : the empty list $x belong to the ensemble [list $x] / actually -> return 1 = OK
expr {$x in [list $y]} ; # should return 0 : the empty list $x doesn't belong to the ensemble [list $y] / actually -> return 1 = NOK
expr {$y in [list $y]} ; # should return 1 : the empty string $y belong to the ensemble [list $y] / actually -> return 1 = OK
expr {$y in [list $x]} ; # should return 0 : the empty string $y doesn't belong to the ensemble [list $x] / actually -> return 1 = NOK

In these 10 situations, Tcl is wrong 4 times, because of this confusion between ensemble and element. Worst, sometimes Tcl is right, but for bad reasons... Ok, you may say this is just tiny corner cases. Well, to make a good software, we need to be able to treat those with precision.

Another possibility,

set {string}x $whatever
expr {$x eq $x && $x in $x} ; # should allways return 1 : a string taken as a list is itself, so, it contains itself.
set {list}y $whatever
expr {$y eq $y && $y in $y} ; # should allways return 0 : no list can contain itself.

So what happened ? Tcl is very intuitive, like Frege ensemble theory. But it has a fondamental limit which kept it back.

Once we can distinguish clearly between string and list (at least optionnaly), we can modified things a little bit

# given :
set {string}s1 abc
set {string}s2 abcdef
expr {$s1 in $s2} ; # should return 1 : the string $s1 (which is abc) is a part of the string $s2 (which is abcdef)
# But
set {string}s1 abc
set {list}s2 abcdef
expr {$s1 in $s2} ; # should return 0 : the string $s1 (which is abc) is not a member of the list $s2 (which is abcdef)
# given :
set {int}i 5
set {int}j 20
expr {$i in $j} ; # should return 4 : the int $i (which is 5) is in the int $j (which is 20), as factor of the int 4.
# But
set {string}i 5
set {string}j 20
expr {$i in $j} ; # should return 0 : the string $i (which is 5) is not in the string $j (which is 20)

Stallman gave his opinion about this during the famous Tcl war. He was not totally wrong, Tcl was only a script language then, not a real programming one, because real programming language need to offer the notion of type, because of Russell's paradox.

Nobody could never hear his claims, Stallman was partial and dishonest, really ? Then TCT continuously refuse to think about the notion of type, how it emerge to solve the Russel Paradox of naïve ensemble theory.

People says types are contradictory with EIAS. Is-it true ? Command names and variable names are strings. But there is a big machinery behind the scene. A command name is a key in a hashtable of commands, a variable name is a key in a hashtable of variables. The type names would be strings, too. But they would stand as key in an hashtable of types.

IMHO, the solution is to implement type in Tcl. You will see, with all the stuff that is there, Tcl will quickly improve its popularity.

gold 2/02/2026. FM Would you and other Wiki members be willing to co-author a proposed wiki page on a namespace workaround for typed variables. I can’t speak for others, but a namespace-based starter page on typed variables (your idea) would be educational for me. Proposed name of new Tcl Wiki page =equals= "Simulating Typed Variables with Namespaces." Themes would be safe variable handling in scripts and improving reliability in algorithmic code. Page-name signals proposed namespace might be a practical workaround and research for some limited algorithmic tasks, not considered a replacement for core and not to overpromise a core change here.