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.
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?
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?
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.
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.
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?
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.
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.
https://github.com/HexFiend/HexFiend/tree/master/templates