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.

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.

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.

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.

Very interesting. I was not aware at all that this was an Indianism. One that I like quite a bit is the word prepone.

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.

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.)

You can find yourself having to work with quite unprofessionally written code. Not an uncommon experience.

Expect was amazing - game changing. The things you could do with it couldn't be replicated elsewhere (well, clearly "could", but not reasonably so)

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

Hey Donal, long time! Great to see you still involved.

Didn't expect Wayland support that soon!

I've done animations at the Tcl layer before with composition of Tk objects. for little visualizations its just fine, certainly not AAA

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

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.

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).

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.)

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.

Wayland.

In a way its distant nominative descendent, TikTok, is also a solitaire game.

This is very cool! The name alone. :-)

That's a bummer. Now I have to start over. </s>

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:

  eery@cherimoya [1] > cd /sprite/src/lib/mx
  eery@cherimoya [4] > grep Tcl *.c
  mxCmdAM.c:    Tcl_Interp *interp;
  mxCmdAM.c: Tcl_Return(interp, Cmd_BindingGet(mxwPtr->cmdTable, argv[1]),
  mxCmdAM.c: interp->result = Tcl_Merge(bindingCount, bindings);
  mxCmdAM.c:    Tcl_Interp *interp;
  [...]
  eery@cherimoya [10] > grep LIBS ../../cmds/mx/local.mk
  LIBS  = -lc -lmx -lsx -lcmd -ltcl -lX11

  eery@cherimoya [11] > ls /sprite/lib/sun4.md | grep tcl
  libtcl.a
  libtcl5.a
  libtcl6.2.a
  libtcl6.3.a

I'm sad he's retired.

Here's another plug for his book:

A Philosophy of Software Design/2e

https://www.amazon.com/dp/173210221X

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.

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.

Now if we could just bring back Navi/AOLPress....

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.

I remember using tcl inside pages running under Vignette Story Server circa 2000 before we started with jsp

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.

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.

It's in decent company in the Redmonk graphs[1], in the vicinity of Smalltalk, Mathematica, D, and Haxe.

[1]: https://redmonk.com/sogrady/2026/04/14/language-rankings-1-2...

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.

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.

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.

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.

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.

https://xn--gckvb8fzb.com/a-word-on-omarchy/

glfw! that's a bit surprising.

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 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.