LES begs to differ:
Questionable: I am pretty sure the Perl monks have their wikis too.
Lars H: But isn't the point here, rather than being that The Tcler's Wiki exists, that its contents are superior to what one might find in the Perl world?
Questionable: Perl has its comp.lang.perl newsgroup as well.
Lars H: Same rebuttal as previous argument.
Questionable: Those without a C/Unix background generally find any programming challenging enough. And will get terribly attached to whatever they learn first.
Lars H: Isn't this argument a bit "all real programmers have a C/Unix background, the rest don't matter"? Although the spread of Linux has probably made such a background more common, I'm not sure it is dominant among the potential users of Tcl.
Questionable: while it may be more difficult to extend Perl, finding extensions for it is a lot easier because it is a lot more popular.
Questionable: Tcl's exec is a constant source of hair loss. That's one of the main reasons {expand} had to be invented, and it still doesn't make things all that terribly easier. And I don't see any real advantage in the open command/function on either side.
Questionable: Tcl's threading? I've heard of it a few times, but I don't think I have seen it yet. I know I have seen a few Tcl experts complain that threading gets too little attention.
Questionable: if it's subjective, better leave it out. Perl mongers could just say the same about Perl and "sensibilities".
Questionable: bad and undocumented code is bad and undocumented code in any language. I can't remember the last time I wrote anything in Perl. Two years? But I still have my scripts here and I can read them quite easily. I can't read my recent Tcl programs so easily unless I document them very well. I am not saying that Perl is more readable than Tcl! What I really mean is that "readability" can be very subjective. Just like natural languages: some may find Spanish very easy. Others may find it very difficult.
Just playing a little Devil's advocate.
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;".
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:-
But there are other application specific things that could sway your decision. For example:-
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.
RLH - Perl has PAR now which allows you to wrap the Perl application into an EXE.
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 :)
SEH -- If the text parsing requires heavy use of regular expressions, I infinitely prefer Tcl, largely because you have the option of using curly braces for patterns; the backslashes in perl regexps of any complexity will drive you cross-eyed.
Also, as a matter of praxis, I never really understood regexps until I started using Tcl. Other regexp-using tools in their docs would give a few desultory examples then say "check the library code package for full details", but the code package would say "check the actual implementing tool for how this package is utilized." Tcl actually had a full page devoted solely to regexp syntax.
This may be less true now than back in the Dark Ages.
LES: Tcl has curly braces and Perl has single quotes. There. Solved.