Hacker News Reader

> 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

> 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?

My impression was a rather shallow one, between the language getting better and my understanding why it looks and acts the way it does, I'd say my change of heart is 20% the former and 80% the latter.

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.

Leading-zero-means-octal-number is one of the things which got fixed in Tcl 9.0, see https://www.tcl-lang.org/software/tcltk/9.0.html#tclchanges - the subsection headed "Numbers".

Hah! Old dogs can learn new tricks. That pleases me an unreasonable amount.

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 :-)