Differences between version 13 and predecessor to the previous major change of TCL.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 13 | Last edited on Friday, June 17, 2005 12:26:44 am | by AristotlePagaltzis | Revert |
| Older page: | version 12 | Last edited on Thursday, June 16, 2005 7:16:24 pm | by SidSwami | Revert |
@@ -1,11 +1,13 @@
An [Acronym] for __T__ool __C__ommand __L__anguage.
It is a scripting language embedded in many applications, much like [Elisp] is used in [Emacs] and VisualBasic is in many MicrosoftWindows applications. (This does not mean these languages have anything in common; actually they're about as far apart from each other as imaginably possible.)
-Tcl is available on all [Unix]-like platforms, as well as on MicrosoftWindows. It is almost always combined with the [Tk] ToolKit. This makes it a good choice for portable [GUI] scripting. There is also a standalone interpreter.
+Tcl is available on all [Unix]-like platforms, as well as on MicrosoftWindows. It is almost always combined with the [Tk] ToolKit. This makes it a good choice for portable [GUI] scripting. There is also a less popular
standalone interpreter.
-The language itself is limited and does not accomodate the needs of large, complex codebases. It
was designed for easy extensibility and embeddability,
intended to serve as a universal scripting interface to compiled libraries and applications containing the
complexity and providing
a simple [API]
. The [Tk] ToolKit is
a significant success for this
model. In practice, more capable
dynamic languages like [Perl], [Python] and [Ruby] that
are designed to carry the complexity of a large codebase without the need for foreign libraries
proved more popular at the one end, while fully scriptable applications never caught on at the other end. With [Tk]'s popularity long since dwindling, giving way to [GTK] and [Qt], so does the prominence of Tcl. Most people would consider it obsolete, though as with any technology (particularly in the OpenSource world), it has found a small following of supporters and enthusiasts who continue to evolve it. There is also still a moderate but significant amount of legacy TclTk code around.
+Tcl
was intended to serve as a a really simple,
universal scripting interface to compiled libraries and applications. The
complexity of large codebases was supposed to be carried inside these libraries
and applications, with their Tcl bindings serving more as
a glue layer for rapid adaptation and recombination
. Tcl itself was not orginally meant to be used as a standalone language. To that end, the biggest, foremost concerns in its design were extensibility and embeddability rather than the needs of large, complex codebases. The language is limited; variables can only be accessed by by name, not by value or by reference. Complex nested data structures were impossible to create until fairly recently. Since people kept using Tcl as a stand-alone language, support for nested lists was added to accomodate them, though manipulating such structures remains painful.
+
+
The [Tk] ToolKit was
a significant success for the original Tcl
model, but no others have followed
. In practice, dynamic languages like [Perl], [Python] and [Ruby] which
are designed to carry the complexity of a large codebase on their own
proved more popular at the one end, while fully scriptable applications never caught on at the other end. With [Tk]'s popularity long since dwindling, giving way to [GTK] and [Qt], so does the prominence of Tcl. Most people would consider it obsolete, though as with any technology (particularly in the OpenSource world), it has found a small following of supporters and enthusiasts who continue to evolve it. There is also still a moderate but significant amount of legacy TclTk code around.
See also:
* The Tcl community is working on the official [Tcl Tutorial | http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html]
* [Tcl Developer Xchange | http://www.tcl.tk/]
