Why I Like Tcl
world-playground-deceit.net
world-playground-deceit.net
My interest in the language got a second wind when I read yosefk's blog entry about it https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
I think there's room for a new language which speaks to Tcl's strength as a command language. This is an under-recognized niche IMHO, mostly covered by shell languages, which have a necessary focus on running other programs. That means they need to communicate with those programs primarily through the command line interface for invoking a program, which is a very thin bottleneck for interactive feedback.
Tcl as a scripting and extension language, which focuses on issuing commands, is to this day basically unique (this theme is extensively elaborated in the linked post, it's a good read). I find myself wondering what another language, freed of the constraint to fit the (from a modern perspective) extremely resource-constrained systems prevalent when Tcl was big, might look like.
If I ever figure that out, I might try and write it.
On the off chance you, or other readers, were not aware, Tcl drives the most famous example of that use case that I know of: https://core.tcl-lang.org/expect/index
While trying to dig up the repo for it, I came across https://github.com/Netflix/go-expect#osexec-example which really highlights your point about "wowzers, what a lot of boilerplate to communicate with a subprocess". I had to deal with a few projects where folks thought that using Python as a "better bash" was a good thing to do, and it, too, was horrific, made worse by the fact that poor subprocess.Popen doesn't have a raise_for_status() equivalent to have it STOP RUNNING if something goes wrong, cheerfully leading to a cascade of errors that is far less likely to happen in bash or likely in Expect, either
To be fair, I think that Tcl really improved with 8.5 (apply, dict and no more expr). No idea what I would have thought of it if my first encounter had been way before that point.
> I think there's room for a new language which speaks to Tcl's strength as a command language.
As mentioned in the "Cons" section, have you looked at Rebol's revival https://github.com/red/red?
The reasons I think something new would do well are things Tcl can't fix. Examples: leading zero octal, 0 is false, 1 is true, and it just... Tcl has a face only a mother could love.
I've been interested in Red for years now without trying it out. It's very high-concept and sort of... totalizing? in a way which seems maybe unfocused. It is admittedly quite clean on the page, and there are some solid ideas there, one of these days I'll take it for a drive. One quibble is they need to stop punting to Rebol and write native documentation, being told that Red is "90% compatible" with another language no one uses, and getting shelled out to the documentation of that language, is not a great way to keep the funnel intact. But you have to, this is where the "official documentation" link sends you: https://github.com/red/docs/blob/master/en/SUMMARY.adoc
That, combined with the "Red is all things to all people!" messaging, gives me the (perhaps unfair) impression that I would run into dusty corners and sharp edges fairly quickly if I tried to cash in the Ultimate Programming Language promise. Just finish up the docs, folks. Only have to do it once.
I don't think it fits the new command language vision, however, because bare words are evaluated. In Tcl, the first word is special, and it's a command, everything else is strings unless you want to substitute in another string (or what have you). That strikes me as essential for this niche, notably this is how shell works and it's tough to imagine a usable shell which didn't work that way.
But talk is cheap and a language implementation is very, very expensive. If I needed to add a command language to a program, I'd use Tcl and call it a day.
I have one application that needs tcl and tk, I use it for my checkbook, it is a nice and simple application that data is saved in text files.
cbb has been around since 1999 and Professor Marco A. P. Cabral fixed many issues a few years ago. I think me and the Professor are the last ones left using cbb.
https://sites.google.com/matematica.ufrj.br/mapcabral/softwa...
It works with version 8.6, had minor issues with 8.5, but prior versions it worked fine. Since I heard 9.0 was released, I hope that odd issue does not come back or other issues do not occur :)
But, one good thing, you can have multiple versions of it on your system. Plus it works great on Linux and the BSDs.
But there have been too many discussions about how horrible this is for performance, that it is always worth mentioning the fact that internally this simplistic view is not true.
OT1H, this labels itself as Verilog, but OTOH https://github.com/Scaleda/Scaleda/blob/v0.2.2/src/main/scal... (it has a non-standard license, so caveat lawyerator)
I couldn't readily find the Antlr file that it is adapting into IJ's AST in order to know how much it tries to cover
"The TCL Programming Language"
and they will understand why Tcl is still relevant.
I hope he releases an update for 9.0.
About Wiki, 1400K is an exaggeration, the default curve minimum (at night) is 4500K.