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.
I'm pretty sure Ousterhout intended for people to write a few deep modules in C and only use Tcl to glue everything together/provide extensibility.
(we did exactly this for networking code about 30 years ago: C for the data plane and Tcl for the control plane. That architecture remained in service for decades.)
I've not seen the code, but the author has written a book [1] which has the advice I've ever seen. Much better than "Clean code" and other books in that direction. So it does not surprise me that the code is so well written.
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.
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.
Closures are not easy to fit with "everything is a string", which favors dynamic scoping over lexical scope. I wonder what you'd change to make tcl more amenable to modernization.
Tcl totally has lexical scoping, through proc and apply that create a new frame and thus new local bindings. Closures with explicit bindings (as opposed to tree-walking to find free variables to match with [info locals] which is something Tcl really can't do due to its "list == atom" thing) are easy to do through apply and a way to store the environment.
>TCL was chosen here because its regex engine isn't too powerful.
Uh, not sure I see the significance but wouldn't that make Tcl less apt for this than something else? Why would you purposely choose a less powerful regex engine?
When you feed the engine regexes supplied by users, you don’t want arbitrary code execution or exponential or infinite running times caused by obscure features.
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.
I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.
Once upon a time (Tcl??/Tk3.6) there was XF by Sven Delmas. It had some issues and really would have needed something like namespaces. AFAIR it took forever to get a stable version for Tk4.0.
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.
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.
The use of {} for strings without substitutions and effectively for scope are actually interrelated, remarkably.
Scopes are special syntactic forms that delegate variable substitution to the associated procedures. For example, a "for" statement evaluates the body of the function after substituting the loop variable. In a string based language, that's basically the same as expressing the scope in a string form where the string content is passed verbatim as an argument without variable substitution or function invocation.
Having used Tcl extensively back in the day, I am not sure that this syntactic cleverness really was a major impediment to adoption. It was just something to learn. Same was true with [] meaning lisp-like function calling rather than array definition.
Baseline Tcl's biggest challenge, in my opinion, was providing mechanisms to write modular code for larger programs and data encapsulation. Core Tcl put off decisions about the appropriate mechanisms to do so by only providing "namespaces" as a building block for higher level third-party syntax. That led to fragmentation at a time when other languages were gaining popularity.
I came into this comment thread thinking "why should I bother with Tcl if I know Perl" but your comment nearly sold me. When I do Perl it's because I can afford to be sloppy, and coming with a GUI sounds like a good deal!
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.
Yes! Tcl's C code is a real pleasure to work with and extend.
I got to write some of the updates in this 2nd edition regarding the C interface:
https://www.oreilly.com/library/view/tcl-and-the/97803216017...
I also recall appreciating Tcl's C code.
I'm pretty sure Ousterhout intended for people to write a few deep modules in C and only use Tcl to glue everything together/provide extensibility.
(we did exactly this for networking code about 30 years ago: C for the data plane and Tcl for the control plane. That architecture remained in service for decades.)
I've not seen the code, but the author has written a book [1] which has the advice I've ever seen. Much better than "Clean code" and other books in that direction. So it does not surprise me that the code is so well written.
[1] https://milkov.tech/assets/psd.pdf
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
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
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.
indeed, and other ports of Expect (Perl Pexpect, Python PyExpect) feel awkward as the constructs don't map quite as well to those languages.
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
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.
There are these pages on the wiki regarding closures, and a reference to needing to change the internals of tcl_ObjType in order to implement them.
https://wiki.tcl-lang.org/page/Closures
https://wiki.tcl-lang.org/page/Emulating+closures+in+Tcl
TCL 9 has surely fiddled with tcl_ObjType I hope, but it doesn't seem like it from a glance.
Closures are not easy to fit with "everything is a string", which favors dynamic scoping over lexical scope. I wonder what you'd change to make tcl more amenable to modernization.
Tcl totally has lexical scoping, through proc and apply that create a new frame and thus new local bindings. Closures with explicit bindings (as opposed to tree-walking to find free variables to match with [info locals] which is something Tcl really can't do due to its "list == atom" thing) are easy to do through apply and a way to store the environment.
The last implementation in https://wiki.tcl-lang.org/page/Closures is pretty nice.
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.
>TCL was chosen here because its regex engine isn't too powerful.
Uh, not sure I see the significance but wouldn't that make Tcl less apt for this than something else? Why would you purposely choose a less powerful regex engine?
When you feed the engine regexes supplied by users, you don’t want arbitrary code execution or exponential or infinite running times caused by obscure features.
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.
I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.
Once upon a time (Tcl??/Tk3.6) there was XF by Sven Delmas. It had some issues and really would have needed something like namespaces. AFAIR it took forever to get a stable version for Tk4.0.
> why there isn't a standard graphical tool for laying out a GUI program
It is a bit surprising since it seems like you could use Tcl/Tk to write it.
The Tk canvas makes writing simple drawing programs fairly easy, and a GUI editor seems like it wouldn't be terribly difficult.
> a cross-platform HyperCard clone
I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)
Fun fact: SQLite’s test suite is written in TCL https://github.com/sqlite/sqlite/blob/master/test/strict1.te...
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.
TIP 401 proposed a fix for this but has not progressed so far - https://core.tcl-lang.org/tips/doc/trunk/tip/401.md .
By arrays you mean something like this?
If the inability to comment out entries here is a problem, that's also something you can fix, you can write something like such that you can then write the following and it will remove commented lines: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"
Which book..?
My guess 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.
The use of {} for strings without substitutions and effectively for scope are actually interrelated, remarkably.
Scopes are special syntactic forms that delegate variable substitution to the associated procedures. For example, a "for" statement evaluates the body of the function after substituting the loop variable. In a string based language, that's basically the same as expressing the scope in a string form where the string content is passed verbatim as an argument without variable substitution or function invocation.
Having used Tcl extensively back in the day, I am not sure that this syntactic cleverness really was a major impediment to adoption. It was just something to learn. Same was true with [] meaning lisp-like function calling rather than array definition.
Baseline Tcl's biggest challenge, in my opinion, was providing mechanisms to write modular code for larger programs and data encapsulation. Core Tcl put off decisions about the appropriate mechanisms to do so by only providing "namespaces" as a building block for higher level third-party syntax. That led to fragmentation at a time when other languages were gaining popularity.
> Baseline Tcl's biggest challenge, in my opinion, was providing mechanisms to write modular code for larger programs and data encapsulation.
I don't know if something about tcl's design precluded lexical scoping and a normal "var" keyword. But "upvar" definitely seems like a smell.
Sure, the "biggest problem with TCL" is some minor syntactical annoyance that you'd get over within the first hour of using it.
In Tcl, "quoting" and "scope" are the same thing.
Tcl is basically a sloppier Perl with a GUI.
I came into this comment thread thinking "why should I bother with Tcl if I know Perl" but your comment nearly sold me. When I do Perl it's because I can afford to be sloppy, and coming with a GUI sounds like a good deal!
Well, and a GUI that people see fit to implement within many other languages as well.
But you can look at it without barfing, at least. And have fun doing wacky metaprogramming instead of wacky code golfing aka obfuscation.