The industry standard VFX compositing tool Nuke also uses Tcl for its expressions and save format, it's all Tcl terms as I recall. My brother did VFX for a while and I was amused when he was having some trouble with an expression and I was like "it's a Tcl system... I know this" and helped him.
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 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.
STk is a Scheme interpreter which can access to the Tk graphical package.
Concretely it can be seen as the John Ousterhout's Tk package where
the Tcl language has been replaced by Scheme.
The Scheme interpreter is now R4RS conformant.
This release provides an efficient object oriented system called STklos.
STklos is a full OO system with multi-inheritance, generic functions,
multi-methods and a true meta object protocol.
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.
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 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 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.
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 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.
> 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.
Besides Tk and the ease of creating GUIs, Tcl has some unique advantages. As I have written before, a favorite of mine, which I have not found in other languages (besides LISP, obviously) is the ability to treat data as code combined with the existence of safe slave interpreters.
This is extremely useful for configuration files: they can use some functions you have defined, but may also include arbitrary code. In order to load them, you simply fire up a safe slave interpreter to execute the code and you're done!
Imagine a config file like:
host machine.example.org
port 9000
dbhost server.example.org
This can obviously be manually parsed easily, but this is also valid Tcl code, if one has defined the functions "host", "port", and "dbhost".
And this allows people to extend the config file to something like:
set mydomain example.org
set type prod
host machine.$mydomain
dbhost server.$mydomain
if {$type == prod} {
port 9000
} else {
port 9999
}
Having a "full-blown programming language" for free in config files is sometimes desirable.
I'm writing much more Python than Tcl these days, but this is a feature I sorely miss. I keep looking for similar functionality in Python, but I am always disappointed. Starlark has been proposed in the past, but unfortunately it means you have to work with something different than Python (in developing, in deploying, etc.), doubling your dependencies.
Tcl/Tk was the first "grown up" language I used after using variants of BASIC up until the mid to late nineties. I bought a used Sun Ultra 1 and Tcl/Tk was like a vision of the future compared to BASIC.
I still sort of want to use it again, but can't quite find a reason to do so.
If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book.
As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way:
make something that is simple enough for almost everyone to understand
give away your source code
explain how to weave your source code in with other systems
55 comments
[ 0.21 ms ] story [ 3.6 ms ] threadhttps://github.com/HexFiend/HexFiend/tree/master/templates
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.
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?
If you are talking about the size of the TCL/Tk static binaries they are a few MB to judge by the zipkit downloads he refers to.
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.
Or is there a way to run Tk as a daemon?
It interfaces to its own internal Tcl interpreter that runs Tk. You can even feed it arbitrary non-Tk commands to eval.
Perl too, IIRC.
https://wiki.tcl-lang.org/page/Scheme
This is quite old, but I always remember seeing it in the BSD packages collection:
https://conservatory.scheme.org/stk/
Then there is Portable Scheme / Tk, a library for several Scheme implementations:
https://wiki.call-cc.org/eggref/5/pstk
PS/Tk provides an interface to the Tk toolkit, and is an effective tool for creating graphical interfaces.
And a recent walk-through:Learn Scheme by Example: Tk GUI with Chicken Scheme
https://blog.matthewdmiller.net/learn-scheme-by-example-tk-g...
STk is a Scheme interpreter which can access to the Tk graphical package. Concretely it can be seen as the John Ousterhout's Tk package where the Tcl language has been replaced by Scheme.
The Scheme interpreter is now R4RS conformant.
This release provides an efficient object oriented system called STklos. STklos is a full OO system with multi-inheritance, generic functions, multi-methods and a true meta object protocol.
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.
you make that sound more like a bug than the feature it truly is
The look is mostly acceptable though.
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.
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.
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))
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.
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 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.
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?
https://en.wikipedia.org/wiki/Henry_Spencer https://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist...
This is extremely useful for configuration files: they can use some functions you have defined, but may also include arbitrary code. In order to load them, you simply fire up a safe slave interpreter to execute the code and you're done!
Imagine a config file like:
This can obviously be manually parsed easily, but this is also valid Tcl code, if one has defined the functions "host", "port", and "dbhost". And this allows people to extend the config file to something like: Having a "full-blown programming language" for free in config files is sometimes desirable.I'm writing much more Python than Tcl these days, but this is a feature I sorely miss. I keep looking for similar functionality in Python, but I am always disappointed. Starlark has been proposed in the past, but unfortunately it means you have to work with something different than Python (in developing, in deploying, etc.), doubling your dependencies.
I still sort of want to use it again, but can't quite find a reason to do so.
Chapter 10: Sites That Are Really Programs
https://philip.greenspun.com/panda/server-programming
by Hal Abelson, Philip Greenspun, and Lydia Sandon
https://philip.greenspun.com/tcl/
If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book.
As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way:
...