Which language I choose for which task is decided by my feeling.

1. Tcl has strings that are straight C strings, making length-dependent operations slow. List operations in Tcl are equally slow, because lists are strings.
   • Untrue since 1997. The Tcl_Obj structure has a string length. The internal representation of a Tcl list is a C array.
2. Tcl cannot deal with binary data because everything must be a null-terminated string.
   • Untrue since 1999. When Unicode compliance was added, Tcl's basic string representation became UTF-8, with an added twist that the invalid UTF-8 byte sequence C0 80 is used to represent a null byte in binary data. Binary data can be held efficiently in byte arrays.
3. Tcl cannot pass arrays by value or by reference, only by name.
   • This is largely a question of style. array get and array set can indeed be used to pass by value. Passing any object (not just an array) by reference is accomplished using pass-by-name and upvar. That's just how you spell it in Tcl, and somewhat a matter of personal taste.
   • AMG: See also: dict
4. Tcl lacks an installation mechanism and set of standard paths for new packages.
   • This comment predates the package command, added in 1996.
5. Tcl stores numbers as strings, slowing its arithmetic.
   • Not since 1997.
6. Tcl is a pure interpreter; Perl uses a bytecode engine.
   • Tcl has been bytecoded since 1997.
7. Perl comes with a full debugger, closely integrated with the language.
   • The best Tcl debuggers have always been add-ons. The core developers have typically not been interested in adding this functionality, partly because we don't miss it much ourselves (there are so many other ways of introspecting a Tcl program's behaviour), and partly so as not to bite the hand that feeds us (sales of TclPro from Scriptics and TDK from ActiveState have funded considerable Tcl development). This could be seen as a valid complaint.
8. Perl has namespaces that can export their symbols.
   • So does Tcl. Since 1997.
9. Perl allows dynamic loading of object modules.
   • So does Tcl. Since 1996.
10. Perl has anonymous subroutines. Tcl lacks them.
    • True. I've wanted anonymous lambdas for some time; there are a lot of details that have to be hashed out. The presence of apply in 8.5 will help some, and "auto-{*} on the leading word" would help even more, but would need a major release to get in.
11. Perl has a list that is numerically indexed, and Perl also has hashes.
    • Ditto Tcl, since 1999.
12. Perl has an extension mechanism (a C preprocessor that turns prototype-like definitions into interface code) that is more convenient than the binary API of Tcl.
    • This is somewhat a matter of opinion. I happen to prefer TEA to Perl's mechanisms; then again, Tcl's interfacing has improved enormously in the last decade.
13. Perl has references which allows arbitrarily complex data structures including structures that are self-referential.
    • Indeed it does. There is some dispute as to whether this is a good thing. Many Tcl'ers believe that sort of thing is for a lower-level language. I'll concede this round to Perl.
14. Perl can analyze a script for syntax errors without executing it.
    • Tcl's dynamic nature, where virtually anything but the twelve syntax rules can be redefined at run time, makes this inordinately difficult to get right in the most general case. For less wizardly uses, the TDK checker (payware) and Frink (open source) do quite a creditable job. Admittedly, neither is "in the core". Tcl suffers a great deal from disparagement of extensions. I'll give Perl a slight edge on this point, but only a slight one.
15. Perl has an object programming model.
    • Tcl's problem isn't that it lacks an object programming model, but that it's agnostic about object programming. It's possible to do quite a creditable job of object programming even in pure Tcl using a script-level package such as Snit. Yes, we're currently debating "OO in the core," but that debate is primarily driven by politics and to a lesser extent by run-time performance, not by capability.
16. Perl provides an interface to all the Posix (.1) routines.
    • Pray be more specific. Tcl has an awful lot, but often it doesn't precisely mirror Posix. Intentionally. Tcl runs quite well on systems that do not have workable Posix libraries - such as Windows - without resorting to emulation layers. There are a couple of gaps - generally in Posix API's that do not port gracefully to other platforms - and those gaps are filled quite nicely with extensions. Of course, many Tcl detractors, and some enthusiasts, disparage extensions for various reasons, many of which I fail to comprehend.

"Packaging is currently too hard in Python, and while there's effort to improve it, it's still largely focused on the problem of installing. The current approach is to just throw docs and specs at the building part"

• Home
• Recent changes
• Help
• WhoAmI/Logout
• Create new page
• Random page
• Previous page
• Next page
• 
  
• Add comments
• Edit
• History
• Edit summary
• References