No, this page is not for flame wars or anything. I use Tcl as well as Perl and Python.
Which language I choose for which task is decided by my feeling.
Sometimes I just feel like coding Perl, sometimes I feel like coding Tcl. There are no big differences to my knowledge that would make one language THE choice for a certain type of tasks, or am I wrong? - Moritz
It's my opinion that, in general, you are correct. However, some tasks may be more easily done in one language than another.
For instance, Perl and Python comes with different extensions and functions than Tcl. So to do equivalent things in Tcl, you either have to locate, download, and install an extension which you seek out to do the functionality, or you have to learn enough about the topic to write your own extension.
LV I suspect that the previous commenter means that Perl and Python come with more modules/extensions/procs/functions at the time one downloads the base source code or base binary distribution. The effort to organize within the Tcl community a response to this comment has come to be referred to as a Batteries Included distribution. So there are ways to get binary distributions of Tcl with more functionality. I've yet to see someone compare some of the Tcl BI distributions against Perl and Python to see whether they now are relatively comparable- if the same types of extensions are available . (RS adds: see especially ActiveTcl)
I think it's not which one comes with more extensions/packages, but which one has a package right now that you need.
For example I'm connecting a Flash frontend to our unix server and there's already a remoting package called AMF::Perl that exists. So, why not use Perl for this task?
If I want to deliver a nice win32 executable desktop app, theres no way I'm touching Perl.
--Ro
Ro, do none of PAR, IndigoStar, perlcc, and the ActiveState compilers work for you?
Never heard of em. The ubiquity of starkits in the tcltk world, and of freewrap is exactly the point I'm trying to make. The tcltk runtime is less than a meg. It's dead simple to wrap basic apps. In the perl world, I really don't think any that you just mentioned are as ubiquitous. --Ro
See also "What is the advantage of Tcl over Perl."
Why old axes have become dull: Two comparisons from around 1995 have been presented over and over again as supposedly current critique of tcl shortcomings: [L1 ] and [L2 ]
Kevin Kenny gives a rundown on past status and current development concerning core points of this critique on comp.lang.tcl [L3 ] ( thread:[L4 ] (reformatted here so the points are in bold and KBK's replies are in italics in an attempt to make things a bit clearer - DKF):
- Tcl has strings that are straight C strings, making length-dependent operations slow. List operations in Tcl are equally slow, because lists are strings.
- Untrue since 1997. The Tcl_Obj structure has a string length. The internal representation of a Tcl list is a C array.
- Tcl cannot deal with binary data because everything must be a null-terminated string.
- Untrue since 1999. When Unicode compliance was added, Tcl's basic string representation became UTF-8, with an added twist that the invalid UTF-8 byte sequence C0 80 is used to represent a null byte in binary data. Binary data can be held efficiently in byte arrays.
- Tcl cannot pass arrays by value or by reference, only by name.
- This is largely a question of style. array get and array set can indeed be used to pass by value. Passing any object (not just an array) by reference is accomplished using pass-by-name and upvar. That's just how you spell it in Tcl, and somewhat a matter of personal taste.
- AMG: See also: dict
- Tcl lacks an installation mechanism and set of standard paths for new packages.
- This comment predates the package command, added in 1996.
- Tcl stores numbers as strings, slowing its arithmetic.
- Tcl is a pure interpreter; Perl uses a bytecode engine.
- Tcl has been bytecoded since 1997.
- Perl comes with a full debugger, closely integrated with the language.
- The best Tcl debuggers have always been add-ons. The core developers have typically not been interested in adding this functionality, partly because we don't miss it much ourselves (there are so many other ways of introspecting a Tcl program's behaviour), and partly so as not to bite the hand that feeds us (sales of TclPro from Scriptics and TDK from ActiveState have funded considerable Tcl development). This could be seen as a valid complaint.
- Perl has namespaces that can export their symbols.
- Perl allows dynamic loading of object modules.
- Perl has anonymous subroutines. Tcl lacks them.
- True. I've wanted anonymous lambdas for some time; there are a lot of details that have to be hashed out. The presence of apply in 8.5 will help some, and "auto-{*} on the leading word" would help even more, but would need a major release to get in.
- Perl has a list that is numerically indexed, and Perl also has hashes.
- Perl has an extension mechanism (a C preprocessor that turns prototype-like definitions into interface code) that is more convenient than the binary API of Tcl.
- This is somewhat a matter of opinion. I happen to prefer TEA to Perl's mechanisms; then again, Tcl's interfacing has improved enormously in the last decade.
- Perl has references which allows arbitrarily complex data structures including structures that are self-referential.
- Indeed it does. There is some dispute as to whether this is a good thing. Many Tcl'ers believe that sort of thing is for a lower-level language. I'll concede this round to Perl.
- Perl can analyze a script for syntax errors without executing it.
- Tcl's dynamic nature, where virtually anything but the twelve syntax rules can be redefined at run time, makes this inordinately difficult to get right in the most general case. For less wizardly uses, the TDK checker (payware) and Frink (open source) do quite a creditable job. Admittedly, neither is "in the core". Tcl suffers a great deal from disparagement of extensions. I'll give Perl a slight edge on this point, but only a slight one.
- Perl has an object programming model.
- Tcl's problem isn't that it lacks an object programming model, but that it's agnostic about object programming. It's possible to do quite a creditable job of object programming even in pure Tcl using a script-level package such as Snit. Yes, we're currently debating "OO in the core," but that debate is primarily driven by politics and to a lesser extent by run-time performance, not by capability.
- Perl provides an interface to all the Posix (.1) routines.
- Pray be more specific. Tcl has an awful lot, but often it doesn't precisely mirror Posix. Intentionally. Tcl runs quite well on systems that do not have workable Posix libraries - such as Windows - without resorting to emulation layers. There are a couple of gaps - generally in Posix API's that do not port gracefully to other platforms - and those gaps are filled quite nicely with extensions. Of course, many Tcl detractors, and some enthusiasts, disparage extensions for various reasons, many of which I fail to comprehend.
In short, virtually all of the points in Mr Sherman's article have been addressed years ago. Circulating this article and presenting it as if it's the current state of affairs is little short of libelous.
DKF: With Tcl 8.6, we gain OO in the core. It's not the same sort of OO as Perl has. We also have full coroutines, which I think Perl 5 doesn't. (They might have a restricted form that only allows yielding in the main coroutine function. Perhaps. It looks very hacky to me, but that's Perl…)
Meanwhile, in Python-land: [L5 ]
- "Packaging is currently too hard in Python, and while there's effort to improve it, it's still largely focused on the problem of installing. The current approach is to just throw docs and specs at the building part"