I do not know the language, but someday.
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.
I don't (personally) like to think of the type system as "everything is an auto-mutating and cached tagged union + string" - from the perspective of someone writing in Tcl, everything absolutely is a string. It's cool that the implementation happens to store some strings as integers, or arrays, or hash tables, or whatever else as a performance hack, but unless you're actually working with Tcl_Objs at the C level, you generally don't need to care about that.
You are correct that, on Tcl level, everything _is_ (behaves like) a string.
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.
The recent Tcl 9.0 release thread had some good discussion going on and my summary post about personal reasons for using it seemed to interest some people, so I fleshed it out a bit more on my website and decided to shamelessly link it on HN.
The recent Tcl 9.0 release thread
Changing the background color of the div id=content from chocolate(?) to white makes this 1000% more readable. PS now that I've read it - great summary.
I've bumped the font-size and line-height a bit, should be better. But I must admit that with redshift enabled, it isn't the most pleasant reading experience; otherwise, it's more grey than brown.
> No LSP/SLIME equivalent, which is as painful as it sounds.
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
Huh, good to know! Doesn't seem easy to make standalone, though.
Sorry, standalone for what? IntelliJ is one of the most advanced IDEs on planet earth. If you mean just having LSP itself, not in the context of an editor, then for sure an IJ plugin is not going to get that done
For Emacs?
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.
> 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
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 :-)
> 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.