Rendered at 19:37:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
srean 23 hours ago [-]
I have a soft corner for TCL, because of its idiosyncracies and weird dynamic stringy playfulness. I would be wary of using it professionally but to play around for the fun of it ... it's just too much fun. Upvar and uplevels are 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. 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).
AceJohnny2 14 hours ago [-]
> I would be wary of using it professionally
This is funny because so much Silicon CAD automation is written in TCL. I mean the most advanced technology in the world depends on TCL in its pipeline (also Excel VBasic!) (let's not talk about COBOL, that's in banking)
TCL is the original extension language, and in the very hidebound electronics CAD world, has a very long tail.
bandrami 11 hours ago [-]
There's an alternate timeline where Ousterhout's dream was realized and TCL filled the role that the Javascript swamp filled. I think that's a better timeline from a tech perspective.
pjmlp 12 hours ago [-]
Not to sidetrack that much, COBOL is now in ISO 2023, even has OOP features, there are ways to do microservices in it, and nice modern IDEs as well.
Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.
tannhaeuser 25 minutes ago [-]
I don't dare to think about the horrible output of an LLM generating COBOL with hallucinated English dropped in.
srean 13 hours ago [-]
I know.
I would hazard a guess that a significant fraction of HNers would have encountered TCL in silicon CAD and took with them a frustrating experience.
kevin_thibedeau 21 hours ago [-]
> Entirety of interpreter state is encapsulated inside the interpreter object
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.
srean 17 hours ago [-]
Are you sure ? Tcl is almost a decade older than javascript although subinterpreters came later. Even before subinterpreters you could have multiple Tcl interpreter instances in your code.
One could call Tcl_CreateInterp() multiple times in your code and each call would return an independent interpreter.
bch 16 hours ago [-]
Safe interps were designed c. 1993 by Nathaniel Borenstein and Marshall Rose to be able to safely run code received through email[0][1].
Back in the ActiveX days, ActiveState had IE scripting engines for Tcl, Perl and Python, allowing their use on IE instead of VBScript and JScript.
dkfellows 9 hours ago [-]
There are a very few truly global entities there, most notably the current working directory and the environment variables. They're global because the underlying concept leaks through into C code you link in and subprocesses you launch, and changing that would be really quite nasty. The Tcl interfaces to those things are internally protected against multithreaded access, of course, but you can still get yourself into a mess that way.
The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...
grimgrin 21 hours ago [-]
if anyone was curious! "soft spot" has an Indian English "soft corner", so says website dot com
srean 14 hours ago [-]
Very interesting. I was not aware at all that this was an Indianism. One that I like quite a bit is the word prepone.
maybewhenthesun 11 hours ago [-]
My uncle, who worked for oil companies all his life, always had the opinion that the Indians use english better than the English. :-)
'prepone' is an example of why I sometimes agree. Most indian guys I know also up the baudrate of english so much that they get twice the information flow compared to british english. With the disadvantage that both sides of the conversation need to speak indian english or you'll get protocol errors :-D
avadodin 10 hours ago [-]
I wrote an internal tool UI in TCL/TK.
Unfortunately, it isn't getting much use anymore because of changes in architecture, but it was easy enough and the control I used for logs was much better than the c# forms stuff it replaced that would pin the CPU 100% and OOM after a few thousand lines.
If I read it today, it makes as much sense as Mayan pictographs, though.
zitterbewegung 22 hours ago [-]
Sort of interesting how Python has got rid of the GIL. Serialization of data securities is still something relevant though and I’m not sure if you should use pickle still?
tlavoie 21 hours ago [-]
Pickle is likely still handy, as long as you created the data that you're deserializing. Zope's object database was a big pickle file, as I recall. But yeah, not a good idea if you're cracking open user-supplied files in any way.
vkazanov 12 hours ago [-]
Ha! People still remember Zope!
That was my first web kind of framework. The naivette of Zope still amuses me endlessly to this very day.
It tried to be cool, made ALL the wrong choices, and died silently with people just moving on.
tlavoie 1 hours ago [-]
I think it still exists, even! It has been a long time since I used it though, but it was interesting.
vkazanov 1 hours ago [-]
Interesting is one way of saying this...
I will never recover from debugging ZODB backed by Oracle. Well, somewhat backed.
Who, like, who thought it was cool to have a pickle-based, mostly in-memory, single process, aaalmost transactional database?!
pjmlp 5 hours ago [-]
There are dozens of us. :)
zahlman 13 hours ago [-]
Pickle is insecure by design, but definitely convenient if you can trust the input.
If you need something safe then you really need to identify your requirements and your threat model first anyway; I wouldn't blindly reach for a one-size-fits-all solution in any programming language.
(Although I would do a quick check to see JSON or TOML is sufficient and practical.)
segmondy 19 hours ago [-]
"wary of using it professionally". what does this even mean? you can use anything professionally if done so in a professional manner. it's just a tool, use it correctly and within limits.
srean 17 hours ago [-]
You can find yourself having to work with quite unprofessionally written code. Not an uncommon experience.
ripe 22 hours ago [-]
Tcl is certainly a bit weird and takes getting used to, but I have found it worth learning its idiosyncrasies, particularly because my applications use sqlite, which fits very naturally with Tcl.
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."
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 the alternatives 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.)
bloaf 19 hours ago [-]
So I also love Tcl, but I think it would have not been great as a web language. I think the small amount of type information we can pass via json is just about right, and tcl would have made it impossible.
You cannot encode arbitrary tcl data to a typed object "correctly" because every tcl dictionary is a valid list, and every list is a valid string (numbers are also strings, and so is code). So in a world of "tcl code on the web", both the sending and parsing ends of a 'tcl data stream' would need to know which type they're "supposed" to treat the data as.
monista 21 hours ago [-]
> The biggest early selling point of Tcl was Tk
You're not that old, are you? :) Before www, expect was the way to go.
Expect was amazing - game changing. The things you could do with it couldn't be replicated elsewhere (well, clearly "could", but not reasonably so)
flopsamjetsam 22 hours ago [-]
My pet project in those days was writing a C++ X-Windows gui toolkit, and I took a lot of inspiration from Tk. Both design, and "how do I do this" from the source code were invaluable.
Yes the legacy Cisco IOS had a Tcl interpreter built in, you can drop in to the repl with the tclsh command. The command is still there on newer Linux based IOS versions
zahlman 13 hours ago [-]
Yep, the age of Python and the C-steeped culture of its original developers probably has a lot to do with the choice of Tcl/Tk as a basis for the standard library GUI framework. But even then, there's significant wrapping; and Python's type system is, if anything, even further away from the free-wheeling "stringly typed" Tcl than JavaScript is.
I do sometimes yearn for the alternate universe where web browsers ended up doing Python natively (and PyPy style optimizations became the default, and the dynamism was reined in to an extent where it could offer JavaScript-tier performance).
Aside from the emphasis on "continuation passing style" though I don't get how you're relating JavaScript to Scheme.
so-cal-schemer 11 hours ago [-]
Here is a discussion from last month:
Develop Cross-Platform CLI and GUI Tools with Tcl/Tk (cgicoffee.com)
112 points by aryonoco 29 days ago | hide | past | favorite | 62 comments
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....
giancarlostoro 23 hours ago [-]
I think some of the "LAMP" type bundles use Tcl/Tk for their UI, kinda neat.
agumonkey 16 hours ago [-]
Iirc it was successfully used so in the CGi world (nuke and maybe maya mel)
trebligdivad 1 days 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.
dkfellows 9 hours ago [-]
The current main project for Tk, targeting the 9.2 release next year, is porting to work on Wayland. (But not dropping support for X11, Windows or macOS.) Apparently, the widget demo is now working (i.e., you could probably build some applications on it) but advanced features like accessibility support are still in progress.
trebligdivad 7 hours ago [-]
Hey Donal, long time! Great to see you still involved.
BoingBoomTschak 2 hours ago [-]
Didn't expect Wayland support that soon!
agumonkey 23 hours ago [-]
It hits a sweet spot for a lot of basic UI needs.
iamcreasy 24 hours ago [-]
Is it still true if I want to custom widget with animations?
convolvatron 23 hours ago [-]
I've done animations at the Tcl layer before with composition of Tk objects. for little visualizations its just fine, certainly not AAA
Dwedit 21 hours ago [-]
What about oldschool Visual Basic?
WillAdams 17 hours ago [-]
It was nice/workable for its time, and one wishes that there was some modern alternative, but "RAD" seems to have dropped off the radar.
Some things I've tried/looked into (beyond TCL/TK):
- Gambas --- Linux only, not sure if there's a nice visual UI builder
- LiveCode --- still salty about the license rug pull, wish the openxtalk folks could get some traction
- MoonBasic --- looks promising, but currently trying....
- flet.dev --- the AI-integration in this makes it quite compelling, though I wish that there was an integrated UI drawing tool, https://github.com/raffieeey/Flet-Visual-Builder is self-described as buggy and hasn't seen an update in 7 months
- Lazarus --- still bummed I never got anywhere with Delphi --- if flet.dev doesn't work out, may try it
pjmlp 12 hours ago [-]
Besides the sibling comment, VB.NET is still around, even if not with the attention it once had.
VB + C# with Windows Forms is not much different from old school VB.
And for the pixel positioning complaints, it is about time people learn about FlowLayoutPanel and TableLayoutPanel, they exist since .NET 2.0 (2005).
bitwize 7 hours ago [-]
That's new-school VB. Tcl was doing automatic widget layout back when VB was using absolute "dialog units" for everything.
pjmlp 5 hours ago [-]
To be more pedantic that was taken from Motif layout managers, and old school VB did have layout managers available, however a large majority only dragged and dropped from the toolbox.
bitwize 6 hours ago [-]
Too much rat wrestling. You could bang out a few lines of Tcl in your editor and have a working GUI. Even stub out the commands that widgets run, tweak and reload until it behaves right, then add those back for a working program. Absolutely nice for providing a visual interface for your Unix scripts or programs, or for building whole applications in if you're daring.
qalmakka 23 hours 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 23 hours ago [-]
Not to mention uplevels and upvar.
wduquette 23 hours ago [-]
All of which I used many years to go to write "Snit", a quite nice object system for coding up Tcl objects and Tk widgets. Snit's a TCL library that takes a nice, easily readable description of your desired object type (the instance variables, the methods, and so forth), translates it immediately into standard TCL, and then evaluates that to define your type. Basically, it's a macro system for defining object types. (I say "object types" rather than "classes" because there is no inheritance.)
sea6ear 19 hours ago [-]
I loved your 'expand' utility - and wrote a truly heinous Tcl to PHP framework/translation layer using it, because I preferred Tcl to PHP at the time - still do, but the early hatred for PHP has muted - that powered an application at the college I attended for an embarrassingly long time.
Not really. Snit’s included in Tcllib; find the Tcllib docs and look at the Snit man page and Snit FAQ.
RHSeeger 15 hours ago [-]
I've always thought of Tcl as a type of Lisp. Clearly, the relationship isn't direct, but it allows a lot of the same things that Lisps do. Plus, the way one nests commands is similar.
And it shares a lot of the same metaprogramming that Lisps have - more so than the vast majority of other languages.
BoingBoomTschak 2 hours ago [-]
As someone who did enough of both (in fact, Tcl was my gateway to Lisp), I'd say yes and no.
Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.
So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.
qalmakka 8 hours ago [-]
yeah it does feel like a Lisp that people happen to write in an imperative fashion most of the time
bitwize 7 hours ago [-]
I think of it as an alternate take on Lisp's metaprogramming. A form of cosmic-horror take that will drive you insane, yes, but Lisp-like metaprogramming nevertheless. Stare too long into Tcl's deadlights and you will want to be there.
neofytos 1 days 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.
Aldipower 1 days 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 1 days ago [-]
Perl/Tk is a lot of fun. I wrote a solitaire game called tktk — Tk Time Killer — that appeared in The Perl Journal.
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 24 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 23 hours 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.
wduquette 23 hours ago [-]
One can create amazing ergonomic scripting APIs in TCL; I've done that. One can also rapidly create horrors without end. I've seen that, too. With great power comes great responsiblity.
CamperBob2 24 hours 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.
kevin_thibedeau 24 hours 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.
As a teen I attended a weeklong ArsDigita workshop in the vault of their Pasadena office. It was in an old bank building on Green St. Aeron chairs, Sun Ray thin clients (iirc), a huge circular bank vault door...
I remember being introduced to regex one day, and later the instructor (a Caltech PhD?) being surprised my code passed all his tests in a class review.
Really, a wonderful experience.
so-cal-schemer 12 hours ago [-]
I thank my cousin, who lived by the 7Cs, for hosting me and driving so far to pick me up the first night (after I hung out waay too long with new acquaintances in the AD office).
And I remember, after a day of learning Tcl, while waiting for an express bus back to Claremont, listening to a woman belt out opera on an empty Colorado Blvd in front of Vroman's, like a private opera rehearsal.
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.
baggachipz 1 days 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.
pjmlp 15 hours ago [-]
When Rails came out, I was like what is the buzz all about, we have been doing this already for several years.
RHSeeger 15 hours ago [-]
Same here. I enjoyed that time/experience a lot.
wombatpm 24 hours ago [-]
I remember using tcl inside pages running under Vignette Story Server circa 2000 before we started with jsp
shaky-carrousel 1 days ago [-]
And OpenACS!
fithisux 1 days ago [-]
Or Kenny Tilton's celtk or cello?
gbacon 1 days ago [-]
The little language that could.
“Tcl tends to get ported to weird places like routers.” (Larry Wall, October 1997)
bch 23 hours 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."
It's not really ported. tkinter just builds a full Tcl interpreter as a Python extension and passes command strings over to it. This is the use case Tcl was designed for. You can get access to the underlying Tcl instance and issue non-Tk commands.
bch 20 hours ago [-]
Technically correct (the best kind of "correct").
My next question to myself was what hardware was running Tcl in c.1997 Cisco equipment? What porting effort was required? I understand there was some proprietary feature work for Cisco IOS, but I don't know what architectural work was required.
dkfellows 9 hours ago [-]
Long term, the Cisco router support became the non-recursive execution engine (of Tcl 8.6) which stopped things from blowing up on the tiny stack sizes that Cisco equipment is configured with.
And which gives us tailcalls and coroutines.
olexsmir 1 days ago [-]
They don't make them like they used to
sgt 1 days 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.
tzury 18 hours ago [-]
Indeed!
For the simple prompt to Claude Fable:
let's write a small tcl/tk app for fun.
a small tiny UI to manage a to do list.
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 1 days 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.
kevin_thibedeau 21 hours ago [-]
> It's not like ALGOL or anything.
It's a Lisp with syntax sugar and no macros.
dkfellows 9 hours ago [-]
There's no macros because there's uplevel (and upvar) instead. It's a different way to do homoiconicity. And the variable binding rules are quite different, which makes for quite a different language in practice.
anthk 21 hours ago [-]
Lisp a la Unix way.
rtpg 15 hours ago [-]
Anyone have fun stories of things they built with tcl/tk? I feel like there's still room for tiny apps with it in theory, but I tend to have the problem of wanting to stuff "arbitrary rich text" into my things (-> web tech suddenly works quite well)
erremerre 11 hours ago [-]
I like using pygubu to have gui with python. but tends to create 300mb apps when compiling. So not much better than Electron...
fmajid 21 hours ago [-]
I did some Tcl work a quarter century agi, but really if I were in the market for an extension glue language today, I'd reach for Lua first.
RHSeeger 15 hours ago [-]
I like the concept of Lua, but I ran into enough issues with it's "everything is a table" design that I stopped using it.
kstrauser 18 hours ago [-]
How come? I don't have enough experience with either to have a preference, but I'd love to hear the opinion of someone more familiar.
fmajid 9 hours ago [-]
The everything is a string approach shows its limits quite quickly. Lua is also extremely performant, which is not always needed in a glue language, but still good to have.
rwbt 15 hours ago [-]
Not the OP but Tcl comes with batteries included and more "full fledged". Lua is just so much more lightweight and so easy to just drop it in any codebase.
The biggest reason to use Tcl even to this day is to write Tk GUI programs.
bch 13 hours ago [-]
> The biggest reason to use Tcl even to this day is to write Tk GUI programs.
Well... Tcl on its own is good as a configuration language, creating DSLs, or as a scripting/extension interface, as well as a single common cross platform interface to filesystems, network sockets, and more - so I'd say "the biggest reason" depends on what you're working on...
kstrauser 15 hours ago [-]
Interesting! Would that make a different choice for standalone use, then?
0x0203 23 hours ago [-]
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.
rwmj 23 hours ago [-]
9.0 was unfortunately incompatible with a lot of software. Certainly in Fedora we did the work (about a year ago) and have been shipping it for a long time.
puneetchandna21 23 hours ago [-]
what do you guys think about omarchy, i am thinking about switching my bro ( CS freshmen) from windows to omarchy instead of ubuntu, should i do it, or should i consider other distros too like this one?
Perz1val 3 hours ago [-]
Imo omarchy is only the right choice for a person engaging in it's "hype", so I wouldn't give it to somebody else. They either want it themselves or it's not a good fit.
bmacho 6 hours ago [-]
It's very off-topic here.
I personally wouldn't put anything but Ubuntu on a computer that someone else has to use and I have to support. No Arch, Fedora, Suse.
The main reason is that I know it, how to configure it, and when it tends to do silly things. Secondary reason is that Ubuntu is a beginner friendly distro.
Unless you are familiar with Arch/Omarchy and/or have ideological reasons, I don't see the point of putting it on someone else's computer. If articles and videos are hyping it, they are probably wrong or don't apply to your case.
kccqzy 21 hours ago [-]
Omarchy is a hyped up Arch Linux configuration tool with one specific kind of user in mind (namely its creator). It’s not beginner friendly if your brother hasn’t used Linux before. In fact Arch Linux itself is not beginner friendly. It’s better to stick with Ubuntu.
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 24 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.)
kps 18 hours ago [-]
Wayland.
gbacon 1 days ago [-]
Sorry to hear about the retinal tearing. I hope advancements come along that work in your favor.
billybuckwheat 22 hours ago [-]
Many years ago, I worked at a company that used Tcl as the scripting language for its primary product. At one point, a hotshot product manager started agitating to replace it with something more modern. He claimed that Tcl was dying because (wait for it) there were no books being published about it at the time. I guess he was wrong ... :-)
shevy-java 22 hours ago [-]
Well - Tcl is dying though. So he was not entirely wrong.
One can not even find it on TIOBE but one can find COBOL there:
glfw is smaller and more focused (SDL adds a TON of stuff, including even its own GPU abstraction API) so the choice was most likely made because of that focus.
1 days ago [-]
shevy-java 22 hours ago [-]
I tried to get into tk via ruby-tk.
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.
fithisux 1 days ago [-]
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 24 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.
UltraSane 22 hours ago [-]
I'm familiar with Tcl because many Cisco routers actually support it as a scripting language.
1 days ago [-]
csiegert 1 days 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.
I wonder what the author of the second article would have thought of wxWidgets in their “why” section. It wouldn’t have the drawbacks that they attributed to Qt.
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 is funny because so much Silicon CAD automation is written in TCL. I mean the most advanced technology in the world depends on TCL in its pipeline (also Excel VBasic!) (let's not talk about COBOL, that's in banking)
TCL is the original extension language, and in the very hidebound electronics CAD world, has a very long tail.
Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.
I would hazard a guess that a significant fraction of HNers would have encountered TCL in silicon CAD and took with them a frustrating experience.
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.
One could call Tcl_CreateInterp() multiple times in your code and each call would return an independent interpreter.
[0] http://www.beedub.com/book/2nd/interp.doc.html
[1] https://www.guppylake.com/nsb/pubs/ulpaa-94.pdf
The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...
'prepone' is an example of why I sometimes agree. Most indian guys I know also up the baudrate of english so much that they get twice the information flow compared to british english. With the disadvantage that both sides of the conversation need to speak indian english or you'll get protocol errors :-D
Unfortunately, it isn't getting much use anymore because of changes in architecture, but it was easy enough and the control I used for logs was much better than the c# forms stuff it replaced that would pin the CPU 100% and OOM after a few thousand lines.
If I read it today, it makes as much sense as Mayan pictographs, though.
That was my first web kind of framework. The naivette of Zope still amuses me endlessly to this very day.
It tried to be cool, made ALL the wrong choices, and died silently with people just moving on.
I will never recover from debugging ZODB backed by Oracle. Well, somewhat backed.
Who, like, who thought it was cool to have a pickle-based, mostly in-memory, single process, aaalmost transactional database?!
If you need something safe then you really need to identify your requirements and your threat model first anyway; I wouldn't blindly reach for a one-size-fits-all solution in any programming language.
(Although I would do a quick check to see JSON or TOML is sufficient and practical.)
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...
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.)
You cannot encode arbitrary tcl data to a typed object "correctly" because every tcl dictionary is a valid list, and every list is a valid string (numbers are also strings, and so is code). So in a world of "tcl code on the web", both the sending and parsing ends of a 'tcl data stream' would need to know which type they're "supposed" to treat the data as.
You're not that old, are you? :) Before www, expect was the way to go.
<https://en.wikipedia.org/wiki/Expect>
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...
I do sometimes yearn for the alternate universe where web browsers ended up doing Python natively (and PyPy style optimizations became the default, and the dynamism was reined in to an extent where it could offer JavaScript-tier performance).
Aside from the emphasis on "continuation passing style" though I don't get how you're relating JavaScript to Scheme.
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....
Good to see it's getting some modern support.
Some things I've tried/looked into (beyond TCL/TK):
- Gambas --- Linux only, not sure if there's a nice visual UI builder
- LiveCode --- still salty about the license rug pull, wish the openxtalk folks could get some traction
- MoonBasic --- looks promising, but currently trying....
- flet.dev --- the AI-integration in this makes it quite compelling, though I wish that there was an integrated UI drawing tool, https://github.com/raffieeey/Flet-Visual-Builder is self-described as buggy and hasn't seen an update in 7 months
- Lazarus --- still bummed I never got anywhere with Delphi --- if flet.dev doesn't work out, may try it
VB + C# with Windows Forms is not much different from old school VB.
And for the pixel positioning complaints, it is about time people learn about FlowLayoutPanel and TableLayoutPanel, they exist since .NET 2.0 (2005).
https://wiki.tcl-lang.org/page/Snit%27s+Not+Incr+Tcl
And it shares a lot of the same metaprogramming that Lisps have - more so than the vast majority of other languages.
Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.
I know that because I had a need to hack together an horrible replacement for the thing I miss the most from Lisp: quasiquoting (https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9...).
------
So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.
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... :-)Here's another plug for his book:
A Philosophy of Software Design/2e
https://www.amazon.com/dp/173210221X
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...
I remember being introduced to regex one day, and later the instructor (a Caltech PhD?) being surprised my code passed all his tests in a class review.
Really, a wonderful experience.
And I remember, after a day of learning Tcl, while waiting for an express bus back to Claremont, listening to a woman belt out opera on an empty Colorado Blvd in front of Vroman's, like a private opera rehearsal.
Such a classy city.
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.
“Tcl tends to get ported to weird places like routers.” (Larry Wall, October 1997)
[0] https://grokipedia.com/page/Tkinter
My next question to myself was what hardware was running Tcl in c.1997 Cisco equipment? What porting effort was required? I understand there was some proprietary feature work for Cisco IOS, but I don't know what architectural work was required.
And which gives us tailcalls and coroutines.
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.
For the simple prompt to Claude Fable:
I got this in no time: https://gist.github.com/mathusiast/a57bf0dfa42d8c7008f8882da...It's a Lisp with syntax sugar and no macros.
The biggest reason to use Tcl even to this day is to write Tk GUI programs.
Well... Tcl on its own is good as a configuration language, creating DSLs, or as a scripting/extension interface, as well as a single common cross platform interface to filesystems, network sockets, and more - so I'd say "the biggest reason" depends on what you're working on...
I personally wouldn't put anything but Ubuntu on a computer that someone else has to use and I have to support. No Arch, Fedora, Suse.
The main reason is that I know it, how to configure it, and when it tends to do silly things. Secondary reason is that Ubuntu is a beginner friendly distro.
Unless you are familiar with Arch/Omarchy and/or have ideological reasons, I don't see the point of putting it on someone else's computer. If articles and videos are hyping it, they are probably wrong or don't apply to your case.
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).