Python is that kind of cool one behaves when visiting parents of your would be spouse for the first time. Tcl on the other hand is like playing one's secret exclusive and somewhat dangerous games with kid school bestie.
Tcl/Tk pioneered the notion of a scripting language as a library. It got threading right. You can run multiple independent Tcl interpreters in the address space of your process and they can exchange messages. Entirety of interpreter state is encapsulated inside the interpreter object, no globals. To a user an it is just a pointer to an object.
No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable).
This was their attempt to position Tcl as an alternative to JS. The sub-interpreters were introduced as controllable sandboxes for running untrusted code with reduced privilege. Instead we got a web scripting language that allows untrusted code to interact with your USB devices. Python sub-interpreters are a joke compared to what Tcl has.
Tcl itself was quite clever as what I'd actually call a string-based scripting language (contrast with Bourne/C-shell/etc. that preceded it on Unix).
Originally, Tcl was among the handful of off-the-shelf extension languages. You write your big application in C or C++, and then you embed an interpreter for a higher-level extension language, for users or the original developer to add on functionality. The options at the time were usually a small Lisp/Scheme, Tcl, Python, or something entirely bespoke and probably quirky and half-butted.
During early dotcoms, there was considerable interest in Tcl for backend work, and it also wouldn't have been the worst choice to put into the browser. Like Python, Tcl would've been more accessible and democratizing-the-Web than JavaScript, and there were already solid off-the-shelf designs and implementations. (Scheme would've appeared slightly more intimidating than Python or Tcl, and was more powerful, which I think was why Tim Berners-Lee preferred Python over Scheme as the people's programming language for various Web purpose. The semantics of the JavaScript we got was more a hurried toy Scheme, plus the simplest object model, and a more intimidating syntax that came from systems programming.)
I loved it back in the day, tons of fun to configure with code, somehow friendly enough for me to play with in high school with no background knowledge and only some man pages to help me. Coupled with a lightweight WM like CTWM https://www.ctwm.org/index.html it lead to a really performant desktop on the single-core ~400mhz machines we had in our computer lab....
Didn't Cisco use Tcl in one of their IOSes? Found it: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
You're not that old, are you? :) Before www, expect was the way to go.
Good to see it's getting some modern support.
From D. Richard Hipp [1]:
"SQLite is a TCL extension that has escaped into the wild.
"The design of SQLite was inspired by the design of TCL, both in the way it handles datatypes and in the formatting of its source code. The index use case for SQLite was in a Tcl/Tk application for an industrial company. From its inception, SQLite has always depended heavily on TCL. These days, SQLite no longer uses TCL internally and can be run separately from any TCL interpreter, and yet the SQLite development process still depends heavily on TCL."
[1] https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...
https://blog.gbacon.com/publications/2000-perl-journal-tktk/
Kudo’s to Mr Osterhout’s long lived legacy
Tcl and Tk are fantastic, and if this is where it ended, John Ousterhout would have secured his place in history - this is only 1 piece of his contributions, though - see too:
* Log structured file system[0]
* parallel Make[1] (Adam de Boor from Sprite project, not JO hisself)
* RAFT consensus protocol[2]
* Various notable teachings [3][4][5]
[1] https://man.freebsd.org/cgi/man.cgi?query=bmake&sektion=1
[2] https://en.wikipedia.org/wiki/Raft_(algorithm)
[3] https://en.wikipedia.org/wiki/Ousterhout's_dichotomy
[4] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
But I think the Sprite kernel and the Sprite-specific libraries (Pfs, Pdev, Fs_Select, Td_), as well as the Sprite-specific userspace, were pretty incredibly pieces of software given the limited resources they were created with.
For that matter, John Ousterhout's text editor and terminal emulator, mx and tx, were the substratum that Tcl was built on. There's a single library on Sprite, libmx, which mx and tx are based on. Tcl basically grew as the command language of libmx, originally two separate entities, then by mx 2.4 it was fully incorporated:
eery@cherimoya [1] > cd /sprite/src/lib/mx
eery@cherimoya [4] > grep Tcl *.c
mxCmdAM.c: Tcl_Interp *interp;
mxCmdAM.c: Tcl_Return(interp, Cmd_BindingGet(mxwPtr->cmdTable, argv[1]),
mxCmdAM.c: interp->result = Tcl_Merge(bindingCount, bindings);
mxCmdAM.c: Tcl_Interp *interp;
[...]
eery@cherimoya [10] > grep LIBS ../../cmds/mx/local.mk
LIBS = -lc -lmx -lsx -lcmd -ltcl -lX11
eery@cherimoya [11] > ls /sprite/lib/sun4.md | grep tcl
libtcl.a
libtcl5.a
libtcl6.2.a
libtcl6.3.aThis is partially because when Tcl was first incorporated in VLSI tools it didn't have a good way to organize and modularize code. But this is also because the big VLSI tool shops realize they basically have a monopoly on their integration surface and have no incentive to improve it.
It's easier to freeze the integration surface and maintain backward compatibility than it is to move the surface forward.
https://newsgrouper.org/%3C119gpah$3eu5q$1@dont-email.me%3E (Tcl) and
https://newsgrouper.org/%3C119gpbh$3eu5q$2@dont-email.me%3E (Tk).
If you understand how generative models and agentic coding works, it's not a surprise. But for some reason it's still mind boggling to think that you can take very old stuff and build impressive programs.
It's a Lisp with syntax sugar and no macros.
The startup I joined in 1999 had its own application server loosely based on AOLServer architecture.
We had Apache + mod_tcl, IIS with our own ISAPI extension, then in box connections for all major RDMS across all key UNIXes and Windows NT/2000.
Some left to join companies doing Vignette projects, others eventually created OutSystems redoing the same ideas, but with the newly released .NET.
However it was also a lesson in performance issues, and the constant pressure to rewrite Tcl code into C extensions.
Was great for rapid prototyping and a/b testing in volume. Not sure I'd pick it ever again for anything, but it was interesting for sure.
Some throwbacks of his from 1999:
https://philip.greenspun.com/wtr/aolserver/introduction-1.ht...
https://philip.greenspun.com/wtr/aolserver/introduction-2.ht...
One can not even find it on TIOBE but one can find COBOL there:
https://www.tiobe.com/tiobe-index/
(TIOBE is horrible, but still.)
[1]: https://redmonk.com/sogrady/2026/04/14/language-rankings-1-2...
See: https://wiki.tcl-lang.org/page/GSoC+Idea%3A+Tk+Backend+for+t...
i'd expect sdl, given wider platform coverage (e.g. mobile), more system integration (e.g. clipboard), and an existing port (https://androwish.org/home/dir?ci=trunk&name=jni%2Fsdl2tk)
I ended up really disliking tk.
Using ruby-gtk2 and ruby-gtk3 was much nicer. (Sadly, gtk4 sucks, so that's the end of the story there.)
I kind of want a universal toolkit that works everywhere and is also good. Right now I use ... well, either the web (that's ok, though I hate how I can not easily open local files and so forth, without having to use node), or swing via jruby-swing - which semi-sucks, but it also works on windows and it actually is not that bad. (I could use javafx etc... but it is so much easier to get started with swing). I also use libui-ng which is ok but lacks many features, sadly.
..... but they do not come with Next Scripting Framework.
There was a new release on September 16, 2026
Also https://cgicoffee.com/blog/2026/04/tcl-tk-develop-cross-plat... (takes a little time to load).