* [The Tcler's 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], and generally more current. * 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] [http://wiki.tcl.tk/unicode] 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" [http://www.tcl.tk/advocacy/perl.html], "[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;". I get the same feeling everytime I use the "-nocomplain" option in tcl. ---- 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 its 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. :) ---- [schlenk] HTML::Tree seems to do not much more than tcllib htmlparse with the 2tree method applied. Build a html tree from html. Maybe it is faster, but as NEM mentioned tDOM, that is probably even faster when building DOM trees for html. One example where i found Tcl superior to perl was building a pipe server spawning worker processes. The event loop and Tcls event system made it work great, i tried for some days in perl first, but it wasn't half as elegant and portable or maintanable. Parsing Text is a thing perl does well, but when it comes to unicode and encodings perl is not as nice. It works with the appropriate modules, but it's kind of twisted to get things right. For any project with more than one programmer working on it, perl needs much stricter coding guidlines to be somewhat readable. It's hard to accidentally obfuscate your Tcl code, but that is something which is unfortunately common with Perl. ---- Peter Newman 5 March 2004: I guess the point I was trying to make was that on this Wiki there are a number of pages comparing Tcl and Perl. And the overall tone of these pages seems to be one of trashing Perl. And saying Tcl is better. It isn't. Tcl and Perl are both good platforms. And they both have there strengths and weaknesses. I use both. But the one I use for a particular application depends on the application. Some things are better/easier done in Tcl. And some things are better/easier done in Perl. There's no doubt in my mind that a console mode app. that parses text is easier done in Perl. It's hard to put a finger on it, but somehow, Perl's just got more horsepower. However, you can do these apps in Tcl too. For GUI apps however, Tcl is the clear winner. Note that on this Wiki, the majority of programs are Tcl/Tk and GUI related. Most scripts seem to have or involve a GUI component. But Perl scripts (on Perl web-sites,) are generally non-GUI. So in practice, most text-thrashing programs get written in Perl - and most GUI related programs get written in Tcl. And that, in my opinion, reflects the relative strengths of those two tools in these areas. But there are areas like HTTP/FTP and HTML-parsing for example, where neither side is the clear winner. Both sides have perfectly good solutions. ---- If you're talking about perl programs on the console which you happily throw away once you have their results, I agree :) ---- [[ [Category Advocacy] ]]