* This is the original quote from [http://www.tuxedo.org/~esr/writings/taoup/chapter3.html], where ESR stands for ''Eric S. Raymond''. The idea here is to keep this version of the code pristine and edit the second version present later in this page. * Note from pne [mailto:pne@writeme.com]: I added a bit from the end of chapter 3, entitled "Trends for the future". Two of the paragraphs there mention Tcl. They follow the main text. If you want to edit them, you are now able to do so. ---- Original text ---- '''Tcl''' Tcl (Tool Command Language) was designed for writing small programs and ''embedded scripts'' (that is, scripts called from within C programs and returning values to those programs). Tcl has become popular not so much for itself as for several facilities that have been built on top of it. The two most important of these are: * The Tk toolkit, a kinder and gentler X interface that makes it easy to rapidly build buttons, dialog boxes, menu trees, and scrolling text widgets and collect input from them. * Expect, a language that makes it relatively easy to script fully interactive programs with widely variable responses. The Tk toolkit is so important that the language is often referred to as Tcl/Tk. (However, the Tk toolkit has a semi-separate life of its own, and is also frequently used with Perl and Python.) The main advantage of Tcl itself is that it is extremely flexible and radically simple. The syntax is very odd but totally consistent. There are no reserved words, and is no syntactic distinction between a function call and ````built-in'' syntax; thus the Tcl language interpreter itself can be effectively redefined from within Tcl (which is what makes projects like Expect reasonable). The main drawback of Tcl is that it has only weak facilities for namespace control and modularity, and one of those (upvar) is rather dangerous if not used with great caution. It scales up very poorly -- it is hard to organize and debug Tcl programs of even moderate size (more than a few hundred lines) without tripping over your own feet. The oddities of the syntax can be a problem as well; the distinction between string quotes and braces will probably give you headaches for a while, and the rules for when things need to be quoted or braced are a bit tricky. TCL also cannot handle I/O to binary files at all, and only provides access to a relatively small commonly-used part of the Unix API (essentially just file handling, process-spawning, and sockets). Indeed, Tcl has the flavor of an experiment in seeing how small a scripting language can get and still be useful. The definitive Tcl reference is [[''JO'']]. The Tcl world doesn't have one central repository run by a core group analogous to Perl's or Python's, but there are several excellent websites that point to each other and cover most Tcl tool and extension development, including http://purl.org/tcl/home/, http://purl.org/tcl/wiki/, and http://www.purl.org/NET/Tcl-FAQ/ . Tcl implementations exist for Windows 95 and Windows NT. Tcl/Tk scripts will run cross-platform with GUI capabilities. [[FIXME: Add Tcl/Tk case studies.]] ---- '''Trends for the Future''' [snip] Tcl has been in a period of relative decline, or at least of diminishing visibility. New Tcl releases since 8.0 have added little to its capabilities. In 1996 a widely-reported and plausible estimate of community sizes held that for every Python hacker there were five Tcl hackers and twelve Perl hackers. Today, judging by search results at SourceForge, Tcl and Python have switched places. As the above indicates, Python has risen in popularity as rapidly as Tcl has fallen. Though the Perl community is still quite a bit larger than Python's, a visible tendency of the brightest Perl hackers to migrate to Python has been rather ominous for the former language -- especially as there is no migration at all in the opposite direction. ---- * Here is the same quote to be edited and enhanced ---- '''Tcl''' Tcl (Tool Command Language) was designed for writing small programs and ''embedded scripts'' (that is, scripts called from within C programs and returning values to those programs). It is a popular myth that Tcl has become popular not so much for itself as for several facilities that have been built on top of it. The two most frequently mentioned of these are: * The Tk toolkit, a kinder and gentler X interface that makes it easy to rapidly build buttons, dialog boxes, menu trees, and scrolling text widgets and collect input from them. * Expect, a language that makes it relatively easy to script fully interactive programs with widely variable responses. The Tk toolkit is so important that the language is often referred to as Tcl/Tk. (However, the Tk toolkit has a semi-separate life of its own, and is also frequently used with Perl and Python.) The truth of the matter is that Tcl is quite often used by itself. One advantage of Tcl is that it is extremely flexible and radically simple. The syntax is very odd but totally consistent. There are no reserved words, and there is no syntactic distinction between a user-written function call and the default ````built-in'' syntax; thus the Tcl language interpreter itself can be effectively redefined from within Tcl (which is what makes projects like Expect reasonable). The main drawback of Tcl is that it has only weak facilities for namespace control and modularity, and one of those (upvar) is rather dangerous if not used with great caution. It scales up very poorly -- it is hard to organize and debug Tcl programs of even moderate size (more than a few hundred lines) without tripping over your own feet. On the positive side, upvar is seldom required, and so it only becomes a problem to those who haven't investigated far enough to find the better implementation alternatives. The oddities of the syntax can be a problem initially as well; the distinction between string quotes and braces will probably give you headaches for a while, and the rules for when things need to be quoted or braced are a bit tricky. Again, after you realize how simple the parser is, and the seven basic rules, things clarify. Early versions of Tcl (pre-version 8.1) also cannot handle I/O to binary files at all, and even now, Tcl as distributed in source in the original tar file only provides access to a relatively small commonly-used part of OS API (essentially just file handling, process-spawning, and sockets). Indeed, Tcl has the flavor of an experiment in seeing how small a scripting language can get and still be useful. Fortunately, Tcl community members have written many add on packages (in the same vein as Perl modules) which add on a wide variety of functionality, from additional Unix support, to graphics, sound, animation, automation of external devices, Windows and MacOS specific functionality support, and more. The original Tcl reference text is [[''JO'']]. However, most developers turn to [[BW]] as the reference for contemporary Tcl. The Tcl world uses SourceForge for their primary source code repository, run by the Tcl Core Team, a core group analogous to Perl's or Python's. There are several additional excellent websites that point to each other and cover most Tcl tool and extension development. Look at URL http://purl.org/tcl/home/ or http://www.purl.org/net/Tcl-FAQ/ first; among other things, they offer pointers to Tcl sources of an interactive Tcl tutorial. Also check out http://purl.org/tcl/wiki/ , an interactive Tcl WWW community. The Tcl core source compiles on * most unixes * Windows 95/NT/2000/Win/CE and * Macintosh * VMS * as well as many other platforms. Tcl/Tk scripts will run cross-platform with GUI capabilities. [[BW]] Brent Welch, Practical Programming in Tcl and Tk, Third Edition [http://www.beedub.com/book/] [[FIXME: Add Tcl/Tk case studies.]] tcl applications: tkdesk, xcdroast, suse_yast2, tkdiff embedded scripting: Electric Editor, vim, .. embedded usage of tcl ( the invisible tcl ) ---- '''Trends for the Future''' [snip] Tcl has been in a period of relative decline, or at least of diminishing visibility. New Tcl releases since 8.0 have added little to its capabilities. In 1996 a widely-reported and plausible estimate of community sizes held that for every Python hacker there were five Tcl hackers and twelve Perl hackers. Today, judging by search results at SourceForge, Tcl and Python have switched places. As the above indicates, Python has risen in popularity as rapidly as Tcl has fallen. Though the Perl community is still quite a bit larger than Python's, a visible tendency of the brightest Perl hackers to migrate to Python has been rather ominous for the former language -- especially as there is no migration at all in the opposite direction. ---- ''[RS]'': Is it still true that Tcl has "weak facilities for namespace control"? What do the others have that we don't? And ''upvar''? What's dangerous in proc foo {_x w} { upvar 1 $_x x ;# array passed by name upvar #0 $w w ;# global array named like a widget ...} [Cameron Laird] has since convinced me that ''upvar'' and ''uplevel'' *are* dangerous - just because they give us so much power that might be abused. Consider proc havoc {args} { foreach i [uplevel 1 info vars] { uplevel 1 set $i foo } } which indeed wreaks havoc to its caller. But besides the power of those constructs, we have the glory of being able to exclude such dangerous commands in a '''safe interpreter''' - both things that few if any other languages have out of the box... ---- [Category Advocacy]