Nathan Torkington writes:
> I'll take this up with Jeff, as I don't believe the Tcl meaning is
> particularly common. Thanks,
Here's what I sent.
On
http://tcl.activestate.com/advocacy/
I believe the chart is inaccurate. I think Perl and Python are at
similar levels of ease--Tkinter vs Perl/Tk are much the same.
I'm unsure how Python can be more extensible than Perl. There are two
meanings for "extensible"--language extensible (new keywords like
'switch' or 'with') vs C-language extensions. Tk is the only one of
the three that permits language extensions, while Perl and Python are
just as extensible with C.
I'll come to Unicode support in my next point, but I believe that
you're inaccurate here too.
Perl offers several thread options. As far as I know (you should
check with Sarathy just to make sure) the latest Perls are as
thread-safe as Tcl.
On
http://tcl.activestate.com/advocacy/perl.html
while the page claims to be "ten reasons why many people prefer Tcl
over Perl" it talks about "you" and "probably" rather than the
experiences of the people who prefer Tcl. For example:
> 2. "if you come back to a Perl script after a couple of months, you
> probably won't be able to understand it anymore."
should be
2. "many Tcl programmers found that if they returned to a Perl script
after a couple of months, they couldn't understand it any more."
There are also some factual problems too, I think.
> Graphical User Interfaces. The Tk toolkit provides Tcl with GUI
> facilities that are amazingly simple and powerful. There's nothing
> quite like it in any other language.
There's a lot like it in other languages--the other language's
bindings to the Tk toolkit!
> Perl has no built-in GUI facilities of its own. There is a package
> called TkPerl that allows you to use Tk from Perl scripts, but it's
> pretty clumsy.
Again, "Tcl programmers think it's clumsy and find Tcl a more natural
fit to Tk."
> Tk was really designed to work best with Tcl; furthermore, TkPerl
> doesn't provide access to the additional widget extensions people
> have built for Tk.
That seems a half-truth. Many people have written Perl wrappers for
the third-party Tk widgets, and have also written their own all-Perl
widgets.
> Development tools. Scriptics. TclPro product provides a
> sophisticated set of development tools for Tcl, including a powerful
> graphical debugger, code checker, and other tools. TclPro runs on
> Windows as well as several versions of Unix. The commercial tools
> available for Perl are less complete and run only under Windows.
You might want to talk to the Activestate folks about this. There are
GUI debuggers that work on Windows and any Unix that supports Tk.
> Internationalization. Tcl is based on Unicode, which makes it
> superior for applications that must be internationalized. Perl is
> still based on 8-bit characters. It can't support Asian character
> sets, and it can't properly support new technologies that require
> Unicode, such as XML. The Tcl regular expression engine works on
> 16-bit characters. Perl's does not.
Perl's RE engine and string operations support Unicode. Ask Sarathy.
> 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: they allow you to add new functions, new data
> structures, and even new control structures such as loops or
> conditionals. 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. Dozens of Tcl
> extensions are available freely on the Internet, providing features
> such as database access (Sybtcl, Oratcl, and Tclodbc),
> object-oriented programming ([incr Tcl]), and network management
> (Scotty). 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.
This blurs the distinction between language constructs and mere
functions. Perl doesn't blur that line--you have to use a source
filter to add new language constructs such as control structures, but
it's trivial to add new function through modules. You can write these
functions in Perl, C, C++, Java, Python, assembly language, Basic,
Awk, Guile, Octave, even Tcl. Thousands of Perl extensions are freely
available on the Internet, and in addition to an incompatible
diversity of database-specific modules, we have have the DBI system.
Objects are built into Perl (we don't need "[incr Perl]" :-) and Perl
is constantly extended. CPAN is one of the major selling points of
Perl, and when you confuse language extensions (e.g., control
structures) with functional extensions (e.g., modules) you
misrepresent the utility of the two languages.
> Perl was not designed to be embeddable and it is difficult to use in
> this way. Thus, if you would like a scripting language for use
> inside an application or device, Tcl is your best bet.
mod_perl is one counterexample of this.
> Thread-safe. The Tcl interpreter is thread-safe, which means you can
> embed Tcl in multi-threaded applications such as large servers and
> enterprise applications. Some of the largest Web sites (e.g.,
> NetScape NetCenter) use Tcl in multi-threaded server applications
> for dynamic page generation. Perl is not thread-safe.
As I said before, I believe that Perl is thread-safe.
> Range. Tcl can be used in many more situations, for many more
> purposes, than Perl. Perl is really a text manipulation language,
> whereas Tcl is a more general application development language.
> Graphical user interfaces, Unicode, extensibility, embeddability,
> and threading are just a few examples of Tcl's greater range.
Those aren't examples of situations, those are examples of language
features you've already discussed! Perl's used in banking, science,
e-commerce, government, manufacturing, and pretty much any other
sector you care to name. Perl's been used to write network servers,
network clients, middleware, GUIs, control systems, and applications.
This seems quite a stretch. You definitely win in embedded devices,
though--I don't know of any devices that have chosen to embed Perl.
> If you explore the Perl Web sites, you'll find various claims about
> why Perl is superior to Tcl. Many of these claims are either
> incorrect or out-of-date
I'm working on updating these now. Can I run the new version by you
for fact-checking?
Thanks,
Nat
