[deleted]
Tcl the Misunderstood (2006)
21–30 of 72 posts
Re: Tcl the Misunderstood (2006)
#22The 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 "…
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 t…
> 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.
Re: Tcl the Misunderstood (2006)
#23Tcl is basically a sloppier Perl with a GUI.
Well, and a GUI that people see fit to implement within many other languages as well.
Re: Tcl the Misunderstood (2006)
#24Another 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.
Re: Tcl the Misunderstood (2006)
#25One 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…
> 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.
Re: Tcl the Misunderstood (2006)
#26One 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…
> a cross-platform HyperCard clone
I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)
Re: Tcl the Misunderstood (2006)
#27Fun fact: SQLite’s test suite is written in TCL https://github.com/sqlite/sqlite/blob/master/test/strict1.te...
Re: Tcl the Misunderstood (2006)
#28I'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 comma…
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.
Re: Tcl the Misunderstood (2006)
#29Tcl is basically a sloppier Perl with a GUI.
But you can look at it without barfing, at least. And have fun doing wacky metaprogramming instead of wacky code golfing aka obfuscation.
Re: Tcl the Misunderstood (2006)
#30Another 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'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.