Version 18 of Tcl vs Perl vs Python

Updated 2006-12-26 20:17:57 by ukl

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 comperable- 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 ]:

  1. Tcl's strings are straight C strings, making length-dependent
     operations slow. Tcl's list operations 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 an array.

  2. 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 represetation 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.

  3. 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.

  4. Tcl lacks an installation mechanism and set of standard paths
     for new packages.
         This comment predates the [package] command, added in 1996.

  5. Tcl stores numbers as strings, slowing its arithmetic.
         Not since 1997.

  6. Tcl is a pure interpreter; Perl uses a bytecode engine.
         Tcl has been bytecoded since 1997.

  7. 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.

  8. Perl has namespaces that can export their sumbols.
         So does Tcl.  Since 1997.

  9. Perl allows dynamic loading of object modules.
         So does Tcl.  Since 1996.

  10. 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.

  11. Perl's list is numerically indexed, and Perl also has hashes.
         Ditto Tcl, since 1999.

  12. Perl's extension mechanism (a C preprocessor that turns prototype-
      like definitions into interface code) is more convenient than
      Tcl's binary API.
          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.

  13. 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.

  14. 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.

  15. 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.

  16. 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 libellous.


Category Advocacy