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 ([ActiveTcl]) is getting better but it's still not as slick as CPAN. * perlmonks.org ([VK]) a great and highly resposnive support site, based on people searching and giving answers to perl questions; usually a question receives many answers within a half of an hour. [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. [VK] on the other side, perl's RE engine is highly optimized: when one writes /^(...)/ interpreter effectively eats three characters without even starting searching process. But this leads to another problem, when source C code implementing such technology becomes very complicated, and there is lack of RE experts on C level (true for Tcl, Perl and probably entire RE world) ---- 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''' LSES - I really dislike that argument. If those variables cause you trouble, don't use them! Perl treats us like adults. If you like terseness, bask in all its terseness. If you like very clear and organized code, especially when you intend to share it, write your own very clear and organized code and be happy. That free attitude will not protect you from someone else's terseness, but forcing people to use "very clear and organized code" even when they don't want to is not the best way. Educate them, but don't force them. Whenever I think of Python's use of indents as part of the syntax, I think: this soup nazi hates terse code and thus created a language that would make it compulsory for everyone to write in the style that *he* prefers. Despite it all, I, for one, can find terseness in practically any language. Whenever someone uses lots of single-character variables in anything with more than half a dozen lines, I find it very hard to read. Keeping tabs on what $a, $b, $c, $i, $j and $r mean to read and understand a function or class is very annoying. But they are all free to use their obscure variables. And more sensible programmers will give their variables more meaningful names, so you always know exactly what is going on without unnecessary effort. Free choice is the best ultimate judge. When a language allows for both terseness and tidiness, it is fair and generous. If the language removes either, it shows it is made for one specific tribe and is not afraid to disregard diversity in writing preferences. ---- ''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] ---- [lv] Perhaps the community would consider adding, either here or on a new page, references, helpful tips, etc. to people who know perl but who are trying to understand Tcl. In particular, if there are specific concepts which have the same name, but differing behaviors, noting those areas would be helpful. ---- Recently on comp.lang.tcl, someone asked, yet again, what the tcl equivalence to Perl's pack function is. I thought I recalled, somewhere in the past, some site having a table that showed correspondence between perl functionality and tcl functionality. Anyone reading this recall such a thing - if you still know where it is, could you insert it on this page? -- Take a look at the [binary] command. Yes, the binary command answers the specific question. But it doesn't help in the general case - where someone either converting some perl code to tcl, or who knows perl and is trying to learn tcl, wants to find equivalents. -- Sorry, I didn't read the question through. The [BOOK Programming Language Examples Alike Cookbook] does this to some extent, but I'm not sure a simple functionality equivalence table would be very useful, because of the differences on other levels. Also, what functionality '''is''' equivalent, anyway? For instance, Perl has no (exact) equivalent to, say, [[puts]]... -- Well, Perl's print is similar functionality, though one has to explicitly specify newlines, whereas in tcl one has to explicityly specify no newlines. ---- Has anyone compared the Perl functionality from the perl source distribution to see what functionality would need to be written for Tcl and added to [Tcllib] (or perhaps to [Activetcl]) so that they had closer to the same level of functionality? -- [VK] In my understanding those are (incomplete list, please add/remove items): * '''Config''' module; one can check configuration variables at run-time of module; in Tcl this could be tricky. (to answer questions like: where is my perl.h, perl.lib, so to rely on those probably versioned parameters; wheter current binary is threaded; tclConfig.sh is very different and can't be used directly from Tcl and either requires shell or some parsing) * '''-e''' switch to write tiny script from oneliner has proven useful: its not always possible to do '''echo ... | perl''' for small programs, and its very handy to write '''perl -MConfig -we 'print $Config{usethreads}' ''' * built-in debugger, console-based, which then could be extended to GUI debugger from [CPAN] * bigint/bigrat: a command '''perl -Mbigint -we 'print 2**10000' ''' just works; in Tcl big-numbers arithmetics isn't in the core distribution, but ''([DKF]: Planned for 8.5; [KBK] is working on it.)'' From the other side, it is obvious that Perl lacks GUI in its source distribution. Question: do the urls http://www.perldoc.com/perl5.8.6/pod/perlfunc.html and http://www.perldoc.com/perl5.8.6/pod/perlmodlib.html provide the full list of perl functionality ''out of the box''? -- Indeed, yes, this is a good approach to dig. Commands ''perldoc perlfunc'' and ''perldoc perlmodlib'' should provide same information. BTW keep in mind that mostly those modules in perlmodlib have relations to perl internals (not for users) and B::* and O::* considered not in shape for using those... ---- See also the [Tcl cheat sheet]. ---- [Category Language]