Tcl the Misunderstood (Antirez)

Another excellent aspect of Tcl I found is extensibility of JO's C implementation. At some point I needed to write some native code for speed and making this visible to the Tcl interpreter was a pleasure. Plus the codebase is so clean and well written.

Previous discussions:

31 points|pmarin|16 years ago|17 comments

https://news.ycombinator.com/item?id=389107

181 points|zeitg3ist|12 years ago|110 comments

https://news.ycombinator.com/item?id=4920831

131 points|throwaway344|11 years ago|45 comments

https://news.ycombinator.com/item?id=7069642

182 points|goranmoomin|2 years ago|79 comments

https://news.ycombinator.com/item?id=31129936

The biggest problem with Tcl is the fact that C won.

This means that "" and {} are expected to work a certain way from C and when you hit Tcl you are HORRIBLY confused.

It's especially confusing as {} is simply quoting and has nothing to do with scope. The fact that Tcl is written such that {} is used with indentation in if-statements muddies the issue even further.

I suspect that a choice of ` (backtick) for Tcl " and " instead of Tcl {} would have made Tcl way less confusing to the vast majority of programmers.

I understand why things weren't done that way--having the ability to know that your quote has different characters for open vs close is very valuable for efficient parsing.

Nevertheless, the Tcl choices were unfortunate given the way history played out.

This is fascinating. I have emailed Tcl's "father" (John Ousterhout) at length and he is one of the few to have actually tried to test what coding patterns make for better code and is the only book I recommend anyone when they want to get better.

Unfortunately most fall for the more popular Clean Code and it's derivatives.

Edit: The book is "A Philosophy of Software Design"

I've long wished to have the free time to write a Tcl-derived language, because it really is so elegant in many ways, it just needs a bit of modernization in some areas. It's been years since I really thought much about this but I recall one of the things it's missing is closures (it does have lambdas at least).

Reading through this article, the memoize implementation does have an issue which is if the memoized command wants to call uplevel or upvar it'll get the wrong stack frame. If I were writing this I'd structure it so it's used like

  proc myMemoizingProcedure { ... } {
    memoize {
      ... the rest of the code ...
    }
  }

such that it can just `uplevel` the code. Or better yet I'd make `memoize` replace the `proc` keyword (or perhaps `memoize proc myMemoizingProcedure …`).

EDIT: I suppose memoizing makes no sense in a procedure that wants to use upvar or uplevel though, because memoizing only works for pure functions.

A lot of the power of expect seems to come from the fact that it's (normally) configured/scripted in Tcl

https://linux.die.net/man/1/expect

I really like that it, like the article mentions, just looks like config for basic scripts but also scales to whatever you need it to do.

My favorite obscure line of TCL:

https://github.com/athas/EggsML/blob/master/concieggs/hooks/...

A line that contains a regex pattern for matching regex patterns.

TCL was chosen here because its regex engine isn't too powerful.

The biggest weakness IMHO is the inability to comment out elements of an array. Even bash lets you do this and it makes testing and dev so much easier. Really wanted to love it, but that got in the way too many times.

Wish I had this page when messing around with Eggdrop[1] back in the late 90s.

As a self-taught novice programmer that started with QBasic and had moved on to Turbo Pascal, I found Tcl to be very confusing and it left a rather negative impression.

Reading this page now though, it seems a lot more logical and reasonable than it appeared at the time.

[1]: https://docs.eggheads.org/tutorials/firstscript.html

One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program.

For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs.

I'd really like for there to be an agreed-upon standard option for graphical program development which was interactive and cross-platform.

Another great feature of Tcl for writing servers it that you can reload the code while it is running and keep all the state and connections open. Code up/bootstrap your server while it is running the whole time. Sure this is a security nightmare, but it is fun to code.

Fun fact: SQLite’s test suite is written in TCL https://github.com/sqlite/sqlite/blob/master/test/strict1.te...

Does anyone know of a good tutorial for getting starting with Tcl/Tk that still makes sense in 2024? I'm really intrigued by the idea of building and shipping simple, cross-platform GUIs, but I'm completely overwhelmed by all of the installation and configuration options. It seems like tclkit is supposed to be the go-tool tool for self-contained executables, but I honestly can't even figure out which site is the source-of-truth for downloading it, let alone installing it.

This language seems like a security nightmare to me regarding code injection attacks through untrusted inputs.

> Concept 9: Eval and Uplevel

That's where it gets really criminal: Dynamic scoping rules. There is no lexical scoping and hence no closures. If you use `uplevel`, your procedure works or doesn't, depending on the caller. There is a reason Tcl is the last language that uses this braindead mechanism.

Tcl is basically a sloppier Perl with a GUI.