- an enthusiastic community [1]
- friendly discussion and help on comp.lang.tcl
- many (?) people working on the Tcl/Tk core
- active technical discussions on the chat [2]
- a wiki with lots and lots of gems
- a license which supports sharing and reuse
- copy on write, everything is a string, file events
- Tk, Expect, and more
- an implementation which has established a record through the years as a model of high-quality coding
- a very clever, subtle initial design, perhaps as important for what it left out as what it put in.
- a growing library of useful tools, known as Tcllib, with a pendant in Tk, called, unsurprisingly, Tklib, not to mention toolsets like BWidget
- deployment options that are unsurpassed by any other language, Tclpro, Freewrap and Tclkit, the latter especially as it depends on a virtual file system and makes for tiny single-file distributions
- easy extendability with a well-documented API
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
- make your own oo, no problem. (for real)
- switch -regexp, armed with our favorite non-typed language, they most convenient construct ever.
- foreach $fields [join $listlist] { code for every row, auto initiated }
- [lsearch -index 2 [lsort -dictionary $fname_lname_phones] 867-5309] oh, the brevity
- upvar, uplevel, be all places at the same time.
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.
