I wonder when Linux distros will start shipping 9.0 or 9.1. Even Arch is still stuck on 8.6, despite 9.0 being released two years ago.
trebligdivad 3 hours ago [-]
Tcl/Tk has got to be the easiest GUI system out there; you can get simple stuff going with no effort - nothing I've seen comes close to that simplicity.
Good to see it's getting some modern support.
agumonkey 7 minutes ago [-]
It hits a sweet spot for a lot of basic UI needs.
iamcreasy 58 minutes ago [-]
Is it still true if I want to custom widget with animations?
convolvatron 45 minutes ago [-]
I've done animations at the Tcl layer before with composition of Tk objects. for little visualizations its just fine, certainly not AAA
srean 19 minutes ago [-]
I have a soft corner for TCL, because of its idiosyncracies and weird dynamics playfulness. I would be wary of using it professionally but to play around for the fun of it ... it's too much fun. Upvar and uplevels are quite crazy.
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. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable).
neilv 41 minutes ago [-]
The biggest early selling point of Tcl was Tk, as a relatively easy way to make good-enough GUI programs with open source on Unixen and the X Window System. Even much easier than the easier-to-use X toolkits like XView with C, and it only got more difficult from there. There were no Web frontends.
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.)
giancarlostoro 34 minutes ago [-]
I think some of the "LAMP" type bundles use Tcl/Tk for their UI, kinda neat.
Aldipower 2 hours ago [-]
I once had an O'Really book named 'Perl/Tk'. I mean, I still have it somewhere... I've the feeling reading through it will maybe become my AI recovery therapy at some point?
gbacon 2 hours ago [-]
Perl/Tk is a lot of fun. I wrote a solitaire game called tktk — Tk Time Killer — that appeared in The Perl Journal.
In a way its distant nominative descendent, TikTok, is also a solitaire game.
Aldipower 2 hours ago [-]
This is very cool! The name alone. :-)
gbacon 1 hours ago [-]
Thanks! It was a fun project.
kevin_thibedeau 57 minutes ago [-]
Perl/Tk is a hard fork and hasn't fully integrated the improvements in Tk over the last couple decades.
qalmakka 28 minutes ago [-]
Tcl is way too smart of a language for its own good. I love how everything is a string or can be hacked on a string, so you can basically do levels of metaprogramming that reach unheard of levels
srean 18 minutes ago [-]
Not to mention uplevels and upvar.
neofytos 3 hours ago [-]
Congrats to the community and the core team. Their dedication to maintaining Tcl/Tk as a gold standard of stability, pragmatism, and lightweight cross-platform development is inspiring.
Many VLSI CAD tools come with a tcl console window. Im gratified to see the continued language support
Kudo’s to Mr Osterhout’s long lived legacy
bch 1 hours ago [-]
> 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]
It's unfortunate that Sprite itself didn't really get absorbed into much of anything, and so doesn't have much of a footprint and isn't really remembered outside of LFS and a few even more niche bits.
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:
I see this praise of tcl/tk a lot on HN, but everyone I know (myself included) absolutely hate working with it in VLSI CAD tools.
Karrot_Kream 40 minutes ago [-]
If you write Tcl/Tk from scratch for an application and architect it well, it's great. The way it's injected into VLSI tooling is an abomination. I've done both.
This 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.
kevin_thibedeau 53 minutes ago [-]
I like it better than the alternatives. The challenges come from vendors who had atrocious in house scripting languages (Synopsys) and then shoehorned their architecture into Tcl. You have to deal with a lot of opaque handles for things that should be native objects.
CamperBob2 53 minutes ago [-]
Indeed. If AI did nothing for me but deal with Xilinx's shit, I'd still nominate everybody from Hinton to Amodei for Nobels.
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.
wombatpm 53 minutes ago [-]
I remember using tcl inside pages running under Vignette Story Server circa 2000 before we started with jsp
baggachipz 2 hours ago [-]
I used it when I worked at AOL :)
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.
shaky-carrousel 2 hours ago [-]
And OpenACS!
fithisux 2 hours ago [-]
Or Kenny Tilton's celtk or cello?
sgt 3 hours ago [-]
The cool thing is that even if you take something arguably super modern, like the latest Claude models, it is able to write Tcl/tk applications for you that you might not have done at that level in the past. With tests in tcltest too.
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.
neofytos 3 hours ago [-]
I haven't tested this recently, but I bet it’s equally capable of writing custom Tcl extensions using the C API. Given how stable and clean the Tcl C interface has always been, it’s probably a perfect use case for LLM generation.
sgt 3 hours ago [-]
Yeah should work. So that makes it possible to do literally anything. Tcl always had one foot in the old days and one foot in the modern era. It's not like ALGOL or anything.
gbacon 2 hours ago [-]
The little language that could.
“Tcl tends to get ported to weird places like routers.” (Larry Wall, October 1997)
bch 50 minutes ago [-]
Tkinter[0] was apparently released in 1994, so mildly interesting he didn't say "Tcl tends to get ported to weird places like other programming languages."
Excellent to read Tk is getting better acessibility support. I love using it for quick little Perl/Tk GUI applications but I'm also slowly going blind from retinal tearing. It's good to see progress in some GUI toolkits when major desktops like KDE have dropped accessibility in their latest releases.
F3nd0 1 hours ago [-]
In what way has KDE dropped accessibility in their latest releases? (Genuine question; first time hearing about this, but I do not follow the space closely.)
gbacon 1 hours ago [-]
Sorry to hear about the retinal tearing. I hope advancements come along that work in your favor.
aarroyoc 3 hours ago [-]
Last time I checked, there was no Wayland support (other than executing in XWayland). Has it changed?
cmacleod4 3 hours ago [-]
Wayland support is being worked on, aiming for release in Tk 9.2 next year.
Tcl/Tk has saved me back in the day. The Windows distribution BAWT/Magicsplat are timely updated
..... but they do not come with Next Scripting Framework.
There was a new release on September 16, 2026
gbacon 1 hours ago [-]
In the early 2000s, I used the Tcl/Tk bindings to the VxWorks target management API. The application hotloaded and -unloaded test modules for a hardware in the loop lab. Tcl allowed the first working concept to come to life in a few days. I have no idea how long it would have taken with with C++ library.
2 hours ago [-]
csiegert 2 hours ago [-]
FFS, I clicked around for a few minutes and not a single screenshot of what the GUI toolkit is capable of. Even the highlights’ “Themed, Truly Native User Interfaces” chapter and the freaking docs that describe the widgets do not show a single screenshot. I’m shaking my head in disbelief.
Good to see it's getting some modern support.
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. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable).
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.)
https://blog.gbacon.com/publications/2000-perl-journal-tktk/
https://newsgrouper.org/%3C119gpah$3eu5q$1@dont-email.me%3E (Tcl) and
https://newsgrouper.org/%3C119gpbh$3eu5q$2@dont-email.me%3E (Tk).
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:
[0] https://en.wikipedia.org/wiki/Log-structured_file_system[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
[5] https://web.stanford.edu/~ouster/cgi-bin/aposd.php
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:
Of course, even by 1992, there were multiple versions of Tcl coexisting... :-)This 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.
Some throwbacks of his from 1999:
https://philip.greenspun.com/wtr/aolserver/introduction-1.ht...
https://philip.greenspun.com/wtr/aolserver/introduction-2.ht...
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.
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.
“Tcl tends to get ported to weird places like routers.” (Larry Wall, October 1997)
[0] https://grokipedia.com/page/Tkinter
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)
..... 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).