A fun one: PostgreSQL uses an adopted version of Tcl's regular expression engine, written by Henry Spencer. Tom Lane seems to think it was an impressive piece of work, and patched it up from time to time.
I use Tk routinely in Scheme; there is no Tcl in my code, but Tk is a very nice (though basic) GUI kit, and my programs work on Linux, BSD, MacOS, and Windows. Other commenters have mentioned that Python ships with Tkinter, a library module that interfaces to Tk. I believe Ruby does the same. Hell, if you're programming in Cobol, you can have Tk (as long as your Cobol allows you to call C). You do not have to love Tcl to love Tcl/Tk.
>you can have Tk (as long as your Cobol allows you to call C).
No C required, you can just connect to the UI through a socket and often skip the FFI completely. This is my preferred way to use Tk and I don't even consider anything else unless there is a reason. Working this way also has the nice side effect of making the application UI agnostic.
Believe you have to do that anyways unless you are going to create full language bindings as tkinter and the like do. I don't know the Tk API in full but I don't believe it provides ways to create widgets, just interact with them more directly. Perhaps someone more knowledgeable will fill in the gaps here, I learned what I needed of the Tk API and called it good.
in what way is Tk basic? can you elaborate? also what are your thoughts on the issues with python as mentioned in the article? how do the scheme bindings compare?
I was an early adopter of the TiVo. You can hook up a terminal to those things. A dumb terminal or terminal software on your computer using your own serial port. There was a terminal/serial port in the back (baud 2600)that took the form of a 3/4" audio plug.
It was a Linux system, but all their own software running on it was written in TCL.
I don't think they were using TK though.
Pretty fun to hack around with. Since it was connected to the phone line, when a call came in it could get the caller ID off the line and display it on the TV screen.
Well, they talk about the "barebones" Tcl version - tbh, I didn't even really know that was an issue in Python, and he is right that you have to remember to install it, and basically whenever I get a new computer I screw it up the first time until I remember the right incantations to spew at pip install or apt install to get it to work? So, "sure," there are some issues there. And to be fair, trying to do modern kind of interfaces with Tkinter in python and ttk can be kind of tricky/impossible? The part about it being "awkward" is definitely true.
But it's "good enough" like 99% of the time? And going from 0 to "something with a button a user can click" is crazy easy. At my old job, before I started working for myself, I built some painfully sprawling python script to:
1) Spin up a selenium browser to access something in servicenow that they wouldn't let us query the API for but required we access
2) Control the downloading of a bunch of files from a tk interface from python
3) toggle various settings and parse through a bunch of downloaded spreadsheets from there and another website that had some data on
4) python and matplotlib then drew pretty pictures for management
5) python then spit out documents and charts in various formats
6) then a button click triggered it all to process in parallel and opened an email to the appropriate managers that I fire off
This turned something like 10-40 hours of manual work (depending on how well you knew how to do it) where you were clicking and reading into like a 15 min job that I could do on the first of the month while I drank my coffee.
I'm sure it would probably be "better" to write the whole program in Tcl/tk, but sometimes I am lazy. Also, if I'm doing something with pandas or AI and the tk gui is just something slapped over the underlying logic and code. I guess it's a matter of preference? But tkinter is "pretty good" and often "pretty good" is way better than perfect.
They say in the article something like, "if you don't need to call python libraries just use tcl/tk" or whatever. And that's fair, but honestly, being able to throw pandas at something or matplotlib or whatever is super valuable. I think in the future maybe it'll be easy to do something like, "claude please port matplotlib into tcl" and then you can do it natively, that would make sense? Or maybe even like they say it might be cool to make a python script then call it from tcl like they say? but multiple scripts in different languages seems like a bit of a maintenance headache? Though that also might be just a skill issue on my part lol. It might be lazy of me but staying in one language has some advantages, namely, I don't need all the boilerplate argparse code for each thing in python I might want to write.
When I wrote the monstrosity above, I didn't really know anything about tcl/tk other than "isn't that that archaic ui thing?" I actually played around with raw tcl during the process of writing that beast, but that was mostly just for fun.
I guess my real response is, if I end up in a knife fight with a GUI layer over python again, the way they describe in there might be what I do? Calling the python from the tcl might be the optimal choice? It'd be fine to stretch the brain in a slightly different direction anyway.
trying to do modern kind of interfaces with Tkinter in python and ttk can be kind of tricky/impossible? The part about it being "awkward" is definitely true.
that sounds a bit worrying. can you give some examples?
from the article i was specifically wondering about this:
And yet still, even with ttk, Python doesn't automatically pick the best theme for the OS! It often defaults to "clam", "alt", or the dreaded "classic" on Linux, which look dated. It's a mess of a Tk bridge! ... the provided bridge to it is clunky
so is it just the perception? sounds like i should just have to remember to pick a better theme. (and use ttk)
and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
Its because tk does not have a central event loop built in. You can't use modern programming techniques without building up a significant scaffolding to get multiple UI elements updated based on an events generated in various places. It requires an observer pattern + a self defined callback event generation scheme to collect events (singleton pattern).
Sure you can make this module and there are probably things out there, but you need to wire it up yourself before you even get to the application logic.
It's not bad per se, but even something like a dark mode is a giant pain in the ass.
Last time I had to make a quick tkinter interface was like a month ago for a project I was working on just for me and I wanted a cleaner interface and I just had codex do it and it was "fine" - like nothing to write home about but "fine." If you're trying to get the most out of your macbook or whatever, the default is kind of bad.
I would say you're correct, it's perception.
> and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
This is exactly why I never even thought to use Tcl to call python before, because you'd end up with something like this for each function you wanted to call in python:
And I guess the question is, do you want to be doing that 20 times for your Tcl app, or do you want to just write a python app? In my mind, a "pure" python app in this case is probably smarter, because you could do something like this:
import tkinter as tk
from tkinter import filedialog
from other_library import super_important_function
def open_file():
filename = filedialog.askopenfilename()
# now bear with me, I always have to remember if filedialog and the like
# return strings or pathlikes, but you get the picture...
if filename:
super_important_function(filename)
root = tk.Tk()
root.title("Pick a File")
button = tk.Button(root, text="Do super important thing on file!", command=open_file)
button.pack()
root.mainloop()
I guess it's personal preference at a certain point, yah. I would say "just use ttk and pick a good theme" is probably the right call. They mentioned some stuff about concurrency in the article and tcl being guaranteed to be responsive, etc. Despite abusing the hell out of tkinter in python, I had no problem rendering multiple windows I had up while I had pandas grind away tens of thousands of datapoints, so YMMV, but tkinter in that application worked fine. But from a "code maintenance" and "bus factor" sort of thing, I would say this is probably easier to figure out wtf is going on with a tkinter app over calling a bunch of python scripts from your Tcl app? But again, it's preference.
One of the things I really don't like about big complex tkinter apps (and this may very well be a skill issue on my part) is that in my experience if you're not really careful they tend to end up being monolithic apps with functions and windows bolted on as needed, and the parent/child relationship between windows gets confusing. Again, this is likely just me being dumb at precisely the wrong time, but I kind of think think the python of it is a little bit kind of confusing. I've thought about trying to get good enough at Racket or something similar to build a DSL for generating tkinter python interfaces? But honestly, I haven't really had both the need for something like that or the time. That said, it would be awesome do have something where I could do:
And have that emit clean python? But... in the world of LLMs etc. I don't know that the juice is worth the squeeze?
Still, wrt the article, I could totally see a situation where it would be better to wire a bunch of other scripts together with Tcl. Imagine your shop has utilities and tools in Go, Python, Bash, whatever. and you needed to wire them all together? That would be an excellent case for doing something like what they described. And like I said, I might try this on the next project where I need a quick GUI.
Worked on a NASA ground control system written in Tk. It was a great way to learn about classic design pattern because we had to roll our own event reactors, observers, plugins.
Honestly it feels very outdated compared to the reactive type of GUI's we have today.
Maybe there are some nice wrappers now that help...
I'd give a Rust based version a try. Just compile into a binary for your platform and off you go.
I built a Tcl/TK GUI in 1997 and I thought that it (specifically Tcl) was dated then. If you're used to anything beyond shell scripting, Tcl feels very un-programming. It does look they added objects in 2012, I can't speak to that.
Notwithstanding anything about LLM tools being able to do GUIs any way you want in 2026, I'd really consider just about anything else at this point. JavaFX, React Native, Electron, Flutter, etc.
the problem with Tcl/Tk is Tcl. the author does write about the quirks and problems, so this is a good article, but the end of it is that Tcl is simply not a language that i am interested in mastering. just like shell scripting. i'll use it if i have to, but it is not my preference.
and as the article also mentions what makes the apps cross platform is the native or near-native GUI. and apparently Tk is good for that.
but i'd rather use a nicer language with it. again, the article does talk about python, and points out that the Tk bindings in python are simply not good enough. that was very insightful, and i am glad to know.
however i would like to know if any other languages do better here. what about go for example? has anyone tried Tk with other languages and can share some experience?
I appreciate this reminder that boring old tech is pretty fucking good tech; especially to your non-ReactJS-not-anti-ReactJS dev, here.
The comments are also a helpful reminder of the various sw and visual design/GUI values folks hold.
I personally never gotten past exploring Tkinter but like everything else I played with until I found reason to depend on it, that'll probably change since it's as available as vim and python and _that's_ the kind of thing I value. Limitations/constrains are the engineer's problem, not the tool's (unless they are the tool's problem (but even then, just be your natural creative self and roll with it))
I really dislike using Powershell as a shell, but it looks like on Windows specifically it also has some gui thing that is somewhat similar to a .NET like zenity.
I used it to wrap up some socat and curl. Ugly stuff. Reading values from a serial device, show on screen until a button press when a value was sent over HTTP. The kind of code you hate but the management thinks is production ready.
I found it because someone on Gentoo IRC was like: ?"if you hate yourself try this"?. Would have preferred to do the whole thing in Perl.
> Alas, the complexity of its meta-object compiler (MOC)
Do these people use the same template when writing about GUIs? I mean what's complicated about MOC? In CMake it's even transparent and the user doesn't even see it. I swear, the same argument coming back year after year. "MOC" is complicated, but the compiler itself and ld isn't?
A fun one: PostgreSQL uses an adopted version of Tcl's regular expression engine, written by Henry Spencer. Tom Lane seems to think it was an impressive piece of work, and patched it up from time to time.
https://en.wikipedia.org/wiki/Henry_Spencer https://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist...
I use Tk routinely in Scheme; there is no Tcl in my code, but Tk is a very nice (though basic) GUI kit, and my programs work on Linux, BSD, MacOS, and Windows. Other commenters have mentioned that Python ships with Tkinter, a library module that interfaces to Tk. I believe Ruby does the same. Hell, if you're programming in Cobol, you can have Tk (as long as your Cobol allows you to call C). You do not have to love Tcl to love Tcl/Tk.
> interfaces to Tk
It interfaces to its own internal Tcl interpreter that runs Tk. You can even feed it arbitrary non-Tk commands to eval.
This is a legacy of the trouble Perl/Tk had splitting it out as an independent library which the Tcl devs didn't want to support.
>you can have Tk (as long as your Cobol allows you to call C).
No C required, you can just connect to the UI through a socket and often skip the FFI completely. This is my preferred way to use Tk and I don't even consider anything else unless there is a reason. Working this way also has the nice side effect of making the application UI agnostic.
But then you have an entire front end written in Tcl or some other non-COBOL language (to continue the above example,) right?
Or is there a way to run Tk as a daemon?
Believe you have to do that anyways unless you are going to create full language bindings as tkinter and the like do. I don't know the Tk API in full but I don't believe it provides ways to create widgets, just interact with them more directly. Perhaps someone more knowledgeable will fill in the gaps here, I learned what I needed of the Tk API and called it good.
that sounds interesting. can you give an example please?
PureData is a good example.
When I first found out about Tcl/Tk, it was used to give a GUI to programs written in C. I've used Tk with Tcl and many times with Perl too.
in what way is Tk basic? can you elaborate? also what are your thoughts on the issues with python as mentioned in the article? how do the scheme bindings compare?
This is a fun idea! Are you using Guile-tk?
> Those GUI apps look native on Windows, Linux and macOS
I don’t see how the author can write this with a straight face.
The apps look like what native apps looked like in 2003.
> The apps look like what native apps looked like in 2003
you make that sound more like a bug than the feature it truly is
Coincidentally the last time native apps were good.
Pretty sure tcl apps look ugly as sin... Python's tkinter is all tcl underneath.
Does it look nicer on Windows than on Linux?
I was an early adopter of the TiVo. You can hook up a terminal to those things. A dumb terminal or terminal software on your computer using your own serial port. There was a terminal/serial port in the back (baud 2600)that took the form of a 3/4" audio plug.
It was a Linux system, but all their own software running on it was written in TCL.
I don't think they were using TK though.
Pretty fun to hack around with. Since it was connected to the phone line, when a call came in it could get the caller ID off the line and display it on the TV screen.
Tkinter or other Tk based GUI interfaces are the immediate tool I reach for whenever I build something that's not in the CLI or in the browser.
My general "daily driver" is python and I love that I can just spin up a cross-platform tool immediately with it. Tcl/Tk rule and are insanely useful.
how is your experience with the problems with Tk and python as described in the article?
Well, they talk about the "barebones" Tcl version - tbh, I didn't even really know that was an issue in Python, and he is right that you have to remember to install it, and basically whenever I get a new computer I screw it up the first time until I remember the right incantations to spew at pip install or apt install to get it to work? So, "sure," there are some issues there. And to be fair, trying to do modern kind of interfaces with Tkinter in python and ttk can be kind of tricky/impossible? The part about it being "awkward" is definitely true.
But it's "good enough" like 99% of the time? And going from 0 to "something with a button a user can click" is crazy easy. At my old job, before I started working for myself, I built some painfully sprawling python script to:
1) Spin up a selenium browser to access something in servicenow that they wouldn't let us query the API for but required we access 2) Control the downloading of a bunch of files from a tk interface from python 3) toggle various settings and parse through a bunch of downloaded spreadsheets from there and another website that had some data on 4) python and matplotlib then drew pretty pictures for management 5) python then spit out documents and charts in various formats 6) then a button click triggered it all to process in parallel and opened an email to the appropriate managers that I fire off
This turned something like 10-40 hours of manual work (depending on how well you knew how to do it) where you were clicking and reading into like a 15 min job that I could do on the first of the month while I drank my coffee.
I'm sure it would probably be "better" to write the whole program in Tcl/tk, but sometimes I am lazy. Also, if I'm doing something with pandas or AI and the tk gui is just something slapped over the underlying logic and code. I guess it's a matter of preference? But tkinter is "pretty good" and often "pretty good" is way better than perfect.
They say in the article something like, "if you don't need to call python libraries just use tcl/tk" or whatever. And that's fair, but honestly, being able to throw pandas at something or matplotlib or whatever is super valuable. I think in the future maybe it'll be easy to do something like, "claude please port matplotlib into tcl" and then you can do it natively, that would make sense? Or maybe even like they say it might be cool to make a python script then call it from tcl like they say? but multiple scripts in different languages seems like a bit of a maintenance headache? Though that also might be just a skill issue on my part lol. It might be lazy of me but staying in one language has some advantages, namely, I don't need all the boilerplate argparse code for each thing in python I might want to write.
When I wrote the monstrosity above, I didn't really know anything about tcl/tk other than "isn't that that archaic ui thing?" I actually played around with raw tcl during the process of writing that beast, but that was mostly just for fun.
I guess my real response is, if I end up in a knife fight with a GUI layer over python again, the way they describe in there might be what I do? Calling the python from the tcl might be the optimal choice? It'd be fine to stretch the brain in a slightly different direction anyway.
trying to do modern kind of interfaces with Tkinter in python and ttk can be kind of tricky/impossible? The part about it being "awkward" is definitely true.
that sounds a bit worrying. can you give some examples?
from the article i was specifically wondering about this:
And yet still, even with ttk, Python doesn't automatically pick the best theme for the OS! It often defaults to "clam", "alt", or the dreaded "classic" on Linux, which look dated. It's a mess of a Tk bridge! ... the provided bridge to it is clunky
so is it just the perception? sounds like i should just have to remember to pick a better theme. (and use ttk)
and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
Its because tk does not have a central event loop built in. You can't use modern programming techniques without building up a significant scaffolding to get multiple UI elements updated based on an events generated in various places. It requires an observer pattern + a self defined callback event generation scheme to collect events (singleton pattern).
Sure you can make this module and there are probably things out there, but you need to wire it up yourself before you even get to the application logic.
It's not bad per se, but even something like a dark mode is a giant pain in the ass.
Last time I had to make a quick tkinter interface was like a month ago for a project I was working on just for me and I wanted a cleaner interface and I just had codex do it and it was "fine" - like nothing to write home about but "fine." If you're trying to get the most out of your macbook or whatever, the default is kind of bad.
I would say you're correct, it's perception.
> and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
This is exactly why I never even thought to use Tcl to call python before, because you'd end up with something like this for each function you wanted to call in python:
And I guess the question is, do you want to be doing that 20 times for your Tcl app, or do you want to just write a python app? In my mind, a "pure" python app in this case is probably smarter, because you could do something like this: I guess it's personal preference at a certain point, yah. I would say "just use ttk and pick a good theme" is probably the right call. They mentioned some stuff about concurrency in the article and tcl being guaranteed to be responsive, etc. Despite abusing the hell out of tkinter in python, I had no problem rendering multiple windows I had up while I had pandas grind away tens of thousands of datapoints, so YMMV, but tkinter in that application worked fine. But from a "code maintenance" and "bus factor" sort of thing, I would say this is probably easier to figure out wtf is going on with a tkinter app over calling a bunch of python scripts from your Tcl app? But again, it's preference.One of the things I really don't like about big complex tkinter apps (and this may very well be a skill issue on my part) is that in my experience if you're not really careful they tend to end up being monolithic apps with functions and windows bolted on as needed, and the parent/child relationship between windows gets confusing. Again, this is likely just me being dumb at precisely the wrong time, but I kind of think think the python of it is a little bit kind of confusing. I've thought about trying to get good enough at Racket or something similar to build a DSL for generating tkinter python interfaces? But honestly, I haven't really had both the need for something like that or the time. That said, it would be awesome do have something where I could do:
And have that emit clean python? But... in the world of LLMs etc. I don't know that the juice is worth the squeeze?Still, wrt the article, I could totally see a situation where it would be better to wire a bunch of other scripts together with Tcl. Imagine your shop has utilities and tools in Go, Python, Bash, whatever. and you needed to wire them all together? That would be an excellent case for doing something like what they described. And like I said, I might try this on the next project where I need a quick GUI.
Still find Tcl/Tk surprisingly effective for simple cross-platform GUI utilities. The `wish` shell was my go-to for quick internal tools.
Fun fact: macOS hex editor "Hex Fiend" uses Tcl for its templating language:
https://github.com/HexFiend/HexFiend/tree/master/templates
Some of these UIs look simpler and better / more user friendly to me than the latest offerings from Apple and Microsoft. Especially this: https://cgicoffee.com/blog/content/images/2026/tcl-tk-articl... Looks like OpenBox?
I take issue with the only 100 MB footprint, that is still pretty big when consider fasm, tcc and rebol are all closer to 1 meg.
Yeah, 100mb is not a bragging point. That's the size of a full web browser engine
Worked on a NASA ground control system written in Tk. It was a great way to learn about classic design pattern because we had to roll our own event reactors, observers, plugins.
Honestly it feels very outdated compared to the reactive type of GUI's we have today.
Maybe there are some nice wrappers now that help...
I'd give a Rust based version a try. Just compile into a binary for your platform and off you go.
It made me remember, me learning programing and building random GUIS app in tkinter and python.
I built a Tcl/TK GUI in 1997 and I thought that it (specifically Tcl) was dated then. If you're used to anything beyond shell scripting, Tcl feels very un-programming. It does look they added objects in 2012, I can't speak to that.
Notwithstanding anything about LLM tools being able to do GUIs any way you want in 2026, I'd really consider just about anything else at this point. JavaFX, React Native, Electron, Flutter, etc.
the problem with Tcl/Tk is Tcl. the author does write about the quirks and problems, so this is a good article, but the end of it is that Tcl is simply not a language that i am interested in mastering. just like shell scripting. i'll use it if i have to, but it is not my preference.
and as the article also mentions what makes the apps cross platform is the native or near-native GUI. and apparently Tk is good for that.
but i'd rather use a nicer language with it. again, the article does talk about python, and points out that the Tk bindings in python are simply not good enough. that was very insightful, and i am glad to know.
however i would like to know if any other languages do better here. what about go for example? has anyone tried Tk with other languages and can share some experience?
I wonder whether Delphi/Lazarus would be better suited for a native GUI on each platform. But you’d have to compile your app for each separately.
I appreciate this reminder that boring old tech is pretty fucking good tech; especially to your non-ReactJS-not-anti-ReactJS dev, here.
The comments are also a helpful reminder of the various sw and visual design/GUI values folks hold.
I personally never gotten past exploring Tkinter but like everything else I played with until I found reason to depend on it, that'll probably change since it's as available as vim and python and _that's_ the kind of thing I value. Limitations/constrains are the engineer's problem, not the tool's (unless they are the tool's problem (but even then, just be your natural creative self and roll with it))
On Linux there is also this windowing shell `wish` which I've used for some very quick (and very very dirty) UIs
I haven’t used myself but in Linux there is also zenity
https://linux.die.net/man/1/zenity
I have seen scripts that use it for a quick GUI.
I really dislike using Powershell as a shell, but it looks like on Windows specifically it also has some gui thing that is somewhat similar to a .NET like zenity.
This seems modal driven. Like calling MsgBox on windows. Wish (iirc) let me get multiple labels, input and buttons in an Hbox/Vbox type layout.
Do you have more information? It looks interesting
I don't, but it was easy even before AI code.
It's this one https://en.wikipedia.org/wiki/Wish_(Unix_shell) - which turns out is Tcl.
I used it to wrap up some socat and curl. Ugly stuff. Reading values from a serial device, show on screen until a button press when a value was sent over HTTP. The kind of code you hate but the management thinks is production ready.
I found it because someone on Gentoo IRC was like: ?"if you hate yourself try this"?. Would have preferred to do the whole thing in Perl.
> Alas, the complexity of its meta-object compiler (MOC)
Do these people use the same template when writing about GUIs? I mean what's complicated about MOC? In CMake it's even transparent and the user doesn't even see it. I swear, the same argument coming back year after year. "MOC" is complicated, but the compiler itself and ld isn't?