Version 14 of What is the advantage of Tcl over Perl

Updated 2004-03-04 09:26:48

* The Tcl'ers Wiki

  • The comp.lang.tcl newsgroup
  • Tcl is simpler. Those without a C/Unix background generally find Tcl syntax far easier to learn and retain.
  • Tcl is smaller.
  • Tcl is easier to extend, embed, and customize.
  • Tcl source code traditionally is a model of lucidity. Perl source code traditionally is dense in magic.
  • Tcl/Tk is far more portable than Perl/Tk.
  • TCP networking is more succinct and less intimidating.
  • Tcl's exec, open and socket are gems of accessible and portable functionality, in comparison to the analogous Perl offerings.
  • Tcl's unified channel API makes life much easier, particularly on Windows.
  • As of spring 2001, Tcl's Unicode [L1 ] capabilities are considerably more mature.
  • As of spring 2001, Tcl's threading savvy (read "Tcl and threads") is considerably more mature.
  • Subjective stuff: some people find Tcl a better fit to their own sensibilities.
  • You can read your own code 6 months after you've forgotten how the program worked.

Also see "Is Tcl Different!", "Why Tcl is better than Perl" [L2 ], "How Tcl is special", ...

(Supply more references.)

Performance is rarely cited as a Tcl advantage. In fact, it's far more common to be asked about "Why Tcl is so much slower than Perl".

I don't use perl much any more. After I spent an hour chasing down a variable that was unexpectably global (the default when I last used perl) I decided that any language where all variables are global unless you specifically say otherwise was not a language I wanted to debug.

Just use "use strict;" which will ensure that you declare all variables as local.

No, use strict; simply means you have to declare all your variables but they can be global or local.

"use strict;" feels like "oops we did it the wrong way, but we'll fix it by making the wrong way optional". Does perl have other optional bad ways to do things? If you take up perl, you probably will get asked to try to repair something written by someone else who didn't "use strict;".

Peter Newman 5 March 2004: Perl is better at almost everything coding related than Tcl - EXCEPT Tk! The Tk syntax in Perl is horribly convoluted. Whereas in Tcl it's clean and simple. So:-

  • If the GUI part of your app. is the most important thing, use Tcl.
  • If there's no GUI, use Perl.

But there are other application specific things that could sway your decision. For example:-

  • If you're processing HTML, Perl's HTML::Tree module blows away anything than Tcl can offer.
  • If you're downloading/uploading files or doing anything HTTP, FTP, etc, it's 50/50. Both platforms offer good solutions.
  • If you're parsing text, Perl is the answer (because that, after all, is the thing that Perl was originally designed to do).
  • Tcl wins hands-down as far as DEPLOYMENT is concerned however. Starkits and Tclkits are just brilliant - and much easier to use than the conventional wrapping solutions available in both Perl and Tcl.
  • Also, the main Tcl deployment solutions (Starkits, Tclkits, Freewrap and Prowrap, etc) are FREE. You can wrap Perl console apps for free (with Perl2Exe). But Tk/GUI apps are gonna set you back USD150 (from memory). It's a fair and reasonable price. But if you're broke, Tcl is the answer.

But for a commercial application, the GUI is probably the most important thing. If it ain't clean and simple and easy and pleasant to use, users just won't use it. And producing such GUI's is MUCH easier in Tcl than Perl.

NEM HTML::Tree - what's so good about this? I haven't used it, but I was wondering whether it was more useful than say tdom's [dom parse -html] mode? Or the htmlparse library in tcllib?

With regards to doing "HTTP, FTP" etc, I'd say things lean more in Tcl's favour here - the event loop, unified channel api, and vfs. Cross-platform networking is a doddle.

Back to "parsing text" - lots of people use Tcl to do a lot of this. I understand the "Perl was originally designed for this" argument, but what are the differences in reality? Is it just Perl's terseness? Or are their some real extra features that Tcl could benefit from?

I feel I should say the diplomatic "but Perl has it's uses" right now, but I just can't think what those uses might be... built-in source obfuscation might be of some use in the commercial world, I guess. :)

[ Category Advocacy ]