- The Tcler's Wiki
- comp.lang.tcl
- 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 [1] 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.
- (file)event, trace and friends often solve requirements for functionality better than threads.
- Tcl is way ahead of Perl in VFS capabiltities; fuse provides an example of the potential consequences.
- As "Tcl's string handling has been written by paranoiacs", to quote DKF, Tcl is immune to many "format string vulnerabilities".
- Yerlp: this page has been here for years, without adequate emphasis on "The uniqueness of safe interps".
- Deployment of Tcl does not need a full installation. It can be delivered as starkit or starpack
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 [comp.lang.perl.* newsgroups, more properly] as well.Lars H: Same rebuttal as previous argument.RLH 20060404: c.l.tcl is a much friendlier group.
as few other explanations.Can anyone please add comments from Tcl usage?[Sometimes Perl is easier: its tainting and use are easier to explain to beginners than safe interpreters, and ...]KPV I disagree. I like the idea behind taint but I've found that beginners, who already find regular expressions confusing, are double confused by how you go about untainting data. Furthermore, the idiom for testing if a variable is tainted is completely baroque (with eval, join and kill, see perlfaq7) and confusing even to experienced users.
Also see "Is Tcl Different!", "Why Tcl is better than Perl" [2] (dead link 2006-04-06, archive copy at [3]), "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:-
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. It's the same.
regular expressions, I infinitely prefer Tcl, largely because you have the option of using curly braces for patternsRMSB: Sorry, but you don't seem to have o good grasp in Perl.In Perl, your can say: s/apples/oranges/ or s{apples}{oranges} or s!apples!oranges! or what pleases your eyes best. Just a tiny nitpick.Being the computer language enthusiast i am, though, i love both languages ( and many others ) for their unique personal ways of handling common programming tasks.SEH 20051206 -- Well, that's funny, because as a Perl beginner I've looked through a lot of tutorial and example code, and I've never seen the constructions you mention. I have however, seen lots of examples of Perl regular expressions with dozens of backslashes from here to the end of the line. If the constructions you mention are so handy, why aren't they used more? The Tcl regular expression functions are by contrast excellently documented, and there were plenty of good examples available for me to learn from whe I started. So is a language superior if it has a theoretically perfect tool for every job that few people nevertheless know about?RLH 2005-12-07: As far as I can tell he wasn't saying they were handy. He was merely pointing out that s/// is a quoting operator just like q// or qq// or qw// and that you can pick your own. So his statement is correct.VK: Perl's REs, when you get used to them, are easier to use, namely because those are part of language syntax. Examples:
Perl's flexible quoting scheme (the q, qq, qw, etc operators) is really nice, especially when dealing with things like quoted html strings.Another useful item in perl that tcl would do well to adopt is the /e flag on regexp substitutions - treat the replacement string as an expression and evaluate it and use the result as the replacement. This seems like a really natural thing for tcl to do since it's all about evaluating, but for some reason it's not there. (And it's not entirely straightforward to emulate).DKF: I've been thinking about this for ages (on and off, mostly off recently alas). The problem is picking a good way to substitute the match values into the script (or, equivalently, a good set of variable names for the script to use to access the matches). And also consideration of what to do if you prefer to get the indices into the string and not the matched values themselves (though I'm tempted to just ignore this bit). Lots of tricky design issues; get them right, and the implementation is dead simple. :^)Lars H: Anything wrong with a bind-style scheme (presumably using RE & and \1 etc. instead of %)? Writing
Perl does have lots of libraries.Most of them suck.Ok, that's a bit of bitterness and frustration coming through, but a lot of perl contributed code (i.e., CPAN) is badly documented, quirky, inextensible, and doesn't work to do really obvious (IMHO) things. For instance, say you want an application that issues several requests to different web servers without waiting for the results, does some local processing, and then waits for all the remote requests. In tcl this is maybe not trivial, but fairly straightforward given the event loop. In perl you could use POE - so long as you're willing to rewrite your entire application to be POE-centric, otherwise it just gets in the way. Or you could implement your own http client and event processor. It's great that you have the low-level tools to do such things (like the raw select call), but awful that you need to.Another great perl 'oops we did it the wrong way' is references. They're a great tool and make all sorts of things possible, and would have been totally unnecessary if the design was better in the first place. [Anon] Complete FUD! Perl's references are one of its main advantages over Tcl. And i'm a Tcl advocate!DKF: Tcl's http package makes doing the "issue several requests to different webservers without waiting" bit really easy, and it is a standard part of the language. To be frank, I didn't realize that that could be difficult. Guess I'm spoiled... ;^)
RLH Tcl has its 11 rules. That's all. I find that very nice. As long as Perl is syntactically correct, anything goes. While you can argue that as a strength (and it could be), I would go with simple and consistent.
RLH 2005-12-05: Consistency! I currently use Perl(5) for a lot of things. I am looking at some of the things being talked about on the Perl(6) group and I shudder. It will be almost like when MS created VB.NET and expected VB6 people to migrate. Of course, it is still early and maybe too early to tell. Tcl adds things, but it isn't radically redesigned.
tro 2006-04-04: I'm a wannabe TCL-convert but although I love the concept (Starkits are the big lure), I always find myself going back to Perl. Maybe it's because I have collected a number of TCL source code examples that generate too many errors. (Note: that's how I learn, I search for code examples and pick them apart. Very inefficient but it works for me.) I'm especially irritated with BWidget. It seems like no two TCL scripts ever use the same version. And I can't get eTCL, which looks lovely, to run any of the scripts I would like to use on my Axim. So, I always end up back with Perl for personal or need it fast stuff.I know - a perfect scripting lanuguage doesn't exist. (I've tried Python and Ruby, too. Even Rexx back in the day...) I've been working in a Unix, VMS and Windows environment for the last five years and would love to have something that could work everywhere. I keep thinking that TCL should be that something. Not that much works in VMS. :-)Well, thanks for letting me vent a little. But I'm serious about that version thing. In Perl, all I need to worry about are the majors 5.0, 5.6 and 5.8 for most of the features I use. TCL has too many little pieces.
RLH 20060404: You should use ActiveTcl by ActiveState. It is a batteries included distro that I have been very happy with. I use it on Windows, HP/UX and MacOS X. It comes with pretty much everything I need and I actually like that way it keeps its packages (although it desperately needs a CPAN). I am also a Perl programmer but I am mostly using Perl for quick web things now (this is another area that I wish got more attension in Tcl). Tcl 8.5, on the horizon, is bringing some nice things to the table without "redefining" what Tcl is. I look at where Perl is going with Perl6 and I shudder.
RS 2006-04-05: .. and regarding eTcl, could you report what does not work for you, best on the eTcl page? In my experience it's the most powerful Tcl/Tk port to PocketPC I've ever seen.tro, CL will happily help you with Tcl issues under VMS, if you want to pursue those.
TRO Responses like these are why I keep coming back to this wiki and TCL. Not that I don't love the rowdy kids hanging out on the Perl lists and newsgroups but I usually feel like their mother. :-)Since I jumped in and made comments, guess that means I will need to document my issues and I will when I have more time. FWIW, the TKM3 ran pretty well on my Axim but again, not perfectly. And the VMS thing is wishful thinking unless I want to compile it myself, which I don't. The company I work for keeps the system pretty well locked down. And of course, DCL is all you could ever need, right?I do have ActiveTcl 8.4.12 installed here at work but I don't use it as much as I use the standalone tclkit executable (which appears to be 8.4.9) and trying things like eTCL. ...terry
AK: The basekits coming with ActiveTcl (bin/base-*) are in essence tclkit and tclkitsh. You may wish to try them as standalone executables.
came here looking for signal handling, something that's built into perl ... what did i find? How can a command-line Tcl application catch and gracefully process signals such as control-C? It can't i'd say that's not really an advantage
RFox: I have to say I hate pages like this. It's like a page that might be titled: "What is the value of a resistor over a capacitor?". Each has its place and application. Each has its warts.
- Tcl is simpler. Those without a C/Unix background generally find Tcl syntax far easier to learn and retain.
- Tcl is easier to extend, embed, and customize.
- Tcl's exec, open and socket are gems of accessible and portable functionality, in comparison to the analogous Perl offerings.
- 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.
- Threads are not usable.
as few other explanations.Can anyone please add comments from Tcl usage?[Sometimes Perl is easier: its tainting and use are easier to explain to beginners than safe interpreters, and ...]KPV I disagree. I like the idea behind taint but I've found that beginners, who already find regular expressions confusing, are double confused by how you go about untainting data. Furthermore, the idiom for testing if a variable is tainted is completely baroque (with eval, join and kill, see perlfaq7) and confusing even to experienced users.Also see "Is Tcl Different!", "Why Tcl is better than Perl" [2] (dead link 2006-04-06, archive copy at [3]), "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.
- 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 Tk/GUI console apps for free. But Perl apps with (Perl2Exe) are gonna set you back USD150 (from memory). It's a fair and reasonable price. But if you're broke, Tcl is the answer.
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. It's the same.
regular expressions, I infinitely prefer Tcl, largely because you have the option of using curly braces for patternsRMSB: Sorry, but you don't seem to have o good grasp in Perl.In Perl, your can say: s/apples/oranges/ or s{apples}{oranges} or s!apples!oranges! or what pleases your eyes best. Just a tiny nitpick.Being the computer language enthusiast i am, though, i love both languages ( and many others ) for their unique personal ways of handling common programming tasks.SEH 20051206 -- Well, that's funny, because as a Perl beginner I've looked through a lot of tutorial and example code, and I've never seen the constructions you mention. I have however, seen lots of examples of Perl regular expressions with dozens of backslashes from here to the end of the line. If the constructions you mention are so handy, why aren't they used more? The Tcl regular expression functions are by contrast excellently documented, and there were plenty of good examples available for me to learn from whe I started. So is a language superior if it has a theoretically perfect tool for every job that few people nevertheless know about?RLH 2005-12-07: As far as I can tell he wasn't saying they were handy. He was merely pointing out that s/// is a quoting operator just like q// or qq// or qw// and that you can pick your own. So his statement is correct.VK: Perl's REs, when you get used to them, are easier to use, namely because those are part of language syntax. Examples:
$string = 'A=3 qwerty=asdf fluffy=4'; # suppose we have word=value pairs
@words = $string=~/(\w+)=/g; # @words will get all words from $string; can be ever shorter?
%words = $string=~/(\w+)=(\S+)/g; # associative array will have pairs so $words{fluffy} now 4Perl's flexible quoting scheme (the q, qq, qw, etc operators) is really nice, especially when dealing with things like quoted html strings.Another useful item in perl that tcl would do well to adopt is the /e flag on regexp substitutions - treat the replacement string as an expression and evaluate it and use the result as the replacement. This seems like a really natural thing for tcl to do since it's all about evaluating, but for some reason it's not there. (And it's not entirely straightforward to emulate).DKF: I've been thinking about this for ages (on and off, mostly off recently alas). The problem is picking a good way to substitute the match values into the script (or, equivalently, a good set of variable names for the script to use to access the matches). And also consideration of what to do if you prefer to get the indices into the string and not the matched values themselves (though I'm tempted to just ignore this bit). Lots of tricky design issues; get them right, and the implementation is dead simple. :^)Lars H: Anything wrong with a bind-style scheme (presumably using RE & and \1 etc. instead of %)? Writing
regsub -command {\w+(\.\w+)+} $text {string tolower &} resultfeels rather natural. OTOH it occurs to me that treating the replacement string as something more subst-like could often be much more convenient. I suppose this is where substitution gets tricky -- one wants matches to be quoted when inserted into parts subject to command substitution, but not quoted when inserted into raw text.DKF: That's one of the issues which has stopped me from coming up with a solution. I know several ways how to do it, but not which is the best one.Perl does have lots of libraries.Most of them suck.Ok, that's a bit of bitterness and frustration coming through, but a lot of perl contributed code (i.e., CPAN) is badly documented, quirky, inextensible, and doesn't work to do really obvious (IMHO) things. For instance, say you want an application that issues several requests to different web servers without waiting for the results, does some local processing, and then waits for all the remote requests. In tcl this is maybe not trivial, but fairly straightforward given the event loop. In perl you could use POE - so long as you're willing to rewrite your entire application to be POE-centric, otherwise it just gets in the way. Or you could implement your own http client and event processor. It's great that you have the low-level tools to do such things (like the raw select call), but awful that you need to.Another great perl 'oops we did it the wrong way' is references. They're a great tool and make all sorts of things possible, and would have been totally unnecessary if the design was better in the first place. [Anon] Complete FUD! Perl's references are one of its main advantages over Tcl. And i'm a Tcl advocate!DKF: Tcl's http package makes doing the "issue several requests to different webservers without waiting" bit really easy, and it is a standard part of the language. To be frank, I didn't realize that that could be difficult. Guess I'm spoiled... ;^)
RLH Tcl has its 11 rules. That's all. I find that very nice. As long as Perl is syntactically correct, anything goes. While you can argue that as a strength (and it could be), I would go with simple and consistent.
RLH 2005-12-05: Consistency! I currently use Perl(5) for a lot of things. I am looking at some of the things being talked about on the Perl(6) group and I shudder. It will be almost like when MS created VB.NET and expected VB6 people to migrate. Of course, it is still early and maybe too early to tell. Tcl adds things, but it isn't radically redesigned.
tro 2006-04-04: I'm a wannabe TCL-convert but although I love the concept (Starkits are the big lure), I always find myself going back to Perl. Maybe it's because I have collected a number of TCL source code examples that generate too many errors. (Note: that's how I learn, I search for code examples and pick them apart. Very inefficient but it works for me.) I'm especially irritated with BWidget. It seems like no two TCL scripts ever use the same version. And I can't get eTCL, which looks lovely, to run any of the scripts I would like to use on my Axim. So, I always end up back with Perl for personal or need it fast stuff.I know - a perfect scripting lanuguage doesn't exist. (I've tried Python and Ruby, too. Even Rexx back in the day...) I've been working in a Unix, VMS and Windows environment for the last five years and would love to have something that could work everywhere. I keep thinking that TCL should be that something. Not that much works in VMS. :-)Well, thanks for letting me vent a little. But I'm serious about that version thing. In Perl, all I need to worry about are the majors 5.0, 5.6 and 5.8 for most of the features I use. TCL has too many little pieces.
RLH 20060404: You should use ActiveTcl by ActiveState. It is a batteries included distro that I have been very happy with. I use it on Windows, HP/UX and MacOS X. It comes with pretty much everything I need and I actually like that way it keeps its packages (although it desperately needs a CPAN). I am also a Perl programmer but I am mostly using Perl for quick web things now (this is another area that I wish got more attension in Tcl). Tcl 8.5, on the horizon, is bringing some nice things to the table without "redefining" what Tcl is. I look at where Perl is going with Perl6 and I shudder.
RS 2006-04-05: .. and regarding eTcl, could you report what does not work for you, best on the eTcl page? In my experience it's the most powerful Tcl/Tk port to PocketPC I've ever seen.tro, CL will happily help you with Tcl issues under VMS, if you want to pursue those.
TRO Responses like these are why I keep coming back to this wiki and TCL. Not that I don't love the rowdy kids hanging out on the Perl lists and newsgroups but I usually feel like their mother. :-)Since I jumped in and made comments, guess that means I will need to document my issues and I will when I have more time. FWIW, the TKM3 ran pretty well on my Axim but again, not perfectly. And the VMS thing is wishful thinking unless I want to compile it myself, which I don't. The company I work for keeps the system pretty well locked down. And of course, DCL is all you could ever need, right?I do have ActiveTcl 8.4.12 installed here at work but I don't use it as much as I use the standalone tclkit executable (which appears to be 8.4.9) and trying things like eTCL. ...terry
AK: The basekits coming with ActiveTcl (bin/base-*) are in essence tclkit and tclkitsh. You may wish to try them as standalone executables.
came here looking for signal handling, something that's built into perl ... what did i find? How can a command-line Tcl application catch and gracefully process signals such as control-C? It can't i'd say that's not really an advantage
RFox: I have to say I hate pages like this. It's like a page that might be titled: "What is the value of a resistor over a capacitor?". Each has its place and application. Each has its warts.
