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.

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.

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 ...
    }
  }

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.

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

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.

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.

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.

Tcl is basically a sloppier Perl with a GUI.

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"

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.