The Zip filesystem stuff is wonderful change to see: it takes a number of techniques that were common in the community (if you had the right tools and knew how to use them) for building standalone applications, and makes them part of the basic toolkit in a standard way. It's a truly excellent change, and I'm glad to see it.

Why did they remove tilde '~' as a convenient shortcut for the Home directory?

mostly people consider tcl non-performant because fundamental operations are about twice as slow as cpython, which is no speed demon: https://news.ycombinator.com/item?id=41637953

another reason is that we don't know how to write fast tcl, as i inadvertently demonstrated in that thread

Agreed, my only exposure to Tcl was writing IRC scripts for bots and I have nothing but fond memories of the experience.

I think of Tcl as Lisp for C programmers; by which I mean, Tcl give you the metaprogramming capabilities you get with Lisp in a language that looks more like C, plays well with C, is much more straightforward than your typical shell language, and has a cross-platform GUI. A skilled Tcl programmer can do magic.

I spent ten years, from 2005 to 2015, programming almost entirely in Tcl/Tk and I loved it. Since then I mostly use it for casual scripts rather than for writing apps; but it's still my #1 choice when I need to do some scripting to automate something at the OS level.

I should also note that Richard Hipp, the creator of SQLite, says that SQLite is coded in Tcl. The database engine itself is coded in C, of course; but the vastly larger test suite is mostly coded in Tcl; and it's the test suite that makes SQLite the reliable engine that it is. The test suite persists; the engine's been re-written in whole and in part.

Standard fare:

BigIP iRules in F5 network appliances (and A10 appliances)[0], orchestration in Argonne National Labs super computer[1], Tealeaf[2], Python Tkinter[3] …

I use it day to day because it’s got a great balance of Lispyness and simple scriptyness, and a great C interface. It’s got a fine REPL, and can be built up (by writing in C) with extensions that are 100% first-class canonical Tcl, in good part (wholly?) because Tcl is such a simple language[4], and homoiconic[5]. A joy to develop in and use.

[0] https://community.f5.com/kb/technicalarticles/irules-concept...

