While the Things holding Tcl back may raise valid points, this page was created to make sure the optimistic side of things is not left behind.
Tcl has been progressing over the years for several reasons:
While I raised the concern of oo, db etc on the other page, let me be the first to enthusiastically say I love TCL! Written well, its extremely flexible, quickly developed , and ultimately legible post implementation, unlike other scripting languages you might be aware of. ;)
My thanks to the TCT for continuing to run through the versions, adding great features along the way (regexp package improvements!) and not letting this great scripting language die.
DKF: Note that when it comes to OO, the right phrase is "watch this space". DB access is trickier (largely because of the complexity of database access library availability/licensing) but becomes easier with an OO core to support it.
RLH 2005-07-05: I really believe one of the things that Perl got right, and when I say right I mean spot on, is the DBI. Tcl should implement a similar system so that driver authors can write to one clean low level spec.
stevel is surprised that no one has mentioned Starkits
Twylite This is the "good" side of my comments under Things holding Tcl back.
What is good about Tcl? Let me start with an anecdote:
Before introducing Tcl to my company I evaluated many other languages including C (with WxWidgets, Qt, GTk and others), Java, Python, Perl and others. We were looking for an environment that would allow us to develop small utilities and larger systems quickly and easily. Key requirements were integration with C libraries, cross-platform support, and high developer productivity. Despite having expertise in C and Java, we went with Tcl.
1. It is easy to learn. Despite its quirks it has a small and consistent set of syntactic rules, and a managable command set. I have had developers with no prior Tcl experience writing code within two days of first exposure to the language, and others maintaining code within one day.
2. Tcl has a compact runtime. This is actually really important to a lot of people, because not everyone has broadband. I can mail a 1.2Mb Tcl-based diagnostic utility to a client. The same utility as a 3.1Mb Python application is pushing the limits of convenience. Expecting a client to download and install a 15Mb Java Runtime is Right Out. A compact runtime also makes Tcl suitable for embedded platforms. Keeping the Tcl core as small as possible is a Good Thing.
3. It is easily extensible and there are plenty of libraries to choose from. In the corporate world, Java is delivering a KO to C++ for three reasons: hype, garbage collection, and an extensive and well-documented library. But the library has also kept Java from capturing a share of the market for utilities, because the JRE is large and installing a separate runtime is non-obvious for end users.Having function libraries is important for fast and reliable development. Having them outside the core is important for fast and simple deployment.
4. Tcl is cross platform. Tk is beyond doubt the most portable GUI toolkit (LINK). Tcl is supported on the same platforms as Java and other major scripting languages, and several besides. With the increasing use of Linux and other *nix operating systems in office and home environments, portability is becoming more important.
SYStems I would say that the single most important characteristic that is pushing Tcl forward is uniformity, Tcl have only one statement type, the command, and that's thanks to it's uniform type system where everything thing is a string, features that are in other languages provided as keywords are just commands in Tcl, for example in C the while loop statement can't be a functions that takes two arguments, one boolean expression another a C script, etc ... , but since C can't have C scripts type (i.e. input), the while had to be a statement type built-in the language specs and specified in the compiler. C have many statement types, if statement, loop statement, etc ... , on the other hand Tcl only have one statement type the command. The C type system can not represent the input required by all types of statement. Understanding, thinking and loving this stuff can only push the Tcl community forward
IL This page does not have enough listed here so I will add somethings I love
I will also add that the super-easy embeddability of Tcl into other programs is a huge benefit. Similarly, the ease of writing an extension can catch one off-guard in an "is that all?" way. That a C program or extension can access the inner workings of Tcl is impressive and useful--one small example is the C functions to use Tcl's VFS layer, so that the C program can access files within a starkit.
And, as always, someone has put enough thinking into this that it's sensible to use..
JMRA tclkit is a killer app, I don't understand why so few people are using it.
LV I suspect there are a number of reasons - but this page isn't the place to discuss them. Let's see what turns up on Why do you NOT use a tclkit.