I recently read the "Why Tcl Is Better Than Perl" piece at Scriptics and was so disgusted by it's level of FUD, it's sophmoric arguments and that Scriptics published it that I wrote a "correction" to Scriptics focusing as much as possible on just the falicies and subjective statements.
I fell in with the Tcl folks at the Scaninavian Conference on Java and Object-Orientation last year when we had a short panel on "dynamic languages" discussing Perl, Python, Ruby and Tcl in front of an audience of Java programmers. Lemme tell ya, nothing makes the differences between Perl and Tcl look small like a room full of Java advocates. :) I've also been impressed that Tcl ships with a complete testing system. It's a long piece. I don't know if it's worth the trouble I put into it, but I felt like writing. It's unfortunate that I don't know Tcl 8 to better provide suggestions for where the article should go to make it a better piece on Tcl's strengths. ----- Forwarded message from Michael G Schwern <[EMAIL PROTECTED]> ----- From: Michael G Schwern <[EMAIL PROTECTED]> Date: Tue, 16 Jul 2002 23:03:02 -0400 To: [EMAIL PROTECTED] Subject: Corrections to "Why Tcl is better than Perl" User-Agent: Mutt/1.3.28i I'm writing in reference to the Scriptics.com article "Why Tcl is better than Perl" at http://www.scriptics.com/advocacy/perl.html. There is no author listed and the comments link is non-functional, so I have to email the webmaster. Please forward this mail on to the author, thanks. I find this article to be a fairly appalling piece especially given the relatively good relations between Perl and Tcl and how basically similar they are. The arguments presented are really something I'd expect more from your average Usenet flame. There are good bits, but they are overshadowed by the more ignorant pieces and lies by ommission. Therein lies the problem with negative advocacy. To back this up, I'll walk straight through the article. Before beginning I will say my last experience with Tcl was version 7.x with StoryServer. I understand that the difference between Tcl 7.x and 8.x is like perl4 to perl5, so I will avoid commenting on Tcl and stick to what I know, Perl. You will hear me harping on Java and C a lot mostly because I've heard many of the same arguments put forward by Java programmers against Perl. Basically, there are places where Tcl is better than Perl, but you're not focusing on them. Most of the article is the same tired "Perl is messy" arguments, and I'd really rather read an intellegent 'vs' argument. Really, what I'd love to hear is the strengths of Tcl rather than the perceived weaknesses of Perl. I'll start critiquing from the top. 1. Simplicity ************* Every language wants to claim it's simple, meaning a simple grammar, but what's really important is if their language is easy to learn in both the short and long term. Simple grammars often mean complexity is pushed off into libraries. Some languages do that well (Smalltalk), some languages do it badly (C, Java). I don't know where Tcl stands on this, the article doesn't bring it up. But I really don't want to get into a "my language is simpler than your language" because it's a highly subjective argument and I prefer to avoid that swamp. However, there are some bits I take exception to: The Perl language is riddled with special cases and idioms. No problem with that, we like our idioms. :) There are many different ways to do the same task in Perl, This, too, is true. Some people don't like that. Oddly enough, after talking with Brent Welch at JAOO last year, it turns out Tcl has many of the really wacky, dynamic features that Perl has like the ability to redefine subroutines while the program is running. and you'll have to learn them all if you're going to read other people's code. As a result, you'll need to be an expert programmer to learn Perl This conclusion is false. It is like saying you will have to learn all available Tcl extensions in order to read other people's code or that you have to learn the complete Java core library to read Java programs. and you should expect to go through a long learning curve. You should expect a long learning curve learning any first programming language. Anyone who tells you otherwise is selling something. Your second language is another story. To get started with Tcl, all you need to learn is about a half dozen basic syntax rules plus a few of the most popular commands. The same is true of Perl. It is not necessary to know OO or regexes or formats or any of the other bits of Perl to write a useful program. I start teaching with print and strings. Then if/else and loops. Then build from there. Languages where this is *not* true is Java and C as you must learn a large amount of syntax and magic phrases, and in Java's case, OO just to run a "Hello world" program. There are dozens of additional commands that provide everything from graphical user interfaces to database access to object-oriented programming, but you can pick these up one at a time when you need them. The implication here, because this is a "Tcl vs Perl" article is that you have to learn GUIs, databases and OO programming to make Perl useful. I'm sure you realize this is false. Both languages have the quality of being able to learn it in chunks. Even casual programmers find that they can learn enough Tcl to perform useful tasks in just a few hours. The same is true of Perl and most dynamic languages (Tcl, Python, Ruby, etc...). 2. Maintainability ****************** Like simplicity, maintainability is utterly subjective. The arguments presented reduce to basic name-calling. When it comes down to it, the largest factor in producing maintainable code is the programmer. I've seen awful code in every language, and every language manifests itself differently. In C, it's poor memory management. In Java & Python, it's poor/overuse of inheritence. In Perl, it's messy looking code. Perl gets a bad rap because messy code is very, very easy to spot. A lousy class hiearchy takes a bit more than a cursory examination to find. Most of the awful Perl code out there (and there's a lot) is produced by inexperienced programmers. Perl experienced a huge influx of new programmers during the .com boom and, since they didn't understand the basics of writing maintainable code, they produced some god-awful stuff. Too much for the experienced folks to counter. Much of this is still floating around, and many people learned from this trash. Only recently are we finally catching up on it. The only other language which had this popularity problem is Java. Ironically, this large influx of newbies to Perl disproves your claim in #1 that Perl is difficult to learn. :) The only useful, absolute measures of a languages ability to write maintainable code are basic language features like: namespaces, OO, lexically scoped variables, privacy enforcement, etc... Finally, the taking of the tongue-in-cheek quote from Programming Perl out of context is particularly low. The Perl community enjoys toying with our reputation as being an ugly language, please don't sucker punch us with our own jokes. 3. Graphical User Interfaces **************************** The Tk toolkit provides Tcl with GUI facilities that are amazingly simple and powerful. Yes, Tcl/Tk is a nice tool for building GUIs. It pretty much revolutionized the field. There's nothing quite like it in any other language. I wouldn't go quite that far. The short list of Perl GUI libraries are: Tk, Gtk, wxWindows, SDL and QT. I'm sure Tcl has versions of these GUI libraries, too. And they all have good and bad points, otherwise we'd all be using Tk. Perl has no built-in GUI facilities of its own. The tired argument of "language X doesn't come with feature Y" can be extended to anything. Tcl doesn't come with an FTP client library, DBM interfaces, Soundex implementation or Memoization library. Perl does. It's an argument that rapidly gets silly given the simplicity of obtaining and installing Perl (and I'm sure Tcl) libraries. TkPerl doesn't provide access to the additional widget extensions people have built for Tk. True. And the converse is also true, the Perl/Tk folks have been busy. A short list of Perl/Tk widget extensions: Tk:FileEntry Tk::Autoscroll Tk::Browser Tk::Clock Tk::ColourChooser Tk::ContextHelp Tk::Contrib Tk::DKW Tk::Date Tk::DateEntry Tk::EMatrix Tk::Enscript Tk::FileDialog Tk::FontDialog Tk::Cloth Tk::FireButton Tk::IFrame Tk::ListMgr Tk::NumEntry Tk::MenuEntry Tk::TFrame Tk::Getopt Tk::HTML Tk::HistEntry etc... See http://search.cpan.org/search?mode=module&query=Tk%3A%3A for details. Instead of simply declaring Tcl/Tk the winner by fiat, perhaps you could provide some examples of how Tcl/Tk is better than Perl/Gtk (widely regarded as superior to Perl/Tk) or where the Tcl/Tk extensions eclipse the Perl/Tk extensions. Be careful, once you get into concrete arguments involving facts you will have to defend them. :) 4. Development tools ******************** Perhaps one of the most laughable lines in the whole article is this: The commercial tools available for Perl are less complete and run mainly under Windows. Classic lie by restriction. Most Perl programmers don't depend on commerical tools because the free ones are so well done. My "Development Environment" is simply a well stocked Debian/Linux machine. I have no idea what the current state of commercial Perl tools are, so I can't comment further. As for all the useful tools, if nothing else their failing is they run mainly on Unix, but Activestate and the improved Windows port of Perl in the last few years has changed that a lot. Most are simply integrated into existing editors and tools. Emacs, vim, jed, joe & BBEdit (popular MacOS editor) all come with powerful Perl tools and hooks into the debugger to provide graphical interfaces. And I can keep using my favorite editor. Powerful profilers, documentation validators, coverage tools, etc... are all downloaded for free from CPAN, and will work on most platforms, under the Devel:: hierarchy. 5. Internationalization *********************** Perl is still based on 8-bit characters. It can't support Asian character sets Perl 5.6.x has Unicode support, but its admittedly not great, but it's certainly false to say Perl can't support Asian character sets. The Encode module available from CPAN handles such things. I won't hold up 5.6.x's Unicode support as anything wonderful, but don't try to claim it doesn't exist. Your statement is particularly amusing given this note Jarkko (5.8 pumpkin king) made just today about the 5.8.0 release announcement texts I'm now turning in the http://www.iki.fi/jhi/VVIIIN over to our C(hinese)J(apanese)K(orean) translation jury, so that we can get the 5.8.0 announcement out also to the largely untapped Asian markets :-) in their own scripts. 5.8.0 represents a huge leap forward for Perl's Unicode and non-Latin language support. The distribution and build time has almost doubled as a direct result of the extra Unicode modules and features. We've had folks from the other side of the Pacific working on Perl's Unicode and Big5 support for years now and it will all come together with 5.8.0. Since it will be released at the end of the week, you may as well revise your views now. and it can't properly support new technologies that require Unicode, such as XML. This is a low and underhanded argument designed to cause panic because with the message "Perl can't support XML!!!". Of course Perl supports XML, it was one of the first languages to provide a complete XML parser and there's dozens of XML modules on CPAN. http://search.cpan.org/search?mode=module&query=XML%3A%3A But because XML might involve Unicode, and Perl's Unicode support prior to 5.8 wasn't so hot, one can make the statement "Perl cannot support the complete XML specification with Unicode parts" which you have reduced to "Perl can't support XML". This is as silly as stating Perl can't support HTML because there might be Asian characters in it. Please remove this statement, it is an active lie and I'd expect better of an advocacy piece. The Tcl regular expression engine works on 16-bit characters. Perl's does not. As of 5.8.0 it does. I don't know the state of 5.6.x. If you are truly interested in discussing Perl's foreign character set handling, the man you want to talk to is Dan Kogai <[EMAIL PROTECTED]>. 6. Extensibility **************** Tcl was designed from the start to be easily extensible. This means that you can add new features to the language by writing C, C++, or Java code. Tcl provides a rich set of APIs for building extensions... Perl does not have a well-developed set of extension APIs; though it is possible in principle to extend Perl, it is rarely done in practice. The problem I have with this section is that you've confused the meaning of "Extensiblity". There are *two* in Perl. One is the XS system for writing Perl extensions using C and direct calls to the internal Perl API. It stinks. We know it stinks. We're rewriting all the internals for Perl 6 because it stinks so badly. But while writing extensions in C might be the common way to write language extensions in Tcl, it is *not* in Perl and I'm sure you're aware of that. Tcl's extension mechanism makes it easy to connect Tcl with things you would like to automate or integrate, such as enterprise applications or new network protocols. Network protocols in Perl are implemented in Perl. C extensions may be used for performance boosts but are not necessary. For a list of available Net:: modules, see: http://search.cpan.org/search?mode=module&query=Net%3A%3A The way you write Perl extensions in Perl is with Perl. That was *the* major feature introduced in Perl 5. This is a strength of Perl that one does not have to learn a second language to write powerful features and I'd mark it down as a flaw in Tcl if you have to bail out to C to write language extensions. Even the syntax of the language itself can be altered within Perl using the filtering mechanism. This has been taken to ludicrous extents by Damian Conway with modules such as Acme::Bleach (converts your entire program to whitespace), Lingua::Romana::Perligata (a complete, deep conversion of Perl to Latin) and Switch (the addition of powerful switch statement to Perl). Even a large number of Perl 6 language features have been backported to Perl 5. The number of available Perl modules in CPAN is not numbered in the dozens, but in thousands. To try and state that Perl is difficult to add functionality to is a lie of ludicrous proportions. CPAN is a resource unique to Perl and no language has its equal in scope and quality of freely available code. As a side note, there is a simple way to place C, Java, C++, etc... into Perl code. Inline::*. Here's a small example of Inline::Tcl. :) use Inline Tcl => <<'END_TCL'; proc square { val } { return [expr $val * $val] } END_TCL print square(3); What could be simpler? :) 7. Embeddablity *************** Perl is embeddable, but nothing like Tcl. Tcl was designed to be embedded. Tcl wins here, hands down, no qualms from me. 8. Thread-safe ************** Perl's threads, even 5.8.0's threads, are pretty lame. I don't know what Tcl's threads are like, but they have to be better. I don't know about the claim that "Perl is nt thread-safe", but they're certainly not elegant or anywhere close to bug-free. 9. Range ******** Like point #2, this argument reduces to name calling. Perl is really a text manipulation language This is as silly as calling C a system driver language, or Java a web applet language. After all, that's what they were built for in the first place. whereas Tcl is a more general application development language. I thought Tcl was a language for parsing config files. :) There are domain specific languages: Javascript and Flash come immediately to mind. Both Tcl and Perl started as domain specific languages (hell, almost every language did) and evolved into general programming languages. Please do not belittle and deny this heritage, there is nothing shameful about it. All the best languages evolved from being used for what they were never designed to do. It's a compliment of the highest order, not an insult. 10. Event handling ****************** Tcl has a much more sophisticated event handling system than Perl Tcl is very powerful for event handling, but Perl can be as well. Rocco Capputo's rediculously powerful POE (Perl Object Environment) has been likened to a "Perl Kernel". It's basically co-operative multitasking in a box. I'm sure I could be convinced that Tcl has better event handling than Perl, but the argument is free of content. So what I'd like to see here is more detail on *why* Tcl's event handling system is so much better rather than a few simple statements with no backing. Misconceptions ************** This is probably the best part of the piece. Many people think of Tcl in terms of 7.x when it was a slow, fully-interpreted language. Rather than trying to hold Tcl up to Perl, why not produce a "Tcl 7.x vs 8.x" article? Tcl has come so far in the last five years, but it's stuck with a bad historical rap. Much like perl5 had to deal with the ghosts of perl4. To sum up, this article is full of subjective statements with no backup and cleverly masked lies to artificially inflate Tcl's standing and belittle Perl. Either it was poorly researched or a deliberate act of misdirection. I'm dissapointed that ActiveState and Scriptics would allow it to be published. It is particularly lamentable as Tcl 8 has improved so much that it can stand on it's own just fine. I'd ask Scriptics to pull this article down and replace it with something better thought out, better researched, containing more concrete arguments and content and perhaps with an experienced Perl programmer auditing to catch any misunderstandings prior to publishing. Or perhaps replace it with an expanded "Tcl 7.x vs 8.x" piece showing all the improvements and clearing up any Tcl misconceptions still floating around. The article reminds me of the laughable claims made by Omnimark who set up a booth at The Perl Conference 3 claiming Omnimark was "Cheaper Than Perl!" [1] To which the obvious response was "So they pay us to use it?" I have unfortunately lost my copy of the pamphlet, but found an old message covering the basic points. http://bumppo.net/lists/fun-with-perl/1999/10/msg00035.html The claims are strangely similar to those in this piece. It's readable, it's concise, it has an IDE, it supports XML... The sad part is in Omnimark's attempts to promote itself as a Perl Killer it failed to emphasize it's most best feature: It's rediculously powerful and concise at dealing with SGML, HTML and XML. Blows Perl out of the water, hands down, on dealing with markup languages. But rather than focus on this strength they chose a negative message and got a negative result. [1] They have since topped that with their new slogan "Realize the value of your content!" -- This sig file temporarily out of order. ----- End forwarded message ----- -- This sig file temporarily out of order.
