TclWise: Guide to the Tcl programming language (2004)(invece.org)
invece.org
TclWise: Guide to the Tcl programming language (2004)
http://www.invece.org/tclwise/
14 comments
if someone is really interested in learn Tcl (not Tk)
i strongly recommend "Tcl 8.5 Network Programming" by Wojciech Kocjan and Piotr Beltowski
while the book is not very recent, Tcl didnt change much in the past few years
Tcl is really a super nice language, i think if they manage to get a cpan like platform, and maybe decent ide support .. it should be on every programmer list of languages
while the book is not very recent, Tcl didnt change much in the past few years
Tcl is really a super nice language, i think if they manage to get a cpan like platform, and maybe decent ide support .. it should be on every programmer list of languages
I disagree, "everything is a string" makes for sloppy programs. Programmers should be learning languages with good type systems if they want to build anything larger than some simple glue scripts.
I interned at a large company which had hundreds of thousands to millions of lines of Tcl scripts to customize an engineering package they use. It was a complete nightmare. It would be preferable to have less of those in the future.
I interned at a large company which had hundreds of thousands to millions of lines of Tcl scripts to customize an engineering package they use. It was a complete nightmare. It would be preferable to have less of those in the future.
Thank goodness that in our enlightened post-Tcl modern age million-line code nightmares no longer exist.
I'll take a statically typed million-line code nightmare over a Tcl one every time.
De gustibus non est disputandum.
What makes Tcl special and worth to learn?
Tcl is very easy to embed into your application. Tcl has a very simple syntax (with just 13 syntax rules). Tcl is very portable. Tcl supports threads and threading using the apartment threading model, where threads generate messages to send to each other. Tcl is asynchronous event-based. Tcl supports virtual filesystems (and virtual time...). Tcl can be compiled to machine code (TclQuadCode, still in progress, but functional). Tcl supports big integers natively. Tcl has excellent documentation for all the library, C API. Tcl has extreme backwards compatibility for binary extensions since all function calls and most data structures are versioned -- if you compile with Tcl version X, your binary extension will work with Tcl version >=X. Tcl has a large library of extensions and a uniform way to fetch them (Teapot). Tcl-based applications can be compiled into a single executable with their interpreter and other resources for single file deployment (that does not extract to disk and run on the run side, it uses the virtual filesystem capabilities to mount the executable and run from there). Tcl is easy to program in and most new Tcl developer's programs work. Tcl can be as small as you want, if you are willing to give up library support. Tcl has excellent unicode support within the BMP (basic multilingual plane; outside the BMP Tcl needs to be compiled differently than the default, which requires a breaking ABI change, though older extensions will still work thanks to versioning). Tcl is extensible within Tcl -- since most of Tcl is composed of the library and there are very few syntax rules most of Tcl can be modified from within Tcl -- you can rewrite "if" and "for" in Tcl if you want, or create your own control structures. Tcl has an option for Safe Interpreters, which can execute untrusted code safely.
What's not to love ?
What's not to love ?
(not OP, but hope you don't mind my $0:02)
tcl is what you get when you take shell and lisp, and smash them into each other.
In many ways, its a lisp whose central data structure is the string, rather than than the linked list (so, a sisp?). And instead of macros, you have fexpressions (functions which can decide at runtime whether or not to evaluate its arguments).
When you understand it like that, you can write some elegant code in it. And as it does have proper, efficient data structures under the hood, performance is on par with most other mainstream, traditional "scripting" languages. Although semantically, everything has a string representation - if you're creating a list, and use it as a list, it only exists in memory as a list (as so you dont pay performance costs of auto-casting to and from its string representation).
2 things really tick (goes with tickle, I guess) me off though:
1. because everything has a string rep, its hard to write code which can handle polymorphic types. For example, say a parsing routine which can take either a string, or a list of strings.
You end up having to 'tag' your data somehow (basically, roll your own static typing), which just feels wrong in such a dynamic language.
(could just be my deficiencies in using it, though)
(on the plus side, rolling your own tagging system using tcl ensembles shows just how malleable the language is. You can almost turn it into anything)
2. the parser could do with some changes. Too much tcl code just looks ugly because you (well, I) can't indent it the way I would like. So you (err, I) end up with /'s everywhere.
Bottomline: tcl is so close to being the perfect drop-in replacement for bash (if only the last extra yard was taken) that its painful to go back to using bash for, well, anything.
tcl is what you get when you take shell and lisp, and smash them into each other.
In many ways, its a lisp whose central data structure is the string, rather than than the linked list (so, a sisp?). And instead of macros, you have fexpressions (functions which can decide at runtime whether or not to evaluate its arguments).
When you understand it like that, you can write some elegant code in it. And as it does have proper, efficient data structures under the hood, performance is on par with most other mainstream, traditional "scripting" languages. Although semantically, everything has a string representation - if you're creating a list, and use it as a list, it only exists in memory as a list (as so you dont pay performance costs of auto-casting to and from its string representation).
2 things really tick (goes with tickle, I guess) me off though:
1. because everything has a string rep, its hard to write code which can handle polymorphic types. For example, say a parsing routine which can take either a string, or a list of strings.
You end up having to 'tag' your data somehow (basically, roll your own static typing), which just feels wrong in such a dynamic language.
(could just be my deficiencies in using it, though)
(on the plus side, rolling your own tagging system using tcl ensembles shows just how malleable the language is. You can almost turn it into anything)
2. the parser could do with some changes. Too much tcl code just looks ugly because you (well, I) can't indent it the way I would like. So you (err, I) end up with /'s everywhere.
Bottomline: tcl is so close to being the perfect drop-in replacement for bash (if only the last extra yard was taken) that its painful to go back to using bash for, well, anything.
If you like using Tcl as a replacement for bash you might enjoy "pipethread"
http://www.rkeene.org/tmp/pipethread-presentation-withnotes....
https://chiselapp.com/user/rkeene/repository/pipethread/
http://www.rkeene.org/tmp/pipethread-presentation-withnotes....
https://chiselapp.com/user/rkeene/repository/pipethread/
(sorry for the late reply, just saw this now)
Thanks for the info - reading your pdf now :-)
Thanks for the info - reading your pdf now :-)
Hmmm. Can any language manual be a HN post? Maybe I could get some points by posting 10 or 20.
As an embedded scripting language for Redis he didn't pick Tcl but Lua, though.