Yet it has a special place on my heart and was one of the interpreters easiest to extend, in regards to the FFI API.
It would be cool to have a Tcl revival though (although I don't see it happening - I'm not in the community though so hopefully someone more informed can post). The language itself seems more capable than most give it credit for. I'm more of a Python fan myself, but can appreciate Tcl after reading through a book on it and writing a few scripts.
https://www.magicsplat.com/ttpl/index.html
For those who are not aware, Tcl is actually part of standard Python distribution through TKinter.
There are many things Tcl has built in that are quite amazing, like a robust virtual filesystem support, reflective channels, and less known these days Starpacks (stand alone runtime) that bundle sources with the binary.
I am current working on bringing back kitcreator for an AI project that uses Tcl as a scripting environment over llama.cpp.
https://github.com/tclmonster/kitcreator
Roy Keene is the original author, and has done some really clever stuff here, like encrypting the VFS appended to the executable. I added compression to this. It provides some manner of obfuscating sources.
And actually, I am also working on using tohil to compile a static Python and load it as a Tcl extension, with the goal to have standalone Python applications bundled with their sources and completely loadable from within the VFS. This will provide a means to bundle TKinter with a “frozen” Python app.
If you’re interested, I have various Tclkits available for download on GitHub. I have added dependencies to them like TLS for HTTPS and so-forth. It can be convenient to have them standalone; the TLS extension here is bundled with the ca certs from libcurl.
https://github.com/tclmonster/kitcreator/releases/latest
And here’s an example how I use the kits in the CI build. It uses the kit it builds to push the update using the TLS extension along with the GitHub REST API:
https://github.com/tclmonster/kitcreator/blob/main/.github/s...
In the most recent big version update there was what I'd consider a breaking change regarding text encoding handling, but it was possible to go back to the old behaviour with an additional parameter .
I introduced it into some of our release tooling in the mid-2000s. Easy to integrate, easy to understand, unsurprisingly good string/text handling, expect was very useful, and it’s not going to be used by anyone else, so no worries about version conflicts.
It ran successfully largely unchanged for around a decade.
I like to use tools that more than merely work.
There's a reason nobody outside EDA uses it.
Yeah, Tcl has its design warts, but I don't think it has that many remaining that can't be fixed via metaprogramming. Even the popular Python manages to frustrate me with its idiotic statement/expression divide (they doubled down by making match() a statement...) and constant need to convert between generators/iterables and lists.
Thing is that R6RS Scheme (or R7RS-large if it comes out one day) is basically a better Tcl if you only consider scripting and don't need the event loop. If Tcl had played its cards right, it'd have competed with fish/rc/nushell/powershell instead, it was really ready to be a better shell well before any other.
------
To be honest, Common Lisp is the only language I've ever seen get this right without compromising on said purity by specifying the reader (parser): https://www.lispworks.com/documentation/HyperSpec/Body/02_.h...
Comments are then just the result of a readtable entry like any other, allowing this kind of voodoo:
; A comment
(set-macro-character #\% (get-macro-character #\;))
% Also a comment