See http://www.perl.org/ for a lot of information regarding Perl. Larry Wall wrote Perl many years ago (see http://www.perl.org/press/history.html for a history of Perl). Perl is a totally separate scripting language from Tcl. In this day of convergence of technologies, it should not be surprising to people that there has been, for a number of years, ''cross pollination'' of ideas between the two languages. Malcolm Beattie wrote some perl modules quite a long time ago that trying to interface to tcl and to [tk]. Also, Dov Grobgeld and Guenther Schreiner did likewise. Later Nick Ing-Simmons went to the ''extreme'' effort of creating a series of scripts to separate tk from tcl, and then created a Perl module that talked to the now interpreter-less graphical library. This module, aka pTk or [Perl/Tk], is the most frequently used one of the four that I have seen announced. pTk installs without any Tcl libraries - the interface is done between a modified version of the Tk C API. There has been a desire by many language developers to see these modifications rolled back into the Tk source tree. The idea is that if the default [Tk] is agnostic about its scripting language, then all scripting languages could have ''equal footing'' in terms of their bindings. Not only that, but non-scripting languages, such as C, C++, etc. would have an easier time making use of this powerful extension. In the past, some Tcl/Tk developers expressed concern that to do this would relegate Tcl even farther to the background of attention. Information about perl can be found at the site http://www.perl.com/ . Several other Wiki pages [http://mini.net/tcl/perl*] address relations between Perl and Tcl. ---- Perhaps some people would list some of the features of Perl, either as a strict language, or from a module/package/extension point of view, that they wish would come to Tcl. ---- Since you ask. Sometimes I yearn for perl's terseness while other times I revel in tcl simplicity, but these are just syntactic sugar really. What I really want in tcl is: * built in debugger: tkcon is excellent and blows away the perl console hands down and idebug is a good start, but not being able to single step is a real shortcoming. I've tried three times to get Tclpro to work, the last was just last week, but I never got it to work on non-trivial programs. Plus, it blew away all my tcl path variables so I junked it. * CPAN: having one place to look for extensions, plus a very uniform way of installing them is very nice. Tcl with the ActiveState distribution is getting better but it's still not as slick as CPAN. [Arjen Markus] I think a built-in debugger is actually easy to create in pure Tcl. Just source a source file and in the process add debug commands that will pause the proc, or continue until a breakpoint comes along, should not be too difficult! (This would slow down the execution ...) ---- [RS]: See for instance [a minimal debugger] on how to administer breakpoints in a few lines of Tcl. [Arjen Markus] Like I said. [Expect] comes with a similar debugger. ---- It's natural to compare Perl and Tcl. When a developer's starting a new project, which will serve him or her best? One of the propositions that often appears at this point is that, "Perl is best at string-handling." I don't subscribe to this. First, I acknowledge that many people believe the claim. There's some sort of validity to it, just in its popularity. Second, programmers should realize that Perl and Tcl are more alike than different, in that both make string handling FAR easier than it is in C, C++, or [Java]. Perl does make interestingly pervasive use of [regular expressions]. This is characteristic of Perl, it's quite interesting, and, in the hands of an expert, it can be rather breath-taking. There are also a couple of distinct reasons to question how much it benefits developers: * First, REs are overdone. That's simply a fact. I encounter quite a bit of code that REs obfuscate, rather than streamline. Among the alternatives are simple procedural "un-rollings", and elementary string manipulations through facilities such as Tcl's [string] command. * Also, Perl's REs have specific problems that Larry Wall describes in [[find reference]]. My summary, then, is that I feel perfectly comfortable performing string manipulations in either Perl or Tcl (or [Python], for that matter, which has yet a different style), but I know I'll use different idioms for the two (or three). Perl often is more concise. I have a personal belief that idiomatic Tcl string-handling tends to be more readable. ---- Every once in the while I consider rewriting my text markup processor (AFT -- http://www.maplefish.com/todd/aft.html) in Tcl or Python. It was originally written in Awk and I rewrote it several times in Perl since 1996. Each time I try a rewrite in something other than Perl it seems pointless. Perl is perfect for what it does. It's my own personal prejudice, but Perl just seems more natural for text munging. Tcl is too ''chunky'' and Python feels too ''Pascal'' like for the task. Maybe its the pervasive [regular expressions] or the Awk-like implication that you '''will be''' working with munging text files. My brain works this way: * ''Perl'' - for text munging in short lived processes. * ''Python'' - for algorithmic programs meant to be readable. (compare w/ Pascal or Java; [CL] frequently calls Python the single most widely applicable language) * ''Tcl'' - for everything else ;-) ''guis, daemons, glue, lego-like toys'' -- [Todd Coram] ---- This is an extremely insightful commentary(above) IMO. Recently I have seen how the event loop really lends itself to *nixish daemon type processes for little things like honeypots, user process and command history monitoring, and other clandestine but basically sound processes. I have to wonder though about the python refernce for algorithms. Is it only because it's OO that he feels this way? Using python procedurally doesn't improve on anything(again IMO). -- [anonymous coward] ---- Perl has references, which are like pointers in C. Tcl doesn't have references, only names. In perl, when the reference count of a data item becomes zero, the data item is garbage collected. In tcl, because there are no references, you have to write your own garbage collection code. For example, assume you have a tcl array whose values are objects (itcl objects, for example). When you replace the object associated with some index with a different object, how do you know if the object previously associated with that index should be destroyed? If the only "reference" to the object is from that index in the array, then the object should be destroyed when the it is replaced. Otherwise, it shouldn't. If you fail to destroy an object which is no longer referenced, then you have a memory leak in your program. If you destroy an object which is referred to from another place in your program, then you have a potential major bug. An automatic garbage collection mechanism would solve this problem for you. Clarification: when I say '''memory leak''', I don't mean that '''Tcl''' is leaking memory. As far as I know, Tcl has no memory leaks. I mean that your '''program''' is leaking memory. In the scenario I described, you have created many objects (using some OOP extension to Tcl) but have lost track of their handles. They are inaccessible because you have lost their handles, but the memory associated with them has not been recycled since you haven't destroyed them. If that continues, you will eventually run out of memory. -- [John Wiersba] ---- I learned Perl first. Wrote an application I can no longer read, and then tried to fix someone else's code. That's why I became a Tcl advocate. [Clif Flynt] I had exactly the same experience as Clif. I felt ''encouraged'' by the Perl community at the time (1997) to make free use of Perl's idiotic pre-defined default variables (with cute names like $' $` $, $.), and could not maintain any program over 20 lines long that made use of them!! '''-PSE''' ---- ''What's wrong with Perl'' [http://www.garshol.priv.no/download/text/perl.html#id3.3.] gives some criticism of Perl. In particular the difficulties there seems to be with making lists of lists are interesting. ---- [RS]: If you want to bring some Perl brevity (and mystic) to Tcl, you can start from here: proc <> {} {expr [uplevel 1 gets stdin _]+1} proc print args { if {![llength $args]} { set fd stdout; set s $::_ } elseif {[llength $args]==1} { set fd stdout; set s [lindex $args 0] } else { set fd [lindex $args 0] set s [join [lrange $args 1 end]] } puts $fd $s } ;# dkf while {[<>]} {print} dkf Here's a version that gets a bit closer in some ways, though Perl fanatics would hate it. proc print {{fd } args} { if {[string match <*> $fd]} { set fd [string range $fd 1 end-1] if {![llength $args]} { set args [list $::_] } } else { set args [linsert $args 0 $fd] set fd stdout } puts $fd [join $args] } The real problem is that perl's filehandles are completely distinct from the strings it can output. [[CL wants to sharpen the expression of that last observation. He thinks it is something like this: Perl filehandles are distinguished syntactically, so it is feasible for the Perl parser to disambiguate different forms in which such a filehandle can appear (or be implicit).]] ---- There's a bug in your code up there, in that the <> procedure uses [[ [uplevel] 1]] on the code that sets the $_ variable, while the print procedure just accesses the variable at the global scope. I'm not sure which is wrong, though. - [RS]: Truly global appears more perlish to me, so make that proc <> {} {expr [gets stdin ::_]+1} The bug went unnoticed by sloppy testing, just one call stack level deep, where ''uplevel 1'' happens to point to the global namespace... ---- [glennj]: If you really want a perl-like print command, don't forget to use the "-nonewline" option to puts... Also, a c.l.t article [http://groups.google.com/groups?hl=en&selm=slrnao435j.9gb.xx087%40freenet9.carleton.ca] asking how to mimic the perl ''select'' command. ... this is starting to turn into a [Playing Perl] page ... ---- "As nasty and tasteless as Tcl is, it is a positive dream compared to Perl. The only conceivable way to write a correct Perl program IMHO is cutting and pasting from someone else's code. " Philip Greenspun [http://philip.greenspun.com/wtr/bookshelf.html] ---- [Category Language]