[1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf

[2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%...

[3] https://docs.python.org/3/library/tkinter.html

[4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm

[5] https://stackoverflow.com/questions/6492704/what-exactly-doe...

I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).

I used it a few times, mainly because of Freewrap. With very little code I was able to write a Windows app with GUI that I could distribute easily as an executable:

  - A backup app for an online sales application (inputs items and spits out a file);
  - An app to fix files in a buggy POS for a large retail chain (this might have been used in thousands of machines, I can't recall the details now);
  - A small app to copy Forms/Reports to the server, fire compilation, and push the new file to git;
  - A wrapper for gs to help a media department easily join many PDFs into one file.

It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago.

It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B

If you aren't designing computer chips, you have no reason to use it. It's a horrible language.

The sooner the EDA industry can get rid of TCL, the better.

I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc.

Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for many SQLite applications. This is mainly related to (rapid) prototyping use cases.

From https://sqlite.org/tclsqlite.html :

> The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.

Quite common in space industry. It is the script language used in many (all?) SCOS-2000 based mission control systems. Yes, is is actually used to control satellites and spacecrafts.

Tk based GUIs work across pretty much all desktop platforms and are much less resource intensive than electron and friends.

Last use I remember seeing for it was in scripting Intel FPGAs

https://www.intel.com/content/www/us/en/docs/programmable/68...

Eggdrop IRC bots. Even 25 years since I first created one, Eggdrop is still the best and most reliable + flexible IRC bot platform, and comes with native support for Tcl.

Copy-pasting a "hype" checklist I made some eons ago:

* Extremely consistent and elegant syntax - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. Nearer to CL than Python on that point.

* Homoiconic through strings (like almost every language with eval) but most importantly, through "list-like" strings.

* Official man pages! No web-only and spec-like doc like cppreference nor lackluster "minimalist" stuff like pydoc (compare `pydoc print` with `man n puts`, for example).

* One of the simplest if not the simplest interaction with C, letting you write C plugins very easily (with critcl and swig to help).

* Not slow, not fast. In the same ballpark as cpython or Perl; doesn't need a tracing garbage collector, refcounting does the job since no cycles are possible by design (worse for throughput, but lighter runtime).

* Fun type system that is superficially "everything is a string" (like sh) but in reality "everything is a tagged union with on-the-fly conversion when needed and a guaranteed string representation". Allows for transparent serialization (`puts $mydict stdout` <=> `set mydict [read stdin]`), like CL's read/write.

* Powerful introspection through `info` (mainly). Allows for stuff like getting the name/body/arglist of a procedure, get all the registered procedures, know if a variable exists, get information on the stack frames and their content, etc... Together with `trace`, you can even write an internal debugger in few lines.

* Procedure arguments are passed by pointer with a copy-on-write system: don't modify the argument and you don't get any memory copy. To you, it just looks like regular passing by value.

* Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) attached to a relative stack frame number, quite elegant considering the language's core concepts.

* If you use at least the builtin extensions (thread, http, tdbc, tcltest, msgcat) and the very basic tcllib/tclX/tclUdp/tklib packages, you're almost set for life. Personally, I also recomment the very convenient tclreadline, tdom, pipethread, tablelist and tclcurl.

* Channels is one of the cleanest I/O implementation I've ever used with some cool features:

- Transformations allowing filters like deflate/zlib/gzip or TLS to be put on a channel (see `transchan` for the API).

- Reflected aka virtual channels, to make your own channels. Basically like glibc/BSD's unportable fopencookie/funopen or CL's gray streams.

- Centralize a lot of ioctl/fcntl mess and even more (like defining the EOF char) in `chan blocked/configure/pending`.

- Integration with the event loop via `chan event/postevent` allows for a nice callback oriented approach to sockets and pipes.

- Other third-party channel types include pty (expect), random, memory or fifo (memchan).

* Builtin event loop (see `after`, `vwait`, `socket -server` and `chan event`) for powerful and seamless concurrency/command scheduling. Much simpler than Python's very "AbstractBeanFactory" asyncio.

* An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread::send/broadcast/transfer`) and performant (`tsv`) synchronization/communication facilities.

* Finally a sane, light and portable (even more with Tile) GUI toolkit: Tk.

* One of the fastest Unicode aware regex implementations, written by Henry Spencer himself. Has its own greater-than-POSIX-ERE syntax called ARE, not as complete as PCRE (lacking lookbehind constraints, most importantly), but still great for an hybrid NFA/DFA engine. Performance comparison with Perl: https://github.com/mariomka/regex-benchmark/pull/44.

* `uplevel` (eval a script in a different stack frame) and `tailcall` (replace the current procedure with another command) let you augment the language by implementing control structures and keywords yourself. Inferior to CL's synergy between unhygienic macros, "naked AST" style homoiconicity, symbols as first-class objects, gensym and quasi-quoting, but still quite powerful.

* Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter.

* Recent versions (>= 8.5) really embraced FP with:

- Real lambdas (but not closures, these have to be emulated) through apply.

- Purer hash maps (dict) than ugly sticking-out-like-a-sore-thumb arrays.

- Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]` instead of `expr {3 * (1 + 2)}`) including sane behaviour for more than two (reduce) or zero (neutral element) arguments.

- Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-lang.org/page/Functional+Programming for more.

* Multiple more-or-less powerful OO systems (now based on the builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take on CLOS or Snit for something Tk oriented.

* Some massive issues on the top of my head: lacking a LSP/SLIME equivalent, the warts of the weird type system (no way to differentiate between atoms and single element lists or evenly sized lists and dicts), missing metaprogramming facilities like quasi-quoting, no official support for UDP and UNIX domain sockets, no GC for class instances (cf https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in core, subtly broken exec (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-lang.org/tips/doc/trunk/tip/259.md)

Here are some project I made with it, still worth using compared to CL which is my true love, simply because its stdlib is better suited for a lot of tasks:

  https://git.sr.ht/~q3cpma/mangadex-tools
  https://git.sr.ht/~q3cpma/rymscrap
  https://git.sr.ht/~q3cpma/lemonbar-tcl
  https://git.sr.ht/~q3cpma/tcl-misc

>Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.

For a long time it was the only way to get a decent IRC bot going, because eggdrop[0] was a Tcl wrapper around a small C core, but the only place I've seen it in the wild other than IRC bots was in the Xilinx toolchain and once when I was in undergrad some TA was using it to get telemetry from Tektronix oscilloscopes in the robotics lab.

[0] https://www.eggheads.org/

When I had contact with TCL for a networking class in the 90's I already knew Python and didn't like that "everthing is a string" pathos.

For me the greatest TCL contribution was Ousterhout's dichotomy: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by the author himself: https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd...

Curious as well. The only time I've seen it used in the wild is Redis' test suite. https://github.com/redis/redis/tree/unstable/tests/integrati...

I use it for "expect" because it just works.

I used it a few weeks ago to fetch and display access timing histograms in an FPGA project.

> Anybody using it for something else and can speak to why you’d use it today?

It was often used as an embedded language (e.g., in F5 load balancers), especially in the pre-Lua days.

The only reason to use it today is because you're forced to by the EDA industry. Otherwise there are far far better options.

That also means this release is basically irrelevant for the next 10 years because that's about how long it takes the EDA vendors to update their bundled TCL versions.

A theming engine went in something like 15 years ago now; the default theme looks rather dated, but there are plenty of others. See https://wiki.tcl-lang.org/page/List+of+ttk+Themes (though the screenshots of core themes are from 8.5/8.6 - default in particular has changed a bit in Tk 9).

The "catch" is that the theming engine has its own new widgets, and so to be themed an application has to use the new API. Code from 1995 (or 2005) still produces GUIs from 1995.

There is a redesign of the website in progress. In the meantime, take a look at https://wiki.tcl-lang.org/page/Showcase .

Brings back great memories and (more or less) where I learned both Tcl & SQL... Back in the mid-90's this is the stack and software I was playing with, though admittedly I was using the ArsDigita Community System proper rather than OpenACS (and back when ArsDigita was a thing).

Funny thing is I remember taking some free classes sponsored and taught by ArsDigita in an office they had in Pasadena, CA (or was it Glendale....???) they weren't too deep or long, but nice introductory stuff.

Tcl's magic is mainly from uplevel and upvar as they allow you to do crazy stuff with the callstack to enable all kinds of metaprogramming. It's not a lot of magic, but it's very powerful.

The Tcl language is made up of commands; a command has a name and takes an argument list, with which it can do literally anything. The standard commands are written in C; Tcl `procs` are commands that are written in Tcl. The control structures, like `if` and `foreach` and `while` is just a Tcl command. The `proc` command that defines a proc is just a Tcl command.

I think of it as Lisp for C programmers.

So: is the language implemented mostly in itself? No, it's mostly implemented in C. Is there a minimal amount of magic? No; the amount of magic you can do is effectively unlimited.

Tcl is incredibly consistent, because it's homoiconic.

Perhaps. I think one of the main reasons JS caught on is that it had no significant baggage and the designers could take it in any direction it needed to go. Every language used by more than a few people, no matter how good it is, has some baggage. As a result, in that alternate universe, the browser scripting language landscape might have been a lot more fragmented.

The work on the safe subset of Tcl for the web can be exploited today to run untrusted scripts in an easily managed sandbox. If you want you can strip away enough commands for the language to be non-Turing complete.

funny enough, tcl browser plugins were around from at least 1996

https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/

I'm pretty sure some fellow students came into our computer room before that, "look now there even is a TK plugin for Mosaic!". it was not in "look it's like gopher but with a mouse!" days, but not that much later.

however you of course had to _do_ something to use it, while JavaScript came out of the box (once it was there).

> maybe the right thing happened

Absolutely. I would have hated to see things like

  set x [ expr $y + $z ]

I doubt the world would have stuck with TCL if that had happened. JavaScript was good enough for people to put up with. TCL definitely isn't. More likely we would have ended up with TCL + something else, with TCL deprecated.