Tcl, or the "Tool Command Language"*, is a powerfully simple, open source-licensed programming language. Tcl provides basic language features such as variables, procedures, and control structures. It runs on almost any modern OS, such as Unix (Linux and non-Linux), MacOS, Windows 95/98 (in Tcl's older forms)/NT/2000/XP/Vista/..., PDA systems, and many more. But the key feature of Tcl is its extensibility.
Tcl was originally developed as a reusable command language for experimental computer aided design (CAD) tools. The interpreter was implemented as a C library that could be linked into any application. It is very easy to add new functions to the Tcl interpreter, so it is an ideal reusable "macro language" that can be integrated into many applications. (See Tcl Chronology for more history.)
But Tcl is a programming language in its own right. It can be roughly described as a cross-breed between
- LISP/Scheme
- but with fewer parens,
- C
- but not as low-level and numerocentric, and
- command line shells
- with more powerful structuring and predictable handling of strange data.
(See Tcl heritage for more ancestry.)
In addition to the basic features:
- string handling
- arithmetic — via expr (infix notation) or individual +, -, *, etc. commands (prefix notation).
- file system access — both to file contents (open, read, puts, etc.) and files as units (file subcommands, such as delete, rename, attributes, ...)
Tcl also provides:
- regular expressions
- binary data handling
- lists (a.k.a. vectors), arrays, and dictionaries (a.k.a. hashmaps)
- sophisticated TCP/IP networking, (see socket)
- event-driven programming (see fileevent, after, vwait)
- extensibility (all tcl commands are even able to be rewritten in tcl)
- integration with C (see critcl)
- unicode support.
- direct access to the Tk GUI toolkit (see What is Tk)
- OO (as of 8.6a2)
- ...
within a radically simple, regular and powerful syntactic frame.
Tcl programs are sometimes called "scripts" because the programs do not need to be compiled into a binary form before running them, but nowadays the Tcl performs JIT compilation transparently, so Tcl does not suffer from the performance penalty associated with traditional interpreters.
Tcl still enjoys the advantage of being a dynamic language, where, for example, commands can be created, redefined, and destroyed at execution time.
The related "Beginning Tcl" page starts you off with some basic information about Tcl, while "Beginning Tk" starts discussing graphical user interfaces (GUIs). You can very easily build a GUI for a Tcl application, or for a compiled program. You can even use other Tcl extensions like 'Expect' to control command line programs from a GUI.
Tcl has a rich set of extensions, so you can write almost any kind of program as a Tcl script. There are extensions for CGI and HTTP (internet) applications, graph plotting applications, and database access. There are even object-oriented extensions for the Tcl language. Many lists of extensions exist - see the Dirty Dozen for pointers.
You might want to know "On What Platforms Does Tcl Run?" or even "How do you say 'Tcl'?" Helpful people will fill in the blanks on the appropriate page.
- Alternatively, Tcl: The cool language -- RS
- Yet another alternative from RS: "Tcl is a rich multi-purpose C library with a mighty powerful configuration language" - "Tcl: Terrific C library"
- Tcl: It's not big and it's not clever. We just happen to think that this is a good thing -- dkf
- Tcl: Java or C/CPP 30 years from now.
- Tcl: What all development environments want to be when they grow up. sdw
Ask Google: http://www.google.com/search?q=define%3Atcl
Tcler's chat in the Tcl Chatroom - Arts and crafts of Tcl-Tk programming
slebetman: Does tcl really do JIT? When was it/will it be introduced? 8.5? 8.6?
NEM: No. Certainly not JIT in the sense of compiling to native code. It compiles to byte-code on-demand, which could be seen as "just in time", but JIT usually means native.
DKF: We've talked (usually at conferences after a few beers) about doing JIT, and the key problem is that it takes quite a lot of development effort to do and would (potentially, depending on details) need to be re-implemented for every architecture that Tcl supports. On the other hand, doing just x86 would handle a very large fraction of what's actually deployed...