It is worth learning considering a few things. The ruleset is freakishly simple and the docs are good. The speed at which you can prototype a gui is somewhat unparalleled. The ability to glue or automate different bits of software is often better than bash. It is called the tool command language after all, though they'll never get me to stop saying tickle.
> The speed at which you can prototype a gui is somewhat unparalleled.
Yeah, but it's some kind of Alternate Web Ghost Story prototype where an uncanny valley ends up terrorizing the developer.
Imagine: you hear faint sounds outside your tent in the middle of the night. You get out to see an vector infographic rustling through your backpack.
And as you slowly approach, it gets bigger. And bigger.
Except for the text, which remains the same size no matter how close you get!
"AAaaaah!"
When the forest rangers arrive the next morning, you and your entire party are nowhere to be found. All that remains is a tiny library a mere few megs in size.
A bush behind your tents hides an old, rusty sign with text too small for the rangers to read:
"Caution: tk canvas scale subcommand does not rescale text or images-- it only adjusts their x/y coordinates."
Lol! And when you're running your very own GUI app in the cutest little window. But, just to see what happens, you decide to reach for the resize handle...
“I can’t believe I’m praising Tcl”[1] (last posted here[2] in 2020) also makes some good points that are not in other writeups, specifially regarding interactive use.
I think Tcl(’s standard library) is still too wordy to make a comfortable interactive shell, but it’s still leagues above everything else I’ve seen; in particular, I can’t help but think Shivers’s dismissal of interactive use in his description of Scsh is something of a cop-out—there are (now, maybe not then) plenty of nice languages to hack a prototype or a quick script in, but somehow Bourne shell + Unix utilities is still the best we can do that won’t make my fingers ache? Tcl demonstrates very well that inside sh there’s a Lisp trying to get out (and Plan 9’s rc does the same but worse), but somehow that line of thought seems to not have been continued further.
(Just in case, I see both Elvish and PowerShell as being more in the Scsh direction than the Tcl direction, that is making a “proper” language at the expense of interactive use and my fingers; Elvish appears to at least have a properness-Bourneness knob but that’s hardly a solution. Anyhow, I don’t think either contributes much to our knowledge of the virtually untouched interactive-use landscape, as opposed to the relatively well-explored scripting-language landscape.)
I’m rereading this now and I realize I was probably thinking about Oil, not Elvish, or rather that my brain mixed some of the Elvish materials I read into the Oil author’s (extensive and illuminating) blog posts and on top of that called the resulting chimera by its smaller part. I’m sorry.
As others already said, it's still a nice language to learn for several reasons. For one, doing even very minor stuff in the Lua-Tcl-Scheme triad gets you a good overview of the trade-offs of scripting languages, the importance of syntax etc.
But in a more practical sense, I see Tcl/Tk closer to awk these times. You won't deliver products in it, but it can come in very helpful in your own tooling or ad-hoc scripting. There's a surprising amount of uses for GUIs that are basically just a few buttons.
One very fruitful use I can remember is a factory setup, where people controlled parts of the machinery via Windows remote login. Now, if someone was already doing this and another person logged in, you basically stole their session.
So in came a very simple "busy" desktop app that just checked the status and showed an appropriately colored button. Clicking on it started the session app, I think there was even some "Please get off soon" messaging later.
There's a lot of utility in that, and Tcl makes it easy to build and deploy. Especially compared to some kind of webapp thingamajig.
You probably won't sell this as a product, but that's what scripting is about.
Note that Tcl's other killer app was "expect", which enabled you to script interactive terminal sessions, e.g. getting information or executing commands via ssh. That tied in well with a GUI to display said information or trigger the commands.
Whether Tcl as a language is worth it over just using e.g. Tkinter is another matter these days.
The GUI parts of the default git (git-gui/gitk) install are written in Tcl/Tk, by the way. This means that it's likely to be installed on a developer system. Even the Windows GIT package includes it, which adds to the ease of deployment/development.
I honestly think that it still makes sense. It’s a nicer language than most of the popular ones out there right now: more-easily embeddable than JavaScript, better designed than Lua. In a lot of way it would have been great had it replaced shell, although that would be a bit of a stretch.
It started out as a single script editor in under 1k lines of code written by someone else. I needed a syntax highlighting editor (so that I can see comments colored correctly in config files - useful if you use comments to turn configs on and off) so I took that script and added features. I kept the old key bindings to support old users of the original script (at its height I had like several dozen known users of the editor - people who wanted a better editor on routers and TiVo) but added key bindings to make it work more like Windows Notepad or Word/WordPerfect or SimpleText on the Mac etc, basically the "normal" GUI text editor keybinding, because I've gotten used to it. Even the Home key behavior I took from what I've come to expect on Mac code editors like BBEdit or CodeWarrior. So the ^C, ^V etc. are my additions to the script. The rest I inherited from the original script.
Some communities actually promote that style. Particularly the terse array languages like APL or K/Q. Each file might only be half a page of code (you can do a lot with a single line of APL) so long and detailed names might not be necessary. You can look at all of Aaron Hsu's talks to get a better idea of this (particularly everything about his co-dfns compiler). He wrote thousands of pages of code to finally get to the final compiler that is a single page of code (fits on a t-shirt).
It makes no sense to me. Even in math notation where one-letter names and terse notation are the norm, you rely heavily on familiarity and convention to understand the notation.
Reading a computer program written in such terse style is like reading a textbook in a completely unfamiliar field, without a symbol glossary or explanatory text. The cognitive burden can be extreme.
I do agree that there is some value in higher information density and the ability to quickly "pattern match" on sections of code (eg. regex), but only up to a point.
Looking at the scripts, they're mostly wrappers intended to be called on the file or a selection, so closer to a macro, shortcut, vim mapping etc. instead of a general purpose executable name. So closer to "C-x C-k" than "M-x save-buffers-kill-terminal".
(Most of them seem to have parameters, so it wouldn't make sense to golf this even further and have a exec command that just accepts one letter)
It's because they're easy for me to remember and easy for me to type. No other reason. a=awk, c=git commit, g=go, r=replace, s=sed and u=undo (obviously z would work just as well for undo). The core idea was commands in the editor is just any executable in your system instead of a custom scripting language - kind of like CGI. You are free to implement commands in bash, tcl, javascript etc.
https://www.se-radio.net/2022/07/episode-520-john-ousterhout...