samatman
9 months ago
I first ran into Tcl on Sparc stations in the mid 90s, and came away with the impression that it was just a bad language. I was implicitly comparing it to Perl, this wasn't a deep dive or anything, just a vague and negative impression which stuck with me.
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.
mdaniel
9 months ago
> 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.
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
BoingBoomTschak
9 months ago
> I first ran into Tcl on Sparc stations in the mid 90s, and came away with the impression that it was just a bad language. I was implicitly comparing it to Perl
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?
cmacleod4
9 months ago
Modern Tcl already has a lot more stuff in it than the early resource-constrained versions, though the basic principles are the same. Still, there's no harm in reinventing a better wheel :-)