8 comments

[ 2.6 ms ] story [ 25.5 ms ] thread
Nice to see a new Tcl book on the bookshelves
Tcl gave me my first taste of scripting, but even more of a revelation was that I could bury a Tcl interpreter in a C program and use Tcl to control all the C modules. It made it really easy to dynamically change the behavior of a running server. Of course security was a bit of an issue, but in 1992 the net was still relatively calm.
Tcl's C API is still more or less the 'best in the business', afaik. Ruby and Python aren't bad, but Tcl just gives you so much access, and the source code itself (modulo the regexp code) is a pleasure to read if you want to hack the C code yourself.
Tcl is an amazing language. Very underrated. It's "EIAS" (everything is a string) philosophy, and the duality of strings and lists is very very powerful. It's got one of the best-documented and precisely written standard libraries I've ever seen (and the "extended standard library" tcllib is of similar quality).

E.g., if some script returns "350 seconds to execute command <more stuff here>" you can hold your nose and just treat the string as a list and extract the 0th element :) ('lindex $return 0').

It's speed leaves much to be desired. My ideal stack would in a large project would be:

1. Tcl shell on top 2. ... talking to either Python or C/C++ below

Python is, I think, still a bit faster than Tcl, but it's not the order of magnitude that C is. And, realistically, there are a lot of things that Tcl is fast enough for these days... it's certainly in the same league as, if not faster, than Ruby and PHP.
As much as I hate to admit it, my first programming job included a lot of Tcl, and I think learning it taught me how to program correctly, or at least in a highly maintainable fashion - this was in Perl's heyday